mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Peng Fan <peng.fan@nxp.com>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
Cc: "kernel@pengutronix.de" <kernel@pengutronix.de>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device
Date: Thu, 25 May 2023 09:04:39 +0200	[thread overview]
Message-ID: <fe5e2b36-6a8e-656c-a4a6-13a47f4871af@prevas.dk> (raw)
In-Reply-To: <DU0PR04MB94170FE393AEE4A86ACE386588469@DU0PR04MB9417.eurprd04.prod.outlook.com>

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@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://community.nxp.com/t5/i-MX-Processors/Question-about-UID-UNIQUE-ID-of-i-MX8MP/m-p/1582383#M200077)
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?

Rasmus


  reply	other threads:[~2023-05-25  7:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15  6:37 Peng Fan (OSS)
2023-05-24 13:30 ` Rasmus Villemoes
2023-05-25  0:01   ` Peng Fan
2023-05-25  7:04     ` Rasmus Villemoes [this message]
2023-05-25  8:30       ` Peng Fan
2023-05-27  8:20   ` Shawn Guo
2023-05-29  3:33     ` Peng Fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe5e2b36-6a8e-656c-a4a6-13a47f4871af@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®