Re: [PATCH v2 1/9] introduce SoC UID

[Sascha Hauer <s.hauer@pengutronix.de>]

On Mon, Nov 17, 2025 at 11:16:34AM +0100, Jonas Rebmann wrote:
> Hi Sascha,
> 
> On 2025-11-17 09:35, Sascha Hauer wrote:
> > Most SoCs have a unique ID (UID) which can be used to identify a
> > particular SoC instance. This is exposed to the environment by some SoC
> > drivers as soc0.serial_number like also done in Linux. The SoC UID can
> > also conveniently be used to generate a unique machine_id on systems
> > with a readonly rootfs. The two usecases require the SoC UID in different
> > formats. While machine_id_set_hashable() takes a binary representation
> > of the SoC UID, soc0.serial_number is a string. The conversion from the
> > binary representation to the string is SoC specific, some SoCs interpret
> > the binary data as a byte array (AM62x for example), others interpret it
> > as words of different lengths in different endianesses (i.MX). Others
> > even print the binary data as decimal (qcom).
> > 
> > Needing a SoC driver for providing the SoC UID is an unlucky choice as
> > some SoCs do not have a SoC driver, but instead read the SoC UID in
> > their eFuse driver in drivers/nvmem (STM32MP bsec). These drivers
> > provide hashable data to generate a machine_id, but do not expose the
> > SoC ID.
> > 
> > This patch introduces barebox_set_soc_uid(). This function provides a
> > new environment variable global.soc_uid which contains the SoC UID.
> > It also passes the SoC UID to machine_id_set_hashable() for generating a
> > machine_id. To accomodate for different string representations of the
> > binary data barebox_set_soc_uid() takes both the binary data and a
> > string in the SoCs preferred format of the same data.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> I wonder if soc_uid is really the global variable we are looking for. I
> understand what we want is a hardware-provided unique ID of a board.
> However boards can have multiple or no SoC UIDs.
> 
> I assume a board with multiple SoCs can have a soc1.serial_number too,
> then having all UIDs provided via the serial_number interface but only a
> single soc_uid global seems confusing to me.
> 
> A SoC or SoM that provides no SoC UID may still provide means of unique
> hardware identification and the global we are introducing here could
> allow us to abstract away from this.
> 
> Can we name this something like hardware_uid to be more flexible about
> its origin?

Right now this is a SoC UID, so I would prefer calling like that.

If a board has zero SoC UIDs, then don't set this variable. I assume
barebox can only run on one SoC at a time and on a board with multiple
SoCs we have multiple barebox instances running with each having its own
SoC UID.

If your SoC doesn't provide a SoC UID then I would recommend not to
overload global.soc_uid with your board specific UID, but provide a
different variable instead.

Currently the last caller of machine_id_set_hashable() wins. I thought
about:

1) Pass some priority to machine_id_set_hashable() and use the data with
   the highest priority
2) Generate a systemd machine_id from all buffers
   machine_id_set_hashable() is called with (in some specific order,
   maybe sort by buffer size first and by memcmp() should multiple
   buffers have the same size)

All these approaches have the problem that the machine_id might change
when new machine_id_set_hashable() providers are added to a new barebox
version.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |