Message ID | 20230515063730.2042715-1-peng.fan@oss.nxp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp6710109vqo; Sun, 14 May 2023 23:40:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5wC4YtljNld8lT6NS7Av+//bjDnWUAPzNeLNQiM33+DfNI54n/zZCjv9lDg2AbgJCREe41 X-Received: by 2002:a05:6a20:9152:b0:e5:58e6:be37 with SMTP id x18-20020a056a20915200b000e558e6be37mr37812922pzc.61.1684132806181; Sun, 14 May 2023 23:40:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1684132806; cv=pass; d=google.com; s=arc-20160816; b=d44N2ZJMrdBKVjvIfB3UmD9iDSqNj7+Q+W2QwSkQpi3588i1+K/tYbEF5P+b4lPDDf vLteaj2tdSgCp6rUJwm1HVO+zg38Bkg9ljfINYbYP6KjKcBh5+wsjSblM/sLQLY318cn 0nq0HLKuLtset1k1vf2MnbR+Q4g4rjQnIul7DgTV5z+KRwThgrb5ScQQGwFb/CKFFWI6 m1/jGiqbCDw3FE8U8MZxx4O4INDnSYZshCgOUhG3obpOjxqL/iGkCBsClTTAjxXtOpVr ywskfoxovrI8tPZ+6CAbcPyk5uEmaNp/eoGkee17uUZHN/6q6hCyOrqQZ1FbHt6kbTs/ Nykg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=OVSR3Z3j8fIFhQix6rGhA5lhkfFMlj6PAJG+63VNUcQ=; b=etN5aS/54jsnH+/XZk7hlWdxQtQnl0sKGy4WrnUVyjtIxmZZ/b4kGTNn3T6EwKPxbc 9Rms7abThEvkN3LpEdCJH4IFiuLN1WgPJ8nN6i8F+u0dLQs+GZRY6sDfEU+SFgzA3zBD 3CRC0o5gjgSIUW6AfoKGP/ZgcZh6awcbLT2NP1xKCcy2hWKPPt1TO/esWfvc2njUbZpE I6eqkiHzH9gOYDHqD9u1thoStmBNTLxxSVJttb+I9uHwphlnGilXxF5zt5LGYRFN4QWq 0XhIIp06l0apVYdF7rv9HPvx/SkXuGRjN4sp/5wgpCPvC5DOjiinXtN8gLhLzgUOYqdo Nkhw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@NXP1.onmicrosoft.com header.s=selector2-NXP1-onmicrosoft-com header.b=NNCcLvbD; arc=pass (i=1 spf=pass spfdomain=oss.nxp.com dkim=pass dkdomain=oss.nxp.com dmarc=pass fromdomain=oss.nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p8-20020a17090a930800b00247ad6e4188si27947266pjo.51.2023.05.14.23.39.54; Sun, 14 May 2023 23:40:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@NXP1.onmicrosoft.com header.s=selector2-NXP1-onmicrosoft-com header.b=NNCcLvbD; arc=pass (i=1 spf=pass spfdomain=oss.nxp.com dkim=pass dkdomain=oss.nxp.com dmarc=pass fromdomain=oss.nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239768AbjEOGcg (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Mon, 15 May 2023 02:32:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239844AbjEOGcf (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 15 May 2023 02:32:35 -0400 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on2054.outbound.protection.outlook.com [40.107.13.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E676A114 for <linux-kernel@vger.kernel.org>; Sun, 14 May 2023 23:32:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XF8bQrTb59bgfcBxfRFN+NxqEasF7vESwFwmDdp8+T9786+Opeu6ca1UpFdGUCMzl3r39JBo4ytai5zT/exNo9Rf238pARzTUCCUfFaRDzzGR+35HkJ9N7L1uajwlQctqfgLaYdwRTbsGJ4e2n6173sESuUBZP/x2WvampJDPK1vcGvXnvDx2pO+JMO7L6LAXlSBHsE6DqrBvqrsvfgmkfvbrkgyQdNujTiQ2x2F5D4yUAFOAtZZYwfI1DEO3KjjPldZzYIXnsI/sqJ7d62wSJ/+Q6UAbQEfyrUHUgPiVBCT/G7Ljvfw2Br9ZVtnxAbIrt4Vwat53Y5UB1TXYq1tCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OVSR3Z3j8fIFhQix6rGhA5lhkfFMlj6PAJG+63VNUcQ=; b=b7Ao0x1R+7uB8/OyF679R/tpaQEiJi+fv0mSwjp6NkcutYBich6J24cJScefowlpHU7Rkkc2M9WoeSdww9l0q/816fB6Bgv6ESawlOEclBybC2OSyD+WD+Ikl3qX0M3CfG7vMnge8FTYA7JWYMHm08LvLcFyFIUWqbqrNftXVj3vSqvxR6dnCyxpCAdr+cmsn7gQJpFLsqqxT0wEFiQFObC14gqYSODU13uerirFmIaG97NHd2EYpnuJyNzY4mNK9PMSnMHAfTF78ccIJkLvj+5T8eqtQDyGIc8Yyfmid3bJR4bgSCO2Cs9Rf0jkzWZ7LMPlVcWrfhbYPgMXkjWazQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com; dkim=pass header.d=oss.nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com; s=selector2-NXP1-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OVSR3Z3j8fIFhQix6rGhA5lhkfFMlj6PAJG+63VNUcQ=; b=NNCcLvbDDYbbFsHGwJhBTlBB1j/PvLTweJYtBBzPPnzt9AxxBwIn4HM6/Goe4+Q9fZxGHbHRacEPPW6JuW5R87QerhWzL/ocgow+47a+gDvpBwbvoY0yz6v82l8Y7541Zfw8OAkc5EAHSdzcA7YeRj1AVAocZKwV6pqvdyqUThE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=oss.nxp.com; Received: from DU0PR04MB9417.eurprd04.prod.outlook.com (2603:10a6:10:358::11) by AS8PR04MB8404.eurprd04.prod.outlook.com (2603:10a6:20b:3f8::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.30; Mon, 15 May 2023 06:32:30 +0000 Received: from DU0PR04MB9417.eurprd04.prod.outlook.com ([fe80::b999:f2c6:a8cc:7b4]) by DU0PR04MB9417.eurprd04.prod.outlook.com ([fe80::b999:f2c6:a8cc:7b4%6]) with mapi id 15.20.6387.030; Mon, 15 May 2023 06:32:30 +0000 From: "Peng Fan (OSS)" <peng.fan@oss.nxp.com> To: 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: [PATCH V3] soc: imx: support i.MX93 soc device Date: Mon, 15 May 2023 14:37:30 +0800 Message-Id: <20230515063730.2042715-1-peng.fan@oss.nxp.com> X-Mailer: git-send-email 2.37.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI1PR02CA0014.apcprd02.prod.outlook.com (2603:1096:4:1f7::9) To DU0PR04MB9417.eurprd04.prod.outlook.com (2603:10a6:10:358::11) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU0PR04MB9417:EE_|AS8PR04MB8404:EE_ X-MS-Office365-Filtering-Correlation-Id: 552af384-f07b-4812-64cc-08db550e287a X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JdRuBCcnetZcTh/Og+MpKQwsn1GbfHsAZoZT8MshhP/twd5/BROiQw4LGnZvP4ZBVM0nQcY0ZdvKRHw7xuKvOj0M/EnmrOGbhZx71Lf0QU5ofcpqQFnKFE0KjWW/DqQ8PBOytMRB7/Qr62EQXMeZ0YXX0YqaP95IR2ZKS7+ly+gi1WqvkfKvoU1fLM+/BSSefckMTPcbqcIG5p39b46WG2h8p4icwbYwcXhnrgS1IJYrrE74mm85uAnNtOdUw55yQscn76wMK1JLB4iOlhL+XZxDYtrVC1x6o752kMwLTIluF5JSUeySDkup5Mjkz3lsUT6GDWGOGqaRNqXJ3pqnfSYeUPncxCazUHhZ3cfdS19U7shuyrAeIivDHEnWX6crBjkP7VQ3dTKOjepSm8ktpcsgUXi7ajazBcoLNgAtUU79KAd6DMDHHSrwjNhcZsyvb0vOYSuwHdleM4qo0yoE1z+YmXYSyACFL6sMcHm3Tlh3KEc+i+AFETpxRJynA7hXP70uFp3f3i+4FhehKJAMN4fffAQ5C0iOOM3y3ALqRnlahKLK8ooZX1usgVI5eITg0eVwh91F6aBu7747b8wxI/oRojBO16azUrq8rVNHyS9dJLS2HF5BDUhTI3JcU265 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9417.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(346002)(396003)(376002)(366004)(39860400002)(136003)(451199021)(52116002)(478600001)(66476007)(66556008)(66946007)(6486002)(86362001)(316002)(4326008)(186003)(1076003)(2616005)(38350700002)(38100700002)(5660300002)(41300700001)(2906002)(6506007)(6512007)(8676002)(8936002)(26005)(83380400001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: MxuRiCzX2x9xqgtxEd0NqHyGTDBLD1XT7Q9qCFesFAY37KBtiOuUB32BLj6FlKP2R/7gf0xgxZr0ijU8vP8zOWt+F3Os+bGPAA+gp4/tOk9WzuWmwgtNuR37KBj/OqeLHippMIxJo3dEPrW5kT/CReasfEMMbxGB2+pdZzcXirY5/liu5Y08OtoZlIcq3lM9+HmWu/7KWzR/vKMJhruxyOYZ9gwpwdKnUN2e7OiNr29M63+6q+Tpqh6+DVpYbjW0AIgyp6PSBqgtlx5qAsfjAAHkEvdNZrd2mWrbMH2uOg7NlNhpy4kRo+E5/cd2habE+2zGAt9MDRNN/ErBenqKpv+O75Q6cAOH2/jaI0CzMJpWnzm/nb3GkqPwoKCyELS1OHgHX90nxr3gR00yEYatsO3nEJnVNjv0YOUAL7GxI/2WivRV9fT8xsR4K783hJzG5LahtNCq+63TW1FH2d2b2FnI6tzSen4dNBYGajuFC8K+AjZBip5jS701qq0MpU4y2g8mJsw7zf6Y9UCkwxJy4GylljFwS2vJ4u9yJ+l2VSj4jfs90c6oLAIn7Qyq4bGqq7F+9vdr7BjuMizO1+BNVa2myRfHgHvdpAtFL5C6I2PHy9vgMu4UIra/kwHPj591Db9akYsaKR2kt9cL+9QT7iWqJKq+4M0B63jEUxXhXdJmw9r2743TnDMDg5j/ltrNSYEyPlE3bi5piA4hjOF9ZnCxs8Ed+Ym/IQ7F2AYV06O7WrYBCG65UDJjpHrzxWqspPSlr5RJXlOlU4fi6Z57skjhNBaFhUc/L8fjwTNfDcM6fUM1u+VxUugTPV1JzcSXfCepRlTk6iIZHDCq3bGE5fthuPYeMCu7vRTKgtiovT4KA4SAlMeTJGYfgq3iP9EEM8s8nUkTDdMndpqSw7uGFm9uFk3RRlByMkMLxdV4eHgDSGpS21ZFIpr+kdsWTpyCxy+xcZ2V8d7WiBAlqn/ZNLO5IyxTDKpckdQBM+/xot32WHDOMkBmuqYONwU0u527Om5tF1GxlDtUPn7nYRLb2R48jZk/6L8imGD8PK3JLhZybwtu76l8dPOSNvtI+piEpzpPJpBDGINgG9Wwv1Vr+zV8tyT+5LpVGgrxDm2FeUVOkp+t0L71K0xpNyoOvXi1kGGN9SPl4Wlpk/tdUSZG3MhzgQ3Ti9Ia9eyZzzLWGGCu2F1sX5jcPRTsJjmuPHp2Fo1ZjSSxKRmuKwk4gE91ipp0CqJ1k2PdTA7sTOhGA2ySz3Hw3AIGVe+BZ8Vt3ccLPCP+1GML3pU6hy48GRe/HrHu6BmXeqHz1H8aoavrFJDkYUxRMpr/glLKn12dgiMdm1PITHVGkf/X21lS60uRziK/CSuFsslCX331k5JYdt0fvBfYeHksdo3s/j8ZarwW/XGUhhoP1wEpb19CUYN0NHC7a4ZYmK/MkyyURhT4Gt0fUQgQJrHJh8Nl8IsSRYpviB1zaVVWQmDDyg5a39UtL54rgnVLXkqhDlAysr5+AO1gk3kGmA5qsKqp5vzNC2pfQwavLPMht4tnZ76Rho1iqel2cz5KeHT/TGoqFr2NaSBbpI8wObIhgD4MeDpj8xHA X-OriginatorOrg: oss.nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 552af384-f07b-4812-64cc-08db550e287a X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2023 06:32:30.3247 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FBmL6AvwlBu2hCxV/DOMeeZg1Vf2gOINf4A/3/HmS5EfEyEgn3iT3wr/tlE6UNUF75zC73MXUnzmkFfo6L5cRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8404 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765941241665558799?= X-GMAIL-MSGID: =?utf-8?q?1765941241665558799?= |
Series |
[V3] soc: imx: support i.MX93 soc device
|
|
Commit Message
Peng Fan (OSS)
May 15, 2023, 6:37 a.m. UTC
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. The overall logic is similar as i.MX8M, so reuse soc-imx8m driver for i.MX93. Signed-off-by: Peng Fan <peng.fan@nxp.com> --- V3: Update commit log Drop uneeded {} V2: The ocotp yaml has got R-b from DT maintainer drivers/soc/imx/Makefile | 2 +- drivers/soc/imx/soc-imx8m.c | 63 ++++++++++++++++++++++++++++++++++++- 2 files changed, 63 insertions(+), 2 deletions(-)
Comments
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
> 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. > reference manual, which mentions a "UNIQUE_ID[127:64]" at offset 0xe00 - > 0xe10 (i.e. bank 40, words 0 and 1). Which chatper? > > 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? RM should be wrong. UID is in Bank 0. > > 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? Just as what the driver indicates, UID is at register address 0x420 and 0x430. 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. Thanks, Peng. > > Rasmus
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
> 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@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
On Wed, May 24, 2023 at 03:30:01PM +0200, Rasmus Villemoes wrote: > 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, Are you fine with the patch itself? Or do you expect more clarification in the commit log? Shawn
Hi Shawn, > Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device > > On Wed, May 24, 2023 at 03:30:01PM +0200, Rasmus Villemoes wrote: > > 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, > > Are you fine with the patch itself? Or do you expect more clarification in the > commit log? Rasmus's comments is for i.MX8MP, this patch is for i.MX93. But anyway I just sent out V4 patch to address i.MX8MP support and then add i.MX93 support. Thanks, Peng. > > Shawn
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile index a28c44a1f16a..83aff181ae51 100644 --- a/drivers/soc/imx/Makefile +++ b/drivers/soc/imx/Makefile @@ -7,5 +7,5 @@ obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o obj-$(CONFIG_IMX8M_BLK_CTRL) += imx8m-blk-ctrl.o obj-$(CONFIG_IMX8M_BLK_CTRL) += imx8mp-blk-ctrl.o -obj-$(CONFIG_SOC_IMX9) += imx93-src.o imx93-pd.o +obj-$(CONFIG_SOC_IMX9) += soc-imx8m.o imx93-src.o imx93-pd.o obj-$(CONFIG_IMX9_BLK_CTRL) += imx93-blk-ctrl.o diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c index 1dcd243df567..6723ac6c0f04 100644 --- a/drivers/soc/imx/soc-imx8m.c +++ b/drivers/soc/imx/soc-imx8m.c @@ -25,8 +25,11 @@ #define IMX8MP_OCOTP_UID_OFFSET 0x10 +#define IMX93_OCOTP_UID_OFFSET 0x80c0 + /* Same as ANADIG_DIGPROG_IMX7D */ #define ANADIG_DIGPROG_IMX8MM 0x800 +#define ANADIG_DIGPROG_IMX93 0x800 struct imx8_soc_data { char *name; @@ -34,6 +37,7 @@ struct imx8_soc_data { }; static u64 soc_uid; +static u64 soc_uid_h; #ifdef CONFIG_HAVE_ARM_SMCCC static u32 imx8mq_soc_revision_from_atf(void) @@ -141,6 +145,53 @@ static u32 __init imx8mm_soc_revision(void) return rev; } +static void __init imx93_soc_uid(void) +{ + void __iomem *ocotp_base; + struct device_node *np; + + np = of_find_compatible_node(NULL, NULL, "fsl,imx93-ocotp"); + if (!np) + return; + + ocotp_base = of_iomap(np, 0); + WARN_ON(!ocotp_base); + + soc_uid = readl_relaxed(ocotp_base + IMX93_OCOTP_UID_OFFSET + 0x8); + soc_uid <<= 32; + soc_uid |= readl_relaxed(ocotp_base + IMX93_OCOTP_UID_OFFSET + 0xC); + + soc_uid_h = readl_relaxed(ocotp_base + IMX93_OCOTP_UID_OFFSET + 0x0); + soc_uid_h <<= 32; + soc_uid_h |= readl_relaxed(ocotp_base + IMX93_OCOTP_UID_OFFSET + 0x4); + + iounmap(ocotp_base); + of_node_put(np); +} + +static u32 __init imx93_soc_revision(void) +{ + struct device_node *np; + void __iomem *anatop_base; + u32 rev; + + np = of_find_compatible_node(NULL, NULL, "fsl,imx93-anatop"); + if (!np) + return 0; + + anatop_base = of_iomap(np, 0); + WARN_ON(!anatop_base); + + rev = readl_relaxed(anatop_base + ANADIG_DIGPROG_IMX93); + + iounmap(anatop_base); + of_node_put(np); + + imx93_soc_uid(); + + return rev; +} + static const struct imx8_soc_data imx8mq_soc_data = { .name = "i.MX8MQ", .soc_revision = imx8mq_soc_revision, @@ -161,11 +212,17 @@ static const struct imx8_soc_data imx8mp_soc_data = { .soc_revision = imx8mm_soc_revision, }; +static const struct imx8_soc_data imx93_soc_data = { + .name = "i.MX93", + .soc_revision = imx93_soc_revision, +}; + static __maybe_unused const struct of_device_id imx8_soc_match[] = { { .compatible = "fsl,imx8mq", .data = &imx8mq_soc_data, }, { .compatible = "fsl,imx8mm", .data = &imx8mm_soc_data, }, { .compatible = "fsl,imx8mn", .data = &imx8mn_soc_data, }, { .compatible = "fsl,imx8mp", .data = &imx8mp_soc_data, }, + { .compatible = "fsl,imx93", .data = &imx93_soc_data, }, { } }; @@ -212,7 +269,11 @@ static int __init imx8_soc_init(void) goto free_soc; } - soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX", soc_uid); + if (soc_uid_h) + soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX%016llX", + soc_uid_h, soc_uid); + else + soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX", soc_uid); if (!soc_dev_attr->serial_number) { ret = -ENOMEM; goto free_rev;