From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device
Date: Wed, 24 May 2023 15:30:01 +0200 [thread overview]
Message-ID: <33d57180-aa13-4178-86e1-c4cf6ef29a6e@prevas.dk> (raw)
In-Reply-To: <20230515063730.2042715-1-peng.fan@oss.nxp.com>
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
reference manual, which mentions a "UNIQUE_ID[127:64]" at offset 0xe00 -
0xe10 (i.e. bank 40, words 0 and 1).
However, no further mention of these upper bits can be found anywhere in
the RM, or in linux or u-boot, mainline or downstream NXP. Furthermore,
quick experiments on both an imx8mp-evk and a custom imx8mp board
reveals that those words are not locked down (they do seem to have some
contents from the factory, but I can still set more bits in them).
Could someone from NXP please explain what exactly bank 40, words 0 and
1, on imx8mp are for? What do their initial value mean, why are they not
locked down, and why does the RM indicate that they should be part of a
unique_id?
Also, assuming that the RM is just wrong (wouldn't be the first time;
the description of the lower 64 bits is also wonky in its own special
way), an 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?
Rasmus
next prev parent reply other threads:[~2023-05-24 13:30 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 [this message]
2023-05-25 0:01 ` Peng Fan
2023-05-25 7:04 ` Rasmus Villemoes
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=33d57180-aa13-4178-86e1-c4cf6ef29a6e@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®