The Amlogic Meson SoC secure monitor (TF-A) handles a call (0x82000044)
to retrieve a chip_id from eFuse OTP data [1].
Previously, this sm call (0x82000044) was used to retrieve just unique
SoC number [2] (a.k.a. SoC "serial" [3]), identifying particular die.
This SoC serial, stored in the eFuse, is always 12 bytes long.
However, this smc provides more info and the patch series generalizes
the API to provide SoC serial and support of chip_id.
Chip_id in eFuse OTP storage exists in two flavors [1]: v1 (12 bytes)
and v2 (16 bytes). The vendor U-Boot handles this difference before
returning the chip_id value to the client and generalizes versions to
look like the following (always 16 bytes in size):
4 bytes 12 bytes
+-------+-------------------+
| | |
| CPUID | SOC SERIAL NUMBER |
| | |
+-------+-------------------+
0 15
The original chip_id value is utilized in several algorithms (for
example, in the Amlogic boot protocols), making it crucial to have the
ability to read the original chip_id value as intended by the vendor [3]
Links:
[1]
[2]
[3]
Signed-off-by: Evgeny Bachinin <EABachinin@...>
---
Patch is based on:
- v5 of Linux patch series
Tested:
* on A1, AXG.
* U-boot CI:
---
Evgeny Bachinin (3):
arm: meson: unify type being used for socinfo
arm: meson: sm: get rid of SM_CHIP_ID_SIZE
arch: arm: meson: support Amlogic chip_id v1 and v2
arch/arm/include/asm/arch-meson/boot.h | 14 ++++
arch/arm/include/asm/arch-meson/sm.h | 48 ++++++++++++-
arch/arm/mach-meson/board-info.c | 13 ++--
arch/arm/mach-meson/sm.c | 120 ++++++++++++++++++++++++++++++---
4 files changed, 179 insertions(+), 16 deletions(-)
---
base-commit: 6d41f0a39d6423c8e57e92ebbe9f8c0333a63f72
change-id: 20250208-meson_chip_id_all_vers-8ed402afae36
Best regards,
--
Evgeny Bachinin <EABachinin@...>
