[PATCH v2] tlv: Add tlv_bind_soc_uid mapping

[Jan Lübbe]

On Mon, 2025-11-24 at 20:58 +0100, Jonas Rebmann wrote:
> Hi Jan,
> 
> On 2025-11-24 11:35, Sascha Hauer wrote:
> > On Wed, Nov 19, 2025 at 04:15:40PM +0100, Jan Lübbe wrote:
> > > On Tue, 2025-11-18 at 10:57 +0100, Jonas Rebmann wrote:
> > > > On 2025-11-18 10:49, Jonas Rebmann wrote:
> > > > > On 2025-11-18 09:40, Sascha Hauer wrote:
> > > > > To me the big question is: What is a SoC UID?
> > > > > 
> > > > > Is it an arbitrary string that happens to be, for many SoCs composed of
> > > > > [0-9A-F] and efficiently represented in binary in the efuses? Then it
> > > > > feels a bit surprising to me to compare this 'arbitrary vendor-provided
> > > > > string' case-insensitively.
> > > > > 
> > > > > But if we consider this an arbitrary block of binary data, typically
> > > > > looked at in hexadecimal then I suggest we use the raw "bytes"-format I
> > > > > sent an RFC patch for on Nov 12, and compare to
> > > > > barebox_get_soc_uid_bin(). I originally wrote that RFC patch for storing
> > > > > SoC UIDs but had a conversation with Ahmad that led me to view the SoC
> > > > > UID as an arbitrary string. However now that we have
> > > > > barebox_get_soc_uid_bin(), I'm tempted to change my mind.
> > > > 
> > > > I did consider changing this for v2 however in your [PATCH v2 1/9]
> > > > "introduce SoC UID" you mentioned that "Others even print the binary
> > > > data as decimal (qcom).". If we where to use 'raw "bytes"-format' as in
> > > > my RFC, the data YAMLs would have hexadecimal representation and I'm not
> > > > sure if that could get too confusing. At least we could consider to add
> > > > a (mandatory?) YAML-field that specifies the number system.
> > > 
> > > As the UID is normally read from registers or messages exchanged with a security
> > > enclave, each SOC vendor has already defined a binary format. We should just
> > > store that unmodified in the TLV value instead of inventing a custom format.
> > 
> > The format is not custom, it's the format Linux provides in sysfs.
> > 
> > It might be confusing if the SOC UID we use has a different format.
> 
> After further discussion with Sascha and Ahmad, I will stick to
> comparing strings in v3.

Sascha, Jonas and I discussed this again internally after my short vacation.

> As there is neither a kernel interface nor a barebox shell interface to
> read the binary representation of the SoC UID, or at least to read some
> uniform (e.g. always hexadecimal) string representation of the SoC UID,
> this would be too impractical. Instead we're taking care that the
> soc_uid string representation in barebox always matches the
> representation given in the kernel. This way, the serial_number/soc_uid
> values easily read from barebox environment or kernel sysfs can be used
> directly without SoC-specific parsing.
> 
> I would however rename this to `tlv_bind_soc_uid_string` so we can have
> `tlv_bind_soc_uid_bin` in addition if needed later.

One main job of a (project specific) schema [1] is to convert between the
strictly defined binary representation in the encoded TLV and the (perhaps
project specific) human-readable representation. Take for example the
"calibration" format use for analog calibration parameters used in the LXA TAC:
https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/bareboxtlv-generator.py#L350
The schema defines that the binary representation is one or more 4 byte big-
endian IEEE 754 binary32 float. As the human-readable representation, a decimal
number is used.

To follow this approach, we should use the SoC-sepecific binary representation
of the SOC UID in the encoded TLV, as this is strictly defined by the SoC vendor
and can never change over a project's life-time. Different ways to read out the
UID might use different formats: In the case of the AM62L, we have hex from the
kernel's sysfs, hex from the ROM code via UART and binary (at an specific
offset) via DFU. 

The generator and barebox can then translate between the encoded and the human-
readable forms defined in each schema as appropriate for each specific project
and manufacturing workflow. This provides a well-defined and stable format in
the TLV and some necessary flexibility (at runtime) to adjust if external tools
change their formats.

The schema should specify the required UID length and which human readable form
to use (e.g. lower case hex), so that only those inputs are accepted.

Regard,
Jan

[1] https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/schema-example.yaml

-- 
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 |