U-Boot loaded RAMDisk crashes Linux on MT7623
Daniel Schwierzeck
daniel.schwierzeck at gmail.com
Tue Jul 20 02:49:44 CEST 2021
Hi Daniel,
Am Montag, den 19.07.2021, 18:34 +0100 schrieb Daniel Golle:
> Hi,
>
> I writing in the hope that someone has a good idea about why U-boot
> is
> handing over a broken memory address for a loaded ramdisk which
> results
> in Linux crashing very early on boot on MediaTek's MT7623N SoC
> (ARMv7).
> If anyone has a good idea why this is happening, I'd be very glad, as
> this currently prevents me from updating that target in OpenWrt.
> Background:
> OpenWrt used to have the initramdisk built-into the kernel itself.
> Having it separate is nicer as then you won't need to recompile the
> kernel or even have a compiler installed in order to modify the
> ramdisk. This already works great on MT7622 and it'd be great to have
> it the same way on MT7623 (and MT7629 in future).
>
> So when loading a uImage.FIT with RAMDisk subimage to me it looks
> like
> U-Boot is not translating the address of the ramdisk correctly, see
> logs below:
>
> U-Boot> tftpboot 0x88000000 openwrt-mediatek-mt7623-bpi_bananapi-r2-
> initramfs-recovery.itb
> Using ethernet at 1b100000 device
> TFTP from server 192.168.5.2; our IP address is 192.168.5.100
> Filename 'openwrt-mediatek-mt7623-bpi_bananapi-r2-initramfs-
> recovery.itb'.
> Load address: 0x88000000
> Loading:
> #################################################################
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> ############################################################
> #####
> 13 MiB/s
> done
> Bytes transferred = 10492520 (a01a68 hex)
> U-Boot> bootm
> ## Loading kernel from FIT Image at 88000000 ...
> Using 'config-1' configuration
> Trying 'kernel-1' kernel subimage
> Description: ARM OpenWrt Linux-5.10.51
> Type: Kernel Image
> Compression: gzip compressed
> Data Start: 0x880000e4
> Data Size: 4944975 Bytes = 4.7 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x80008000
> Entry Point: 0x80008000
> Hash algo: crc32
> Hash value: 9da8225f
> Hash algo: sha1
> Hash value: ea4e69501bed0925ecdee0bb6b3a3b489fedc38c
> Verifying Hash Integrity ... crc32+ sha1+ OK
> ## Loading ramdisk from FIT Image at 88000000 ...
> Using 'config-1' configuration
> Trying 'initrd-1' ramdisk subimage
> Description: ARM OpenWrt bpi_bananapi-r2 initrd
> Type: RAMDisk Image
> Compression: Unknown Compression
> Data Start: 0x884b7668
> Data Size: 5511960 Bytes = 5.3 MiB
> Architecture: ARM
> OS: Linux
> Load Address: unavailable
> Entry Point: unavailable
you could try to explicitely set load and entry address to 0.
> Hash algo: crc32
> Hash value: 01e5fbf0
> Hash algo: sha1
> Hash value: 6ceb78df26920d97dee505ddeb0318e0c1522ba0
> Verifying Hash Integrity ... crc32+ sha1+ OK
> WARNING: 'compression' nodes for ramdisks are deprecated, please fix
> your .its file!
> ## Loading fdt from FIT Image at 88000000 ...
> Using 'config-1' configuration
> Trying 'fdt-1' fdt subimage
> Description: ARM OpenWrt bpi_bananapi-r2 device tree blob
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x889f9288
> Data Size: 33453 Bytes = 32.7 KiB
> Architecture: ARM
> Hash algo: crc32
> Hash value: a2599155
> Hash algo: sha1
> Hash value: 59c64737be8bda92b33417dfadca87e9c4662be2
> Verifying Hash Integrity ... crc32+ sha1+ OK
> Booting using the fdt blob at 0x889f9288
> Uncompressing Kernel Image
> Loading Ramdisk to ff4b9000, end ff9fab18 ... OK
> ^^^^^^^^^^
> Using Device Tree in place at 889f9288, end 88a04534
>
> Starting kernel ...
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 5.10.51 (daniel at box) (arm-openwrt-linux-
> muslgnueabi-gcc (OpenWrt GCC 8.4.0 r17073+11-8bb4437c01) 8.4.0, GNU
> ld (GNU Binutils) 2.34) #0 SMP PREEMPT Mon Jul 19 12:26:15 2021
> [ 0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7),
> cr=10c5387d
> [ 0.000000] CPU: div instructions available: patching division
> code
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [ 0.000000] OF: fdt: Machine model: Bananapi BPI-R2
> [ 0.000000] earlycon: uart8250 at MMIO32 0x11004000 (options '')
> [ 0.000000] printk: bootconsole [uart8250] enabled
> [ 0.000000] Memory policy: Data cache writealloc
> [ 0.000000] Zone ranges:
> [ 0.000000] Normal [mem 0x0000000080000000-0x00000000afffffff]
> [ 0.000000] HighMem [mem 0x00000000b0000000-0x00000000ffffefff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080000000-
> 0x00000000ffffefff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-
> 0x00000000ffffefff]
> [ 0.000000] 8<--- cut here ---
> [ 0.000000] Unable to handle kernel paging request at virtual
> address 3f9fab0c
>
> ^^^^^^^^^^
> Xf8fabXX looks familiar, see above. Just 3XXXXXXX seems wrong, or at
> least not where physical memory ended up being mapped in Linux.
> I also don't understand why U-Boot is reloacing the RAMdisk in first
> place, shouldn't it be fine to just pass the address where it is
> loaded inside the FIT structure (0x884b7668)?
The bootm command calls boot_ramdisk_high()
when CONFIG_SYS_BOOT_RAMDISK_HIGH is enabled. This is the case for most
archs.
If you look at that function, you can somewhat control the behavior
either via env variables "initrd_high", "bootm_low", "bootm_size" or
via gd->ram_base, gd->ram_size, gd->ram_top. Maybe you could debug and
play with that function. According to the code an in-place initramfs is
only possible, if you do a "setenv initrd_high 0xffffffff". But you
should also check if ARM Linux has some special alignment requirements
for initramfs and if a address of 0x884b7668 is useable (for example on
MIPS, there is a 16 kiB boundary requirement and moving the initramfs
with boot_ramdisk_high() accomplishes that).
>
> [ 0.000000] pgd = (ptrval)
> [ 0.000000] [3f9fab0c] *pgd=00000000
> [ 0.000000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.51 #0
> [ 0.000000] Hardware name: Mediatek Cortex-A7 (Device Tree)
> [ 0.000000] PC is at memcmp+0x10/0x50
> [ 0.000000] LR is at start_kernel+0x8c/0x508
> [ 0.000000] pc : [<c04b8098>] lr : [<c0c00a08>] psr:
> 200000d3
> [ 0.000000] sp : c0d01fc0 ip : 3f9fab0c fp : 00000000
> [ 0.000000] r10: 10c5387d r9 : 3f9fab08 r8 : c09c007c
> [ 0.000000] r7 : 3f9fab18 r6 : c0da1038 r5 : c0d04ec0 r4 :
> 3f9fab0c
> [ 0.000000] r3 : 00000023 r2 : 0000000c r1 : c09c007c r0 :
> 3f9fab0c
> [ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA
> ARM Segment none
> [ 0.000000] Control: 10c5387d Table: 8000406a DAC: 00000051
> [ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
> [ 0.000000] Stack: (0xc0d01fc0 to 0xc0d02000)
> [ 0.000000] 1fc0: 00000000 00000000 00000000 00000000 c0c28a54
> 00000000 00000000 c0c00330
> [ 0.000000] 1fe0: 00000051 10c0387d 00000000 889f9288 410fc073
> 00000000 00000000 00000000
> [ 0.000000] [<c04b8098>] (memcmp) from [<00000000>] (0x0)
> [ 0.000000] Code: e3520000 0a00000f e1a0c000 e5d13000 (e5d00000)
> [ 0.000000] random: get_random_bytes called from
> print_oops_end_marker+0x24/0x4c with crng_init=0
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Kernel panic - not syncing: Fatal exception
> [ 0.000000] Rebooting in 1 seconds..
> [ 0.000000] Reboot failed -- System halted
>
> Anyway, all ideas are welcome :)
>
>
> Cheers
>
>
> Daniel
--
- Daniel
More information about the U-Boot
mailing list