0

I'm booting kernel on my board with u-boot ramdisk image which is 39.8 MB. It boots successfully. When I try another u-boot image which has 74.7 MB size, load adress of ramdisk changing and its giving

'Loading Ramdisk to ff8c0000, end 03fffd63... Bad Trap at PC:7fef8cb0'

and board hangs with ' ###ERROR ### Please RESET the board ###'

Commands I use for booting with tftp:

tftp 30000000 uImage.bin
tftp 32000000 DTB.dtb
tftp 40000000 rootfs.ext2.gz.u-boot
bootm 30000000 40000000 32000000

I also tried different tftp adresses. Scenario remains same.

How can I solve this situation?

Edit: Full Console log:

=> bootm 30000000 40000000 32000000 WARNING: adjusting available memory to 30000000

Booting kernel from Legacy Image at 30000000 ...

Image Name: Linux-4.19.26+gc0c2141

Image Type: PowerPC Linux Kernel Image (gzip compressed)

Data Size: 7140198 Bytes = 6.8 MiB

Load Address: 00000000

Entry Point: 00000000

Verifying Checksum ... OK

Loading init Ramdisk from Legacy Image at 40000000 ...

Image Name: core-image-x11-t1042d4rdb-64b-20

Image Type: PowerPC Linux RAMDisk Image (uncompressed)

Data Size: 74710371 Bytes = 71.2 MiB

Load Address: 00000000

Entry Point: 00000000

Verifying Checksum ... OK

Flattened Device Tree blob at 32000000

Booting using the fdt blob at 0x32000000

Uncompressing Kernel Image ... OK

Loading Ramdisk to ff8c0000, end 03fffd63 ... Bad trap at PC: 7fef8cb0, SR: 0

NIP: 7FEF8CB0 XER: 20000000 LR: 7FF16C60 REGS: 7faedae0 TRAP: 0d00 DAR: FFFFEFFC

MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00: 00000003 7FAEDBD0 7FAEDE98 FF8C0000 4073F038 0473FD60 FFFFF000 5E2AE23B GPR08: DE633873 00000020 00000001 7FAEDBE0 7FFCB808 08200800 7FAF52E8 00000000 GPR16: 00000000 00000000 306CF3A6 30000000 00000001 30000040 00000000 7FF957A8 GPR24: 7FAF533C 7FFCB6FC 7FFCB718 40000040 04000000 7FFCB6F8 7FF78540 0473FD63 Call backtrace: 7FFCB6F8 7FF176CC 7FF0D9D4 7FEFA26C 7FF1B088 7FF0BC44 7FF0BE08 7FF0C3B8 7FF1A664 7FF09CDC 7FF0CCC4 7FF4FF3C 7FF0D1D0 7FEF1040 Exception in kernel pc 7fef8cb0 signal 0

ERROR ### Please RESET the board ###

  • Are you seeing issue in the filesys mount? kernel is loading successfully? Ramdisk execution address is ff8c0000. Is this address configured by yourself? 74.7 MB of filesys may overflow with this address. – Rajeshkumar Jan 07 '20 at 05:00
  • I am having this issue when filesys is mounting on RAM. Kernel is loading successfully but in the next step this error occurs. ff8c0000 is given automatically. Yes probably that is the reason but I don't understand why. 39.8 filesys is locating in different place. 74.7 is locating at ff8c0000. What is the way of enlarging this memory area or changing ff8c0000 ? – Yusuf Altıparmak Jan 07 '20 at 05:25
  • can you change the kernel boot args "ramdisk_size=" (unit in KB) – Rajeshkumar Jan 08 '20 at 00:38
  • Increase the ramdisk_size to more than 74.7 MB. – Rajeshkumar Jan 08 '20 at 01:15
  • Where is the location of "ramdisk_size" variable? According to my demo boards doc. the are for rootfs in nor flash is 43 mb, perhaps they arranged this variable to 64MB with max value. Maybe increasing it to 128MB works. – Yusuf Altıparmak Jan 08 '20 at 05:23
  • Either we can do the change in '.config' file or we can add this variable in kernel bootargs at runtime. example: kernel /vmlinux ro root=LABEL=/ rhgb quiet ramdisk_size=131072 – Rajeshkumar Jan 08 '20 at 19:02
  • Hİ @Rajeshkumar, '.config' file is like this; CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=131072 – Yusuf Altıparmak Jan 09 '20 at 13:42
  • It seems I already have 128 MB permitted in CONFIG_BLK_DEV_RAM_SIZE=131072 – Yusuf Altıparmak Jan 09 '20 at 13:43
  • Seems like the Linux image execution overwrites some of the location where your initrd file copied. Try to change the physical memory of ramdisk file. Also try to use below uboot variable "setenv initrd_size ". – Rajeshkumar Jan 09 '20 at 20:02
  • What I understood so far is, the adress in 'Bad trap at PC: 7fef8cb0' 7fef8cb0 nearly equals 1,998995945 GB and start adress of Ramdisk seems ff8c0000 which nearly equals 3,992919922 GB. Why U-boot is arranged so many memory for a ~70 MB ramdisk image ? – Yusuf Altıparmak Jan 10 '20 at 04:46
  • And is there any variable to change the start adress of initrd or uImage when boot process started? – Yusuf Altıparmak Jan 10 '20 at 04:47
  • Can you paste here your kernel boot args? – Rajeshkumar Jan 10 '20 at 21:41
  • Hello @Rajeshkumar, this problem is solved by increasing CONFIG_BLK_DEV_RAM_SIZE to 500000 instead 131072 – Yusuf Altıparmak Feb 18 '20 at 11:17
  • Thanks for the info – Rajeshkumar Feb 19 '20 at 20:07

2 Answers2

0

You are loading the kernel image at 0x30000000. Afterwards you are loading the device tree at 0x30000000.

0x32000000 - 0x30000000 = 0x2000000 = 33554432

So when loading the device tree you are overwriting the kernel image.

If the area between 0x3f000000 and 0x40000000 is not used otherwise, choosing 0x3f000000 for the device tree should solve your problem.

Xypron
  • 1,660
  • 1
  • 9
  • 18
  • Hmm, but when I try this settings with an ~39MB rootfs, it boots successfully. What is the point of this. – Yusuf Altıparmak Jan 07 '20 at 18:10
  • It is evident that in the 39 MB you are also overwriting a part of the kernel image. If the modified code is not used, you may not immediately observe the error. Does changing the address solve your original problem? – Xypron Jan 08 '20 at 21:18
  • Hello, no it did not changed the original problem yet. Between the adresses ff8c0000 and 03fffd63, ff8c0000-03fffd63 isn't that area is larger than ~79MB. I still couldn't get why bad trap occurs. – Yusuf Altıparmak Jan 09 '20 at 13:49
0

What I understood so far is, the adress in

'Bad trap at PC: 7fef8cb0'

7fef8cb0 nearly equals 1,998995945 GB and start adress of Ramdisk seems ff8c0000 which nearly equals 3,992919922 GB.

Why U-boot is arranged so many memory for a ~70 MB ramdisk image ?