Pi 3b Compute Module boot issues using Open Embedded on rpi-5.4.y

[mike-scott]

Describe the bug
The Open Embedded build doesn't mirror everything in the boot directory of this repo into the boot partition of the build. Only the following files are directly copied:
*.elf
*.dat
*.bin

The kernel7.img in our case is a u-boot.img and DTBs/overlays are produced directly from the kernel build depending on the configuration used for the Open Embedded build -- in our case the overlays are present, but the only *.dtb file present in the main boot partition directory is bcm2710-rpi-cm3.dtb.

The resulting boot partition when used doesn't make it to u-boot (console wise).
From here I started debugging the build. Here are the highlights:

1. Hand build the DTB directly from the rpi-5.4.y sources and copy that to the boot partition: same hung boot result.
2. If I copy the DTB from a rpi-4.19.y build, I get a full boot and the system works normally.
3. If I apply the following diff to the 5.4-based DTS then I can boot all the way to the kernel but it hangs when ISP is loaded:

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 4426f9e6ba92c..abcf677fe4162 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -306,7 +306,7 @@
               };
 
               uart0: serial@7e201000 {
-                      compatible = "arm,pl011", "arm,primecell";
+                      compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
                       reg = <0x7e201000 0x200>;
                       interrupts = <2 25>;
                       clocks = <&clocks BCM2835_CLOCK_UART>,

4. if I remove the following cma data from arch/arm/boot/dts/bcm283x.dtsi I get a full boot and system works normally:

		cma: linux,cma {
			compatible = "shared-dma-pool";
			size = <0x4000000>; /* 64MB */
			reusable;
			linux,cma-default;
		};

NOTES: #4 is probably something I need to work out in our command line vs. DTS configuration for CMA. But #2 seems like an issue where the RPi firmware is parsing something that was removed from the 5.4.y DTBs?

Expected behaviour
Firmware should at least boot to kernel7.img.

Actual behaviour
Hangs prior to kernel7.img console init.

System
Open Embedded master branch build using rpi-5.4.y

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
  Raspberry Pi 3B Compute Module

• Which OS and version (cat /etc/rpi-issue)?
  Open Embedded Dunfell release

• Which firmware version (vcgencmd version)?
  Firmware repo @ SHA 7449540

• Which kernel version (uname -a)?
  5.4.40

[pelwell]

If the firmware is starting the ARMs at the entry point of the supplied kernel, with a pointer to the chosen DTB, then it has fulfilled its duty. Any incompatibility between the rpi-5.4.y DT and U-boot is not our responsibility, but we're happy to work with the U-boot maintainers if they have questions, etc.

[mike-scott]

Hi @pelwell Thanks for responding.

I understand that this is not a supported boot method by your team. However, the current firmware has such a minimal amount of console print enabled, that it's hard to tell if it's actually making the jump to the kernel7.img or not in the case of #1.

Is there a "testing" firmware that would have more debug enabled for this purpose?

I'm surprised that users of https://github.com/agherzan/meta-raspberrypi/commits/master (@agherzan or @kraj) aren't seeing this same issue.

[mike-scott]

@pelwell I apologize. This one is on me.

I took another look through our Open Embedded setup and realized we are specifically changing the u-boot config to use the firmware supplied DTB (in an attempt at making the u-boot image more re-usable across RPi variants) -- Some of the larger distros do this as well for the same reason.

The upstream RPi u-boot build sets: CONFIG_OF_EMBED=y which would ignore the DTB passed in by the firmware completely and this issue wouldn't occur.

I also see that @agherzan / @kraj Open Embedded layer doesn't use u-boot so they would not see this.

Closing this issue.

[agherzan]

The Yocto BSP layer has support for u-boot it as far as I remember it uses an embedded dtb for rpi3 variants. There was a plan to change that in uboot but I haven't had the time to follow up if that happened or not.