Huh that’s strange, I do recall there not being ethernet support added at the moment (since that now goes through the RP1 chip iirc) but you should be able to get a successful boot into the kernel. I’ll have a look to see what variables there might be in our layer. I’m a bit limited in terms of serial output at the moment since I don’t have a dedicated UART header on hand (having to go through GPIO which has to be rerouted through a dtb, so u-boot doesn’t pick it up)
Hi @pyxlwuff,
The UART is the key here. I have the official RPi debug probe attached, but for whatever reason it seems to push something on the TX line. I disconnected that one, and BOOM, the autoboot cmd gets executed. So yay, RPi5 booting nicely!
EDIT:
EDIT 2: I’ll try to assemble everything into a preliminary layer for tinkering, but the u-boot version discrepancy makes it a bit complicated. Probably proper support will be scarthgap and later, then.
Greets,
Josef
1 Like
Discovered an issue with our Pi 4 8GB variants running our Pi 4 version of the test image in 32 bit would cause u-boot to not work. I’ve done some digging and found a patch from Home Assistant that reverts the problematic section.
Tested on both Pi 4 4GB and 8GB Variants, and Pi 5 (4GB) with successful boots. I’ve updated my fork of meta-mender with this patch included, but further tests are probably going to be needed on other variants, just in case this quietly triggers something elsewhere.
1 Like
Currently some quite ugly hacks are involved. But if you feel like giving it a spin, then GitHub - TheYoctoJester/meta-mender-community at raspberrypi5 holds a preliminary state of the board integration.
Enjoy!
1 Like
Thanks everybody for the discussion and contributions, I finally have assembled a WIP state of the integration here, and will let it evolve.
The main moving part is u-boot, with the required 2024.04 version being obviously not finalised yet, and not being available in kirkstone. So a possible strategy might be to go for scarthgap and later only, but I’m not fully decided yet.
Input and opinions are very much appreciated!
1 Like
Great to see! I’ve also managed to secure myself a Raspberry Pi Debug probe too, and couldn’t seem to replicate the issue you were facing here - might’ve been your serial client pushing something?
The U-Boot team recently released 2024.04-rc5 so I’d assume with the release of that & Scarthgap just around the corner, alot of this will be able to be condensed into something more manageable
1 Like
I have created (and will continue to maintain) the scarthgap/u-boot branch for meta-lts-mixins. This is currently at the v2024.04-rc5 u-boot version which includes Raspberrypi 5 support. I haven’t had the time yet to try to port it to mender for scarthgap.
If there is sufficient interest, I can also create a kirkstone/u-boot branch for the meta-lts-mixins, but that was not my immediate need or goal. Embrace the future. Be the now.
I have pending changes to send as a PR to meta-raspberrypi.
I haven’t tried your branch yet, but I have absolutely observed that my meta-lts-mixins branch and corresponding meta-raspberrypi branch will not hand-off from u-boot to the linux kernel without the debug probe (the UART port between HDMI0 and HDMI1 on the PCB) present. I am still trying to root cause this. The other behavior I am seeing is that the framebuffer does not properly transition: we see the u-boot logo and then the 4 raspberrypi logos (4 cores) but no console output on the HDMI display. This is likely a configuration mismatch, but I do not know where yet.
For anyone unaware, the raspberrypi5 added the RP1 chip which does the early boot handling and this is likely where something is not quite correct. Mainstream Linux distributions do not see any issue, nor does yoe-distro (which does not use u-boot).
Hi @moto-timo,
I need to check the meta-lts-mixins layer out, thanks a lot for bringing it up. The thing that makes me wonder is, at least for the state that I have tested - with patches by @pyxlwuff - the situation is exactly the opposite. If the RPi Debug Probe is connected, the board is stuck in the u-boot shell but I can’t send any characters, while without the probe it happily boots. So my guess is that something with the device tree is just that little bit off.
Greets,
Josef
Yeah I’d agree here myself. I’m able to get it to boot with the probe attached straight into the kernel, but the u-boot timeout is quite quick so I haven’t been able to try dropping to its shell yet. I’ll have access to our Pi 5 Test board in a couple days to have a look. Regarding the devicetrees, they were taken from Raspberry Pi’s Kernel source, and embedded directly into our u-boot fork, so I assume something isn’t mapping the way u-boot expects at the moment?
EDIT: U-Boot 2024.04 is now fully available as a stable, however it seems it’ll still need the Pi 5’s dtbs manually patched in until they work their way into u-boot itself.
Hi,
Out of curiosity, what EEPROM firmware versions are you running on your Pi 5 test boards? I’m not sure if slight firmware changes might be the reason behind my successful boots not needing debug connections, but worth checking out. Both of my test pi 5s run 30de0ba5 (2023/10/30)