agherzan / meta-raspberrypi

Yocto/OE BSP layer for the Raspberry Pi boards
https://www.yoctoproject.org/
MIT License
540 stars 414 forks source link

Kernel Uncompress Failure on Raspberry Pi 4 in Scarthgap Yocto Release #1306

Open mdrodrigo opened 6 months ago

mdrodrigo commented 6 months ago

Description:

Issue: Encountering a error during kernel uncompression on the Raspberry Pi 4 when utilizing the Scarthgap Yocto Release and meta-raspberrypi layer on the master branch. This issue manifests specifically with kernel version 6.6 on the raspberrypi4 machine. Upon booting, following the u-boot initialization, the kernel uncompression process triggers an error, causing the board to enter a reboot loop.

Error Log from U-Boot:

U-Boot 2024.01 (Jan 08 2024 - 15:37:48 +0000)

DRAM:  628 MiB (effective 3.6 GiB)
RPI 4 Model B (0xc03111)
Core:  212 devices, 16 uclasses, devicetree: board
MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... OK
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
PCI: Failed autoconfig bar 10
starting USB...
Bus xhci_pci: dm_pci_bus_to_phys: invalid physical address
xhci-pci init cannot map PCI mem bar
probe failed, error -5
No working controllers found
Hit any key to stop autoboot:  2  1  0 
Card did not respond to voltage select! : -110
** Booting bootflow 'mmc@7e340000.bootdev.part_1' with script
Working FDT set to 273e2400
8520088 bytes read in 370 ms (22 MiB/s)
## Booting kernel from Legacy Image at 00080000 ...
   Image Name:   Linux-6.6.22-v7l
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    8520024 Bytes = 8.1 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 273e2400
   Booting using the fdt blob at 0x273e2400
Working FDT set to 273e2400
   Loading Kernel Image
uncompressed: uncompress error -28
Must RESET board to recover
resetting ...
B/

Observations: Curiously, this issue does not persist when utilizing the raspberrypi4-64 variant. In this case, the kernel operates without encountering any issues.

Steps to Reproduce:

Utilize the Scarthgap Yocto Release on a Raspberry Pi 4. Ensure the kernel version is 6.6. Observe the boot process, noting the error during kernel uncompression.

Expected Behavior: The kernel should uncompress successfully on the Raspberry Pi 4 using the Scarthgap Yocto Release, allowing the board to boot normally without encountering errors.

Additional Information:

This issue is specific to the raspberrypi4 machine and kernel version 6.6. No similar issues have been observed with the raspberrypi4-64 variant. When using the kernel 6.1 the problem does not occur. Any insights or resolutions would be greatly appreciated.

Thank you for your attention to this matter.

leon-anavi commented 3 months ago

For the record: I ran into the same situation with machine raspberrypi4 on Scarthgap and as described in this issue the board boots fine with image built for raspberrypi4-64.

morten-bruun-zoetis commented 1 month ago

I also see this error. Does anybody know if there is a workaround?

ashlin4010 commented 1 month ago

To add a little more info: raspberrypi4-64 uses the Image format and the booti command raspberrypi4 uses the uImage format and the bootm command

If you take the uImage and extract it to a zImage you can boot it with bootz. The extracted zImage is identical to the kernel built without u-boot support.

Doing some research the error uncompressed: uncompress error -28 can happen if the kernel is larger than CONFIG_SYS_BOOTM_LEN, the default is 8M, and the kernel we are trying to boot is 8.2M.

Setting CONFIG_SYS_BOOTM_LEN to a larger number or making the kernel smaller should fix that issue. I am new to Yocto so I don't know how to change kernel or u-boot options. But both use kconfig so I would expect that meta-raspberrypi handles both in the same way.

kkettinger commented 1 month ago

I just came across this issue, @ashlin4010 thanks for pointing out where the bug is.

To set CONFIG_SYS_BOOTM_LEN to a higher value, create a bbappend for u-boot like this:

File structure:

meta-your-layer/
├── recipes-bsp
│   └── u-boot
│       ├── files
│       │   └── memory_size.cfg
│       └── u-boot_%.bbappend

u-boot_%.bbappend:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI:append = " file://memory_size.cfg"

memory_size.cfg:

CONFIG_SYS_BOOTM_LEN=0x1000000

The memory_size.cfg is picked up by u-boot and merged into the config.