/proc/device-tree/serial-number shows wrong info

[shawaj]

/proc/device-tree/serial-number is hard coded to c3d9b8674f4b94f6

Whereas /proc/cpuinfo shows the correct unique serial.

Can this be easily fixed?

[JeffyCN]

i mostly working on userspace...

from a quick check, it looks like: 1/ the cpuinfo's serialno is from otp nvmem 2/ the device-tree's serialno is from u-boot(march-rockchip/board.c)

so you can try to add logs in u-boot to trace it, likely it got a valid serialno from vendor storage(there's a factory tool to burn it, and mostly used for adb/fastboot), maybe you can try to comment out vendor storage serialno part in board.c

[shawaj]

@JeffyCN can this be fixed on the Rockchip yocto side?

It seems all px30 are effected

[JeffyCN]

as explained above, this doesn't look like a bug to me.

1/ that serial number is mostly used for adb and fastboot, if you want uniq serialno, check cpuinfo. 2/ that serial number would be factory burned one(vendor storage) or the otp one(same as cpuinfo's uniq serial number)

so it seems like you should ask your factory...

if you need it to be uniq, either ask them not to burn serialno in vendor storage, for burn a uniq one or hacl uboot to ignore.that

[JeffyCN]

and absolutely yocto has nothing to do with it.

[JeffyCN]

and of cause, you may also need to add logs in u-boot's board.c to conform that, since i really don't know much about u-boot, i mostly working on userspace things(like gstreamer, weston, xserver)

[shawaj]

@JeffyCN It's not on the board side though as this is only when running via yocto as far as I can tell

And it's not possible to just use the serial from cpuinfo because we are using with balenaCloud which expects the serial number to be in /proc/device-tree/serial-number

Can it be overriden with a yocto layer or some device tree blob?

[shawaj]

It's also not just on this platform. It seems to be all px30.

If you Google c3d9b8674f4b94f6 you will see this in huge number of results as hard coded

[JeffyCN]

as mentioned above, that no is from uboot, the current code is reading from factory flashed no(vendor storage) then otp's uniq no. then it will set the dts and kernel cmdline, which is for android adb and fastboot mostly.

i've provide my suggestions, it has nothing to do with yocto, it's pure uboot and factory flow, please hack your uboot(or there even a config to disable vender storage in uboot) or ask your factory.

[JeffyCN]

if you don't know how to use custom uboot, please check the readme of meta-rockchip

and about factory flow, there's a tool for them to burn serialno and eth mac bt mac hdmi key or something else i guess

that is to allow the customers using their own serialno instead of rockchip's cpu id