[PATCH v2 0/2] Add additional globalvar for soc_uid

[PATCH v2 0/2] Add additional globalvar for soc_uid

[Fabian Pflug]

The binary representation was used to compare against, but never exposed
to userspace to query, as the exposed variables could correlate with the
value, but did not.

For example on i.MX8MP the byte order was reversed in comparing
the return value of barebox_get_soc_uid_bin and $global.soc_uid.

The exposed string representation is encoded in a manufacturer-specific
manner, hence for use in scripting, soc_uid_hex should be accessible in
a generic representation.

Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
---
Changes in v2:
- Renamed soc_uid_bin to soc_uid_hex
- Add to MAGICVAR
- removed "is is" in help text
- Updated commit messages
- Link to v1: https://lore.barebox.org/barebox/20260330-v2026-03-0-topic-soc_bin_id-v1-0-11292f75b196@pengutronix.de

---
Fabian Pflug (2):
      common: misc: add soc_uid_hex to globalvar
      i.MX: HAB: update text for HABV4_CSF_UNLOCK_UID

 arch/arm/mach-imx/Kconfig | 11 +++--------
 common/misc.c             |  9 +++++++--
 2 files changed, 10 insertions(+), 10 deletions(-)
---
base-commit: 1d386a53086d28a0c4eda138ae9408a418b97b7e
change-id: 20260330-v2026-03-0-topic-soc_bin_id-d12a84d7b1b5

Best regards,
-- 
Fabian Pflug <f.pflug@pengutronix.de>

[PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Fabian Pflug]

uidstr and uidbuf could be the same, but don't have to be. This results
in uncertainty on what exactly is the current UID used for
machine_set_hashable and to compare against with TLV.

Add an additional global var, that encodes SoC-UID registers in a
manner uniform across SoCs/manufacturers.

This can now be used to feed as data for bound-soc-uid into
`bareboxtlv-generator.py` or as the value for
`CONFIG_HABV4_CSF_UNLOCK_UID`

Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
---
 common/misc.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/common/misc.c b/common/misc.c
index ecf9574f7a..be896706d6 100644
--- a/common/misc.c
+++ b/common/misc.c
@@ -268,6 +268,7 @@ const uuid_t *barebox_get_product_uuid(void)
 BAREBOX_MAGICVAR(global.product.uuid, "SMBIOS-reported product UUID");
 
 static char *soc_uid_str;
+static char *soc_uid_bin_str;
 static void *soc_uid;
 static size_t soc_uid_len;
 
@@ -295,18 +296,22 @@ void barebox_set_soc_uid(const char *uidstr, const void *uidbuf, size_t len)
 	soc_uid = xmemdup(uidbuf, len);
 	soc_uid_len = len;
 
+	soc_uid_bin_str = xzalloc(len * 2 + 1);
+	bin2hex(soc_uid_bin_str, uidbuf, len);
+
 	if (uidstr) {
 		soc_uid_str = xstrdup(uidstr);
 	} else {
-		soc_uid_str = xzalloc(len * 2 + 1);
-		bin2hex(soc_uid_str, uidbuf, len);
+		soc_uid_str = soc_uid_bin_str;
 	}
 
 	machine_id_set_hashable(uidbuf, len);
 
 	globalvar_add_simple_string("soc_uid", &soc_uid_str);
+	globalvar_add_simple_string("soc_uid_hex", &soc_uid_bin_str);
 }
 BAREBOX_MAGICVAR(global.soc_uid, "SoC Unique ID");
+BAREBOX_MAGICVAR(global.soc_uid_hex, "SoC Unique ID (in hex)");
 
 const char *barebox_get_soc_uid(void)
 {

-- 
2.47.3

[PATCH v2 2/2] i.MX: HAB: update text for HABV4_CSF_UNLOCK_UID

[Fabian Pflug]

With the establishment of global.soc_uid_hex, there is no need to look
for the serial number and reverse it.

Also some SoC's will have 128-bit UID's, so the hint to 64-bit is not
correct and should be removed.

Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
---
 arch/arm/mach-imx/Kconfig | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 2e4d1ac80a..cb77d0d5b6 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -918,17 +918,12 @@ config HABV4_CSF_UNLOCK_UID
 	depends on HABV4 && HABV4_CSF_UNLOCK_FIELD_RETURN
 	string "CSF Unlock UID"
 	help
-	  Device specific 64-bit UID required to unlock the field-return
+	  Device specific UID required to unlock the field-return
 	  feature. This value must match the per device UNIQUE_ID fuses.
 
 	  The below example shows the expected format. The UNIQUE_ID is
-	  printed during boot by barebox:
-	    i.MX___ unique ID: 7766554433221100
-	  or it can be queried by Linux via:
-	    - cat /sys/devices/soc0/serial_number
-	      7766554433221100
-
-	  So this value have to be set:
+	  stored in $global.soc_uid_hex, but must be split into bytes.
+	  The soc_uid_hex 0011223344556677 becomes:
 	    - 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
 
 	  Afterwards, the `hab -p -r` command can be used to burn the fuse.

-- 
2.47.3

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Jonas Rebmann]

On 2026-04-15 13:10, Fabian Pflug wrote:
> uidstr and uidbuf could be the same, but don't have to be. This results
> in uncertainty on what exactly is the current UID used for
> machine_set_hashable and to compare against with TLV.
> 
> Add an additional global var, that encodes SoC-UID registers in a
> manner uniform across SoCs/manufacturers.
> 
> This can now be used to feed as data for bound-soc-uid into
> `bareboxtlv-generator.py` or as the value for
> `CONFIG_HABV4_CSF_UNLOCK_UID`
> 
> Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>

Reviewed-by: Jonas Rebmann <jre@pengutronix.de>

Re: [PATCH v2 2/2] i.MX: HAB: update text for HABV4_CSF_UNLOCK_UID

[Jonas Rebmann]

On 2026-04-15 13:10, Fabian Pflug wrote:
> With the establishment of global.soc_uid_hex, there is no need to look
> for the serial number and reverse it.
> 
> Also some SoC's will have 128-bit UID's, so the hint to 64-bit is not
> correct and should be removed.
> 
> Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>

Reviewed-by: Jonas Rebmann <jre@pengutronix.de>

Re: [PATCH v2 2/2] i.MX: HAB: update text for HABV4_CSF_UNLOCK_UID

[Sascha Hauer]

Hi Fabian,

On Wed, Apr 15, 2026 at 01:10:22PM +0200, Fabian Pflug wrote:
> With the establishment of global.soc_uid_hex, there is no need to look
> for the serial number and reverse it.
> 
> Also some SoC's will have 128-bit UID's, so the hint to 64-bit is not
> correct and should be removed.
> 
> Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> ---
>  arch/arm/mach-imx/Kconfig | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 2e4d1ac80a..cb77d0d5b6 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -918,17 +918,12 @@ config HABV4_CSF_UNLOCK_UID
>  	depends on HABV4 && HABV4_CSF_UNLOCK_FIELD_RETURN
>  	string "CSF Unlock UID"
>  	help
> -	  Device specific 64-bit UID required to unlock the field-return
> +	  Device specific UID required to unlock the field-return
>  	  feature. This value must match the per device UNIQUE_ID fuses.
>  
>  	  The below example shows the expected format. The UNIQUE_ID is
> -	  printed during boot by barebox:
> -	    i.MX___ unique ID: 7766554433221100
> -	  or it can be queried by Linux via:
> -	    - cat /sys/devices/soc0/serial_number
> -	      7766554433221100

I don't think we should remove this. For some people it might be more
convenient to read the SoC UID from Linux or to parse it from the
barebox console log.

> -
> -	  So this value have to be set:
> +	  stored in $global.soc_uid_hex, but must be split into bytes.
> +	  The soc_uid_hex 0011223344556677 becomes:
>  	    - 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77

By using soc_uid_hex we no longer have to reverse the byte order, but
still have to reformat it (split into bytes, add 0x and comma). I think
this little convenience gain is not worth the change really.

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 |

Re: [PATCH v2 2/2] i.MX: HAB: update text for HABV4_CSF_UNLOCK_UID

[Fabian Pflug]

What about TLV data?

There to use the SOC_UID, the value printed during boot has to be reveresed, or if not on i.MX6/8, then I have no idea
how the field looks like, but soc_uid_hex, would always give the right value in the right format.

I can add a new version with the linux examples included, but would still like to establish the soc_uid_hex value or
change the content of soc_uid to what is currently in soc_uid_hex.

Kind regards
Fabian Pflug

On Wed, 2026-04-22 at 09:43 +0200, Sascha Hauer wrote:
> Hi Fabian,
> 
> On Wed, Apr 15, 2026 at 01:10:22PM +0200, Fabian Pflug wrote:
> > With the establishment of global.soc_uid_hex, there is no need to look
> > for the serial number and reverse it.
> > 
> > Also some SoC's will have 128-bit UID's, so the hint to 64-bit is not
> > correct and should be removed.
> > 
> > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > ---
> >  arch/arm/mach-imx/Kconfig | 11 +++--------
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 2e4d1ac80a..cb77d0d5b6 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -918,17 +918,12 @@ config HABV4_CSF_UNLOCK_UID
> >  	depends on HABV4 && HABV4_CSF_UNLOCK_FIELD_RETURN
> >  	string "CSF Unlock UID"
> >  	help
> > -	  Device specific 64-bit UID required to unlock the field-return
> > +	  Device specific UID required to unlock the field-return
> >  	  feature. This value must match the per device UNIQUE_ID fuses.
> >  
> >  	  The below example shows the expected format. The UNIQUE_ID is
> > -	  printed during boot by barebox:
> > -	    i.MX___ unique ID: 7766554433221100
> > -	  or it can be queried by Linux via:
> > -	    - cat /sys/devices/soc0/serial_number
> > -	      7766554433221100
> 
> I don't think we should remove this. For some people it might be more
> convenient to read the SoC UID from Linux or to parse it from the
> barebox console log.
> 
> > -
> > -	  So this value have to be set:
> > +	  stored in $global.soc_uid_hex, but must be split into bytes.
> > +	  The soc_uid_hex 0011223344556677 becomes:
> >  	    - 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
> 
> By using soc_uid_hex we no longer have to reverse the byte order, but
> still have to reformat it (split into bytes, add 0x and comma). I think
> this little convenience gain is not worth the change really.
> 
> Sascha

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Sascha Hauer]

On Wed, Apr 15, 2026 at 01:10:21PM +0200, Fabian Pflug wrote:
> uidstr and uidbuf could be the same, but don't have to be. This results
> in uncertainty on what exactly is the current UID used for
> machine_set_hashable and to compare against with TLV.
> 
> Add an additional global var, that encodes SoC-UID registers in a
> manner uniform across SoCs/manufacturers.
> 
> This can now be used to feed as data for bound-soc-uid into
> `bareboxtlv-generator.py` or as the value for
> `CONFIG_HABV4_CSF_UNLOCK_UID`
> 
> Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> ---
>  common/misc.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/common/misc.c b/common/misc.c
> index ecf9574f7a..be896706d6 100644
> --- a/common/misc.c
> +++ b/common/misc.c
> @@ -268,6 +268,7 @@ const uuid_t *barebox_get_product_uuid(void)
>  BAREBOX_MAGICVAR(global.product.uuid, "SMBIOS-reported product UUID");
>  
>  static char *soc_uid_str;
> +static char *soc_uid_bin_str;
>  static void *soc_uid;
>  static size_t soc_uid_len;
>  
> @@ -295,18 +296,22 @@ void barebox_set_soc_uid(const char *uidstr, const void *uidbuf, size_t len)
>  	soc_uid = xmemdup(uidbuf, len);
>  	soc_uid_len = len;
>  
> +	soc_uid_bin_str = xzalloc(len * 2 + 1);
> +	bin2hex(soc_uid_bin_str, uidbuf, len);
> +
>  	if (uidstr) {
>  		soc_uid_str = xstrdup(uidstr);
>  	} else {
> -		soc_uid_str = xzalloc(len * 2 + 1);
> -		bin2hex(soc_uid_str, uidbuf, len);
> +		soc_uid_str = soc_uid_bin_str;
>  	}
>  
>  	machine_id_set_hashable(uidbuf, len);
>  
>  	globalvar_add_simple_string("soc_uid", &soc_uid_str);
> +	globalvar_add_simple_string("soc_uid_hex", &soc_uid_bin_str);

barebox_set_soc_uid() takes two arguments, the raw SoC UID data and a
SoC specific string representation of that data. It's unfortunate that
you need two different interpretations of the raw data on i.MX, one to
match the Linux /sys/ format and one to put into the CSF file.

Anyway, just adding a second string representation not only for i.MX,
but also for all other SoCs is rather confusing. For the i.MX field
return case we could also add a hab command option or a i.MX specific
globalvar which is exactly described as "SoC UID in the format the CSF
needs"

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 |

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Fabian Pflug]

On Wed, 2026-04-22 at 09:56 +0200, Sascha Hauer wrote:
> On Wed, Apr 15, 2026 at 01:10:21PM +0200, Fabian Pflug wrote:
> > uidstr and uidbuf could be the same, but don't have to be. This results
> > in uncertainty on what exactly is the current UID used for
> > machine_set_hashable and to compare against with TLV.
> > 
> > Add an additional global var, that encodes SoC-UID registers in a
> > manner uniform across SoCs/manufacturers.
> > 
> > This can now be used to feed as data for bound-soc-uid into
> > `bareboxtlv-generator.py` or as the value for
> > `CONFIG_HABV4_CSF_UNLOCK_UID`
> > 
> > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > ---
> >  common/misc.c | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/common/misc.c b/common/misc.c
> > index ecf9574f7a..be896706d6 100644
> > --- a/common/misc.c
> > +++ b/common/misc.c
> > @@ -268,6 +268,7 @@ const uuid_t *barebox_get_product_uuid(void)
> >  BAREBOX_MAGICVAR(global.product.uuid, "SMBIOS-reported product UUID");
> >  
> >  static char *soc_uid_str;
> > +static char *soc_uid_bin_str;
> >  static void *soc_uid;
> >  static size_t soc_uid_len;
> >  
> > @@ -295,18 +296,22 @@ void barebox_set_soc_uid(const char *uidstr, const void *uidbuf, size_t len)
> >  	soc_uid = xmemdup(uidbuf, len);
> >  	soc_uid_len = len;
> >  
> > +	soc_uid_bin_str = xzalloc(len * 2 + 1);
> > +	bin2hex(soc_uid_bin_str, uidbuf, len);
> > +
> >  	if (uidstr) {
> >  		soc_uid_str = xstrdup(uidstr);
> >  	} else {
> > -		soc_uid_str = xzalloc(len * 2 + 1);
> > -		bin2hex(soc_uid_str, uidbuf, len);
> > +		soc_uid_str = soc_uid_bin_str;
> >  	}
> >  
> >  	machine_id_set_hashable(uidbuf, len);
> >  
> >  	globalvar_add_simple_string("soc_uid", &soc_uid_str);
> > +	globalvar_add_simple_string("soc_uid_hex", &soc_uid_bin_str);
> 
> barebox_set_soc_uid() takes two arguments, the raw SoC UID data and a
> SoC specific string representation of that data. It's unfortunate that
> you need two different interpretations of the raw data on i.MX, one to
> match the Linux /sys/ format and one to put into the CSF file.
> 
> Anyway, just adding a second string representation not only for i.MX,
> but also for all other SoCs is rather confusing. For the i.MX field
> return case we could also add a hab command option or a i.MX specific
> globalvar which is exactly described as "SoC UID in the format the CSF
> needs"

Please don't get confused. This is an additional benefit for the CSF in i.MX. The main focus here is to have a string
representation, that can be used in TLV generation, with the script in 
https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/bareboxtlv-generator.py

The value 
0x0024, bound-soc-uid, "Reject TLV if supplied binary data does not match UID SoC register"
https://github.com/barebox/barebox/blob/v2026.04.0/common/tlv/barebox.c#L200

Needs this representation for all vendors, not just i.MX.
And since the values for soc_bin and uidstr can differ greatly, it is very soc specific on what value to use in the
https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/data-example.yaml

This patch tries to fix it, by giving a value, that can just be copied to TLC data.yaml

Kind regards
Fabian Pflug

> 
> Sascha

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Sascha Hauer]

On Wed, Apr 22, 2026 at 10:14:11AM +0200, Fabian Pflug wrote:
> On Wed, 2026-04-22 at 09:56 +0200, Sascha Hauer wrote:
> > On Wed, Apr 15, 2026 at 01:10:21PM +0200, Fabian Pflug wrote:
> > > uidstr and uidbuf could be the same, but don't have to be. This results
> > > in uncertainty on what exactly is the current UID used for
> > > machine_set_hashable and to compare against with TLV.
> > > 
> > > Add an additional global var, that encodes SoC-UID registers in a
> > > manner uniform across SoCs/manufacturers.
> > > 
> > > This can now be used to feed as data for bound-soc-uid into
> > > `bareboxtlv-generator.py` or as the value for
> > > `CONFIG_HABV4_CSF_UNLOCK_UID`
> > > 
> > > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > > ---
> > >  common/misc.c | 9 +++++++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/common/misc.c b/common/misc.c
> > > index ecf9574f7a..be896706d6 100644
> > > --- a/common/misc.c
> > > +++ b/common/misc.c
> > > @@ -268,6 +268,7 @@ const uuid_t *barebox_get_product_uuid(void)
> > >  BAREBOX_MAGICVAR(global.product.uuid, "SMBIOS-reported product UUID");
> > >  
> > >  static char *soc_uid_str;
> > > +static char *soc_uid_bin_str;
> > >  static void *soc_uid;
> > >  static size_t soc_uid_len;
> > >  
> > > @@ -295,18 +296,22 @@ void barebox_set_soc_uid(const char *uidstr, const void *uidbuf, size_t len)
> > >  	soc_uid = xmemdup(uidbuf, len);
> > >  	soc_uid_len = len;
> > >  
> > > +	soc_uid_bin_str = xzalloc(len * 2 + 1);
> > > +	bin2hex(soc_uid_bin_str, uidbuf, len);
> > > +
> > >  	if (uidstr) {
> > >  		soc_uid_str = xstrdup(uidstr);
> > >  	} else {
> > > -		soc_uid_str = xzalloc(len * 2 + 1);
> > > -		bin2hex(soc_uid_str, uidbuf, len);
> > > +		soc_uid_str = soc_uid_bin_str;
> > >  	}
> > >  
> > >  	machine_id_set_hashable(uidbuf, len);
> > >  
> > >  	globalvar_add_simple_string("soc_uid", &soc_uid_str);
> > > +	globalvar_add_simple_string("soc_uid_hex", &soc_uid_bin_str);
> > 
> > barebox_set_soc_uid() takes two arguments, the raw SoC UID data and a
> > SoC specific string representation of that data. It's unfortunate that
> > you need two different interpretations of the raw data on i.MX, one to
> > match the Linux /sys/ format and one to put into the CSF file.
> > 
> > Anyway, just adding a second string representation not only for i.MX,
> > but also for all other SoCs is rather confusing. For the i.MX field
> > return case we could also add a hab command option or a i.MX specific
> > globalvar which is exactly described as "SoC UID in the format the CSF
> > needs"
> 
> Please don't get confused. This is an additional benefit for the CSF in i.MX. The main focus here is to have a string
> representation, that can be used in TLV generation, with the script in 
> https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/bareboxtlv-generator.py
> 
> The value 
> 0x0024, bound-soc-uid, "Reject TLV if supplied binary data does not match UID SoC register"
> https://github.com/barebox/barebox/blob/v2026.04.0/common/tlv/barebox.c#L200
> 
> Needs this representation for all vendors, not just i.MX.
> And since the values for soc_bin and uidstr can differ greatly, it is very soc specific on what value to use in the
> https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/data-example.yaml
> 
> This patch tries to fix it, by giving a value, that can just be copied to TLC data.yaml

Ok, I can much better buy TLV support as an argument.

Please add a

BAREBOX_MAGICVAR(global.soc_uid_hex,
          "byte array representation of the raw SoC UID");

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 |

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Fabian Pflug]

On Wed, 2026-04-22 at 10:25 +0200, Sascha Hauer wrote:
> On Wed, Apr 22, 2026 at 10:14:11AM +0200, Fabian Pflug wrote:
> > On Wed, 2026-04-22 at 09:56 +0200, Sascha Hauer wrote:
> > > On Wed, Apr 15, 2026 at 01:10:21PM +0200, Fabian Pflug wrote:
> > > > uidstr and uidbuf could be the same, but don't have to be. This results
> > > > in uncertainty on what exactly is the current UID used for
> > > > machine_set_hashable and to compare against with TLV.
> > > > 
> > > > Add an additional global var, that encodes SoC-UID registers in a
> > > > manner uniform across SoCs/manufacturers.
> > > > 
> > > > This can now be used to feed as data for bound-soc-uid into
> > > > `bareboxtlv-generator.py` or as the value for
> > > > `CONFIG_HABV4_CSF_UNLOCK_UID`
> > > > 
> > > > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > > > ---
> > > >  common/misc.c | 9 +++++++--
> > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/common/misc.c b/common/misc.c
> > > > index ecf9574f7a..be896706d6 100644
> > > > --- a/common/misc.c
> > > > +++ b/common/misc.c
> > > > @@ -268,6 +268,7 @@ const uuid_t *barebox_get_product_uuid(void)
> > > >  BAREBOX_MAGICVAR(global.product.uuid, "SMBIOS-reported product UUID");
> > > >  
> > > >  static char *soc_uid_str;
> > > > +static char *soc_uid_bin_str;
> > > >  static void *soc_uid;
> > > >  static size_t soc_uid_len;
> > > >  
> > > > @@ -295,18 +296,22 @@ void barebox_set_soc_uid(const char *uidstr, const void *uidbuf, size_t len)
> > > >  	soc_uid = xmemdup(uidbuf, len);
> > > >  	soc_uid_len = len;
> > > >  
> > > > +	soc_uid_bin_str = xzalloc(len * 2 + 1);
> > > > +	bin2hex(soc_uid_bin_str, uidbuf, len);
> > > > +
> > > >  	if (uidstr) {
> > > >  		soc_uid_str = xstrdup(uidstr);
> > > >  	} else {
> > > > -		soc_uid_str = xzalloc(len * 2 + 1);
> > > > -		bin2hex(soc_uid_str, uidbuf, len);
> > > > +		soc_uid_str = soc_uid_bin_str;
> > > >  	}
> > > >  
> > > >  	machine_id_set_hashable(uidbuf, len);
> > > >  
> > > >  	globalvar_add_simple_string("soc_uid", &soc_uid_str);
> > > > +	globalvar_add_simple_string("soc_uid_hex", &soc_uid_bin_str);
> > > 
> > > barebox_set_soc_uid() takes two arguments, the raw SoC UID data and a
> > > SoC specific string representation of that data. It's unfortunate that
> > > you need two different interpretations of the raw data on i.MX, one to
> > > match the Linux /sys/ format and one to put into the CSF file.
> > > 
> > > Anyway, just adding a second string representation not only for i.MX,
> > > but also for all other SoCs is rather confusing. For the i.MX field
> > > return case we could also add a hab command option or a i.MX specific
> > > globalvar which is exactly described as "SoC UID in the format the CSF
> > > needs"
> > 
> > Please don't get confused. This is an additional benefit for the CSF in i.MX. The main focus here is to have a
> > string
> > representation, that can be used in TLV generation, with the script in 
> > https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/bareboxtlv-generator.py
> > 
> > The value 
> > 0x0024, bound-soc-uid, "Reject TLV if supplied binary data does not match UID SoC register"
> > https://github.com/barebox/barebox/blob/v2026.04.0/common/tlv/barebox.c#L200
> > 
> > Needs this representation for all vendors, not just i.MX.
> > And since the values for soc_bin and uidstr can differ greatly, it is very soc specific on what value to use in the
> > https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/data-example.yaml
> > 
> > This patch tries to fix it, by giving a value, that can just be copied to TLC data.yaml
> 
> Ok, I can much better buy TLV support as an argument.
> 
> Please add a
> 
> BAREBOX_MAGICVAR(global.soc_uid_hex,
>           "byte array representation of the raw SoC UID");

There already is

BAREBOX_MAGICVAR(global.soc_uid_hex, "SoC Unique ID (in hex)");

And since it is a single value and not a byte array, I think byte array is the wrong representation.
Using a byte-array for TLV does not work with the TLV tooling. This expects a single value.

It has to be converted to a byte array for CSF, as described in the helptext for HABV4_CSF_UNLOCK_UID

Different tooling, different representation.

Fabian

> 
> Sascha

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Sascha Hauer]

On Wed, Apr 22, 2026 at 10:52:34AM +0200, Fabian Pflug wrote:
> On Wed, 2026-04-22 at 10:25 +0200, Sascha Hauer wrote:
> > On Wed, Apr 22, 2026 at 10:14:11AM +0200, Fabian Pflug wrote:
> > > On Wed, 2026-04-22 at 09:56 +0200, Sascha Hauer wrote:
> > > > On Wed, Apr 15, 2026 at 01:10:21PM +0200, Fabian Pflug wrote:
> > > > > uidstr and uidbuf could be the same, but don't have to be. This results
> > > > > in uncertainty on what exactly is the current UID used for
> > > > > machine_set_hashable and to compare against with TLV.
> > > > > 
> > > > > Add an additional global var, that encodes SoC-UID registers in a
> > > > > manner uniform across SoCs/manufacturers.
> > > > > 
> > > > > This can now be used to feed as data for bound-soc-uid into
> > > > > `bareboxtlv-generator.py` or as the value for
> > > > > `CONFIG_HABV4_CSF_UNLOCK_UID`
> > > > > 
> > > > > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > > > > ---
> > > > >  common/misc.c | 9 +++++++--
> > > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/common/misc.c b/common/misc.c
> > > > > index ecf9574f7a..be896706d6 100644
> > > > > --- a/common/misc.c
> > > > > +++ b/common/misc.c
> > > > > @@ -268,6 +268,7 @@ const uuid_t *barebox_get_product_uuid(void)
> > > > >  BAREBOX_MAGICVAR(global.product.uuid, "SMBIOS-reported product UUID");
> > > > >  
> > > > >  static char *soc_uid_str;
> > > > > +static char *soc_uid_bin_str;
> > > > >  static void *soc_uid;
> > > > >  static size_t soc_uid_len;
> > > > >  
> > > > > @@ -295,18 +296,22 @@ void barebox_set_soc_uid(const char *uidstr, const void *uidbuf, size_t len)
> > > > >  	soc_uid = xmemdup(uidbuf, len);
> > > > >  	soc_uid_len = len;
> > > > >  
> > > > > +	soc_uid_bin_str = xzalloc(len * 2 + 1);
> > > > > +	bin2hex(soc_uid_bin_str, uidbuf, len);
> > > > > +
> > > > >  	if (uidstr) {
> > > > >  		soc_uid_str = xstrdup(uidstr);
> > > > >  	} else {
> > > > > -		soc_uid_str = xzalloc(len * 2 + 1);
> > > > > -		bin2hex(soc_uid_str, uidbuf, len);
> > > > > +		soc_uid_str = soc_uid_bin_str;
> > > > >  	}
> > > > >  
> > > > >  	machine_id_set_hashable(uidbuf, len);
> > > > >  
> > > > >  	globalvar_add_simple_string("soc_uid", &soc_uid_str);
> > > > > +	globalvar_add_simple_string("soc_uid_hex", &soc_uid_bin_str);
> > > > 
> > > > barebox_set_soc_uid() takes two arguments, the raw SoC UID data and a
> > > > SoC specific string representation of that data. It's unfortunate that
> > > > you need two different interpretations of the raw data on i.MX, one to
> > > > match the Linux /sys/ format and one to put into the CSF file.
> > > > 
> > > > Anyway, just adding a second string representation not only for i.MX,
> > > > but also for all other SoCs is rather confusing. For the i.MX field
> > > > return case we could also add a hab command option or a i.MX specific
> > > > globalvar which is exactly described as "SoC UID in the format the CSF
> > > > needs"
> > > 
> > > Please don't get confused. This is an additional benefit for the CSF in i.MX. The main focus here is to have a
> > > string
> > > representation, that can be used in TLV generation, with the script in 
> > > https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/bareboxtlv-generator.py
> > > 
> > > The value 
> > > 0x0024, bound-soc-uid, "Reject TLV if supplied binary data does not match UID SoC register"
> > > https://github.com/barebox/barebox/blob/v2026.04.0/common/tlv/barebox.c#L200
> > > 
> > > Needs this representation for all vendors, not just i.MX.
> > > And since the values for soc_bin and uidstr can differ greatly, it is very soc specific on what value to use in the
> > > https://github.com/barebox/barebox/blob/master/scripts/bareboxtlv-generator/data-example.yaml
> > > 
> > > This patch tries to fix it, by giving a value, that can just be copied to TLC data.yaml
> > 
> > Ok, I can much better buy TLV support as an argument.
> > 
> > Please add a
> > 
> > BAREBOX_MAGICVAR(global.soc_uid_hex,
> >           "byte array representation of the raw SoC UID");
> 
> There already is
> 
> BAREBOX_MAGICVAR(global.soc_uid_hex, "SoC Unique ID (in hex)");
> 
> And since it is a single value and not a byte array, I think byte array is the wrong representation.
> Using a byte-array for TLV does not work with the TLV tooling. This expects a single value.

You are right, byte array is not the correct term here. What I wanted to
make clear is that it is the raw buffer content with the first byte in
the buffer being the first two digits of the string, just to make the
difference between these two clearer:

global.soc_uid=0011223344556677		"SoC Unique ID"
global.soc_uid_hex=7766554433221100	"SoC Unique ID (in hex)"

Both are obviously hex values, which one means what?

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 |

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Fabian Pflug]

On Wed, 2026-04-22 at 11:16 +0200, Sascha Hauer wrote:
> On Wed, Apr 22, 2026 at 10:52:34AM +0200, Fabian Pflug wrote:
> > 
> > There already is
> > 
> > BAREBOX_MAGICVAR(global.soc_uid_hex, "SoC Unique ID (in hex)");
> > 
> > And since it is a single value and not a byte array, I think byte array is the wrong representation.
> > Using a byte-array for TLV does not work with the TLV tooling. This expects a single value.
> 
> You are right, byte array is not the correct term here. What I wanted to
> make clear is that it is the raw buffer content with the first byte in
> the buffer being the first two digits of the string, just to make the
> difference between these two clearer:
> 
> global.soc_uid=0011223344556677		"SoC Unique ID"
> global.soc_uid_hex=7766554433221100	"SoC Unique ID (in hex)"
> 
> Both are obviously hex values, which one means what?

maybe "Raw SoC Unique ID (vendor independent representation)"?

> 
> Sascha

Re: [PATCH v2 1/2] common: misc: add soc_uid_hex to globalvar

[Sascha Hauer]

On Wed, Apr 22, 2026 at 11:19:02AM +0200, Fabian Pflug wrote:
> On Wed, 2026-04-22 at 11:16 +0200, Sascha Hauer wrote:
> > On Wed, Apr 22, 2026 at 10:52:34AM +0200, Fabian Pflug wrote:
> > > 
> > > There already is
> > > 
> > > BAREBOX_MAGICVAR(global.soc_uid_hex, "SoC Unique ID (in hex)");
> > > 
> > > And since it is a single value and not a byte array, I think byte array is the wrong representation.
> > > Using a byte-array for TLV does not work with the TLV tooling. This expects a single value.
> > 
> > You are right, byte array is not the correct term here. What I wanted to
> > make clear is that it is the raw buffer content with the first byte in
> > the buffer being the first two digits of the string, just to make the
> > difference between these two clearer:
> > 
> > global.soc_uid=0011223344556677		"SoC Unique ID"
> > global.soc_uid_hex=7766554433221100	"SoC Unique ID (in hex)"
> > 
> > Both are obviously hex values, which one means what?
> 
> maybe "Raw SoC Unique ID (vendor independent representation)"?

I think

"Raw SoC Unique ID representation"

is enough. It's not necessarily the vendors that made up the Linux representation.

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 |

Re: [PATCH v2 2/2] i.MX: HAB: update text for HABV4_CSF_UNLOCK_UID

[Jonas Rebmann]

Hi,

On 2026-04-22 09:43, Sascha Hauer wrote:
> Hi Fabian,
> 
> On Wed, Apr 15, 2026 at 01:10:22PM +0200, Fabian Pflug wrote:
>> With the establishment of global.soc_uid_hex, there is no need to look
>> for the serial number and reverse it.
>>
>> Also some SoC's will have 128-bit UID's, so the hint to 64-bit is not
>> correct and should be removed.
>>
>> Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
>> ---
>>   arch/arm/mach-imx/Kconfig | 11 +++--------
>>   1 file changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
>> index 2e4d1ac80a..cb77d0d5b6 100644
>> --- a/arch/arm/mach-imx/Kconfig
>> +++ b/arch/arm/mach-imx/Kconfig
>> @@ -918,17 +918,12 @@ config HABV4_CSF_UNLOCK_UID
>>   	depends on HABV4 && HABV4_CSF_UNLOCK_FIELD_RETURN
>>   	string "CSF Unlock UID"
>>   	help
>> -	  Device specific 64-bit UID required to unlock the field-return
>> +	  Device specific UID required to unlock the field-return
>>   	  feature. This value must match the per device UNIQUE_ID fuses.
>>   
>>   	  The below example shows the expected format. The UNIQUE_ID is
>> -	  printed during boot by barebox:
>> -	    i.MX___ unique ID: 7766554433221100
>> -	  or it can be queried by Linux via:
>> -	    - cat /sys/devices/soc0/serial_number
>> -	      7766554433221100
> 
> I don't think we should remove this. For some people it might be more
> convenient to read the SoC UID from Linux or to parse it from the
> barebox console log.

If instructions of reversing /sys/devices/soc0/serial_number are kept, I
suggest to indicate that it's Linux' that prints them in reverse on
i.MX. `drivers/soc/imx/soc-imx8m.c` and `soc-imx.c` flat out present the
SoC UID in reverse order, at least consistently across i.MX SoCs.

There is an unambiguous order of the byteorder in the registers; and for
reasons beyond my comprehension (inattention?) it was chosen for the
kernel to print them uid[16],uid[15],uid[14],... Although the vendor
seems to do the obvious and expect uid[0],uid[1],uid[2],...

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    |