CM4: Mismatched revision code from bootloader vs cpuinfo

[jovial_leavitt]

I purchased a 4GB CM4 from ebay for my yocto project. I wanted to test it out before buying more from the same vendor. I became concerned when I realized it doesn't report the same revision number in /proc/cpuinfo vs the bootloader (or vgencmd).

Code: Select all

root@raspberrypi4:~# vcgencmd otp_dump | grep -E '28:|30:'
28:6fec7c39
30:00b03140

root@raspberrypi4:~# cat /proc/cpuinfo | tail -n 4
Hardware        : BCM2711
Revision        : c03140
Serial          : 1000000029b7e722
Model           : Raspberry Pi Compute Module 4 Rev 1.0

root@raspberrypi4:~# cat /proc/meminfo | head -n 1
MemTotal:        3928752 kB

From the documentation[1] the model code b03140 indicates a 2GB ram CM4, where c03140 would be a 4GB model. Is this something to worry about? Has anyone else seen this kind of product code mismatch? The model revision reports as mismatched on the official rpi debian release as well.

(You can see the serial number is mismatched as well. This value shows correctly on the official rpi debian release, so I suspect this is something to do with my yocto image.)

[1]: https://www.raspberrypi.com/documentati ... des-in-use

[PhilE]

It's certainly nothing to worry about, provided the cpuinfo value matches the device you paid for. I don't know how the value programmed into the OTP is obtained - whether it is supposed to change when the RAM size on the production line is changed, whether they all get the same fixed value, or somewhere in between - but whatever is programmed, the RAM size is overwritten by the size determined from the RAM chip at boot time. If you were to swap the RAM parts between two CM4s (very much not recommended), the reported size would change accordingly but the values from otp_dump wouldn't.

[jovial_leavitt]

I see. That's helpful information. Thank you for the quick response.

[trejan]

You can see the serial number is mismatched as well. This value shows correctly on the official rpi debian release, so I suspect this is something to do with my yocto image.)

Does your Yocto image use Uboot? It will pass on a modified DT to the kernel which can cause this mismatch. The incorrect serial number and revision sounds like its getting overridden by uboot.env.

Does Raspberry Pi OS show the correct revision code?

[jovial_leavitt]

Yes, my yocto image is using u-boot. I'm attempting to support A/B updates with swupdate so I'm using u-boot to switch between the dual rootfs. I am not intentionally adding any extra DT to the uboot boot, but I can't rule it out because this yocto stuff is a big stack of software and I'm kinda stumbling through it.

On Raspberry Pi OS:

Code: Select all

Hardware        : BCM2835
Revision        : c03140
Serial          : 100000006fec7c39

On my yocto build:

Code: Select all

Hardware        : BCM2711
Revision        : c03140
Serial          : 1000000029b7e722

So the revision code does not match the bootloader value of b03140 on either OS, but the hardware and serial values are correct on rpiOS.

On my image I can see the correct serial number in /proc/device-tree/system/linux,serial, but the wrong one is displayed in /proc/cpuinfo.

At the risk of drifting off topic, I also have an issue with seeing a different MAC address. I can see the correct MAC is being passed in to the kernel cmdline but it doesn't take effect. Do you think that is a related issue?

[PhilE]

Did you run both of those images on the same board? Did you notice that the serial number also changed? My guess is that U-boot has been configured to use a pre-canned, pre-patched DTB, rather than inherit one from the firmware (which U-boot can easily do).

[jovial_leavitt]

Yes all of the outputs in these posts have been from a single board. I just switched and sd card out from the official raspi debian to my yocto build.

The serial number changing was also a hint something was off. I have been investigating where the odd serial/MAC are coming from but I haven't found the culprit. I am using the kirkstone branch of poky. I will look into if there are rogue dtb's floating around. I am still learning my way around this build system and this corner of linux. I would be grateful for any more suggestions on where to look.

[PhilE]

What is in boot.scr? Any references to fdt are particularly relevant.

[jovial_leavitt]

Hi, sorry for the delay. I have run into unrelated(?) problems and can't produce a build with working USB for some reason. That's probably worthy of a new thread.

On topic, I was using a boot script from the swupdate example layer[1] to switch between A/B root partitions.

Code: Select all

saveenv
fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs
if env exists rpipart;then echo Booting from mmcblk0p${rpipart};else setenv rpipart 2;echo rpipart not set, default to ${rpipart};fi
load mmc 0:${rpipart} ${kernel_addr_r} boot/@@KERNEL_IMAGETYPE@@
setenv bootargs "${bootargs} root=/dev/mmcblk0p${rpipart}"
@@KERNEL_BOOTCMD@@ ${kernel_addr_r} - ${fdt_addr}

I had suspected the "saveenv" call was writing out the MAC/serial, pinning it to the first device that ran that sd card and causing the confusion as I moved the sd card between my test devices. Unfortunately my build troubles started before I could test that theory.

[1]: https://github.com/sbabic/meta-swupdate ... oot.cmd.in