RPi4 boot problem

General Discussions
, ,
1

My final step to make the image bootable was to set KERNEL_IMAGETYPE to “uImage” as U-Boot scripts get confused if it’s anything else.

Was this for RPi 4B? You are the first person I’ve come across who has said this was necessary, and my understanding is that newer versions of u-boot are compatible with zImage using the bootz command.

2

@dpv Yes, it definitely isn’t. I don’t know for EOL versions, but at least for dunfell, kirkstone and ongoing development it definitely is not. And you should not use anything other than that anyways for maintenance reasons anyways these days.

Greets,
Josef

3

Hi Josef,

Thanks for confirming uImage shouldn’t be required.

Since you seem to be an expert authority on these forums, I’ve been struggling to get a CM4 yocto project to boot correctly. I get a kernel panic message:

---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---

To debug, I compared the output partitions of the .sdimg file to the reference RPi4B bullseye image output from mender-convert linked in this official tutorial.

By doing this, I noticed a few differences, but the one that stood out most to me was that in the mender-convert image’s rootfs/boot directory, there are symlinks to every file in the boot partition, including the start*.elf and fixup*.dat files. The output from my yocto build has the rootfs/boot dir, but inside are only the .dtb, kernel7l.img, and zImage files (plus others I enabled via config.txt)

Could the absence of these files on rootfs be the problem? Is there a standard procedure to include them, or would I need to manually implement a recipe with something like ROOTFS_POSTPROCESS_COMMAND_append ?

Thanks for your assistance. Honestly I’m astounded how little discussion there is on this particular forum topic, given RPi4/CM4 must be one of the most popular targets.

4

Hi @dpv,

So, as far as I can tell there’s a few factors at play here.

  • the mender-convert generated image is based directly on the Raspberry Pi provided one, and those ship a lot of extra files in the boot partition. That is not needed in a Yocto build, so this is not the issue as far as I can see.
  • from my experience, the error message that you posted is actually just a symptom of something a bit up in the logs, which goes like “failed to mount rootfs” or such.
  • The usual reason for this is that the standard RPi builds are targeted at the non-CMs, and those always use the SD card. If you have something like a CM which uses eMMC, adjusting MENDER_STORAGE_DEVICE might be needed to adjust. If you compare the device paths on Debian CM vs. Debian standard RPi should give you the required information.

Greets,
Josef

5

Hi @TheYoctoJester,

Thanks for sharing this feedback. It has helped me continue investigating

I agree, we need to find the earliest sign of problems from kernel messages.

[    2.549168] mmc0: new DDR MMC card at address 0001
[    2.553095] of_cfs_init
[    2.565765] mmcblk0: mmc0:0001 AJTD4R 14.6 GiB 
[    2.572329] of_cfs_init: OK
[    2.617054]  mmcblk0: p1 p2 p3 p4
[    2.622674] mmc1: new high speed SDIO card at address 0001
[    3.820217] mmcblk0: mmc0:0001 AJTD4R 14.6 GiB
[    3.824943] ALSA device list:
[    3.825031] mmcblk0boot0: mmc0:0001 AJTD4R 4.00 MiB 
[    3.827907]   No soundcards found.
[    3.833963] mmcblk0boot1: mmc0:0001 AJTD4R 4.00 MiB 
[    3.841448] uart-pl011 fe201000.serial: no DMA platform data
[    3.842086] mmcblk0rpmb: mmc0:0001 AJTD4R 4.00 MiB, chardev (243:0)
[    3.856864] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: none.
[    3.865426] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    3.872544] devtmpfs: mounted
[    3.878401] Freeing unused kernel image (initmem) memory: 2048K
[    3.884510] Run /sbin/init as init process
/sbin/init: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory
[    3.910865] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

I googled this problem about libseccomp.so.2 , but it seems people often get load errors like this with many other shared libraries, and for a variety of reasons.

Command-line repair strategies were non-starters here, so instead, I fully formatted (not quick format) the eMMC, flashed a new image, booted it up and :tada: ta-da.
systemd runs and we arrive in userland.

Thanks again for the assistance. I had dozens of tabs open and too many questions/ideas swirling around.

Now I’ll get on with setup and testing Mender’s functionality. Cheers

1 Like
6

Indeed @dpv that sounds like a broken image or card filesystem. Glad you got it working and thanks for letting us know!

Greets,
Josef