Re: [PATCH v2] tlv: Add tlv_bind_soc_uid mapping

[Jonas Rebmann <jre@pengutronix.de>]

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.

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.

Regards,
Jonas

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