[PATCH V3] soc: imx: support i.MX93 soc device

[Peng Fan]

> Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device
> 
> On 25/05/2023 02.01, Peng Fan wrote:
> >> Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device
> >>
> >> On 15/05/2023 08.37, Peng Fan (OSS) wrote:
> >>> From: Peng Fan <peng.fan at nxp.com>
> >>>
> >>> i.MX93 Device Unique ID(UID) is in eFuse that could be read through
> >>> OCOTP Fuse Shadow Block. i.MX93 UID is 128 bits long, so introduce
> >>> soc_uid_high to indicate the higher 64bits.
> >>
> >> So apparently, the imx8mp also has 128 bits, at least according to
> >> the
> >
> > It is 64bits. The RM maybe wrong.
> 
> OK. I assume you've raised a ticket internally with the documentation team
> to get that fixed?
> 
> And while you're at it, could you draw their attention to the lower bits as
> well:
> 
> 0x420[10:0] UNIQUE_ID[42:0] 43
> 0x430[15:11] UNIQUE_ID[47:43] 5
> 0x430[23:16] UNIQUE_ID[55:48] 8
> 0x430[31:24] UNIQUE_ID[63:56] 8
> 
> I mean, it's a really amazing piece of hardware that manages to cram 43 bits
> of information into a 32 bit word.
> 
> >> reference manual, which mentions a "UNIQUE_ID[127:64]" at offset
> >> 0xe00 -
> >> 0xe10 (i.e. bank 40, words 0 and 1).
> >
> > Which chatper?
> >>
> 
> In my copy, which identifies as "i.MX 8M Plus Applications Processor
> Reference Manual, Rev. 1, 06/2021", it's in Table 6-35, page 823.
> 
> 
> >> obvious follow-up question is: Are the currently exposed
> >> (lower) 64 bits unique among all imx8mp SOCs, i.e. does those 64 bits
> >> by themselves actually work as a uid?
> >
> > Just as what the driver indicates, UID is at register address 0x420
> and 0x430.
> 
> So, for the record, for the iMX8MP, the SOC UID consists of precisely those
> 64 bits found in those two words. And no two iMX8MPs ever produced will
> have the same value. OK. Except:
> 
> > For bank 0x40, I could not reveal information if RM or Secure RM not
> > say something.
> >
> > You could raise tickets in community.nxp.com to ask people follow up
> > on RM issue or else.
> 
> Very interesting, though, that somebody else tried to do just that
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
> munity.nxp.com%2Ft5%2Fi-MX-Processors%2FQuestion-about-UID-
> UNIQUE-ID-of-i-MX8MP%2Fm-
> p%2F1582383%23M200077&data=05%7C01%7Cpeng.fan%40nxp.com%7Ce
> e14840685854a192dc008db5cee5230%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C638205950874432380%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&sdata=fEXtlp0UTJjo8GGpdqqRurJd3yfamxZmiHkI4Zs
> MKMo%3D&reserved=0)
> and have unambiguously been told by "joanxie" from  NXP TechSupport
> 
>   refer to the reference manual, lower 64bits from 0x420[10:0]-
> 0x430[11:31]and higher 64bits from 0xE00-0xE10
> 
> and later
> 
>   the higher 64 bits thus bank 40 word 0 and bank40 word1.
> 
> and again
> 
>   since this soc uses 128bits as UID, try to use 128bits
> 
> But you are clearly stating the opposite, that bank 40, words 0 and 1, do not
> form part of the UID, a statement supported by the experimental fact that
> those words are not locked down from the factory.
> 
> Apart from the still unanswered question about what those two words then
> actually contain, represent and/or are used for, this leaves me with yet
> another question:
> 
> - What's the value of asking questions at community.nxp.com if the answers
> one can expect to get are not rooted in reality?
[Peng Fan] 

Sorry, I am wrong, RM is correct, I overlooked the fuse at address 0xe00.

Regards,
Peng.

> 
> Rasmus