SID Register Guide

= Security ID =

So far, all Allwinner A-series SoCs come with a bit of memory called 'SID'. So far, for all chips this is 128-512 bytes of usable memory, with a catch. These bytes of memory are not in RAM or ROM, they are so called e-fuses. Each bit of an e-fuse can only transition from 0 -> 1 once. Writing 0 to a bit does nothing, but once a bit is set to 1, it is set permanently. Therefore, extreme care must be taken when writing any of the areas referenced below.

By default, the chip ID or revision is written to these fuses, as well as a serial number and Thermal Sensor calibration data. While modifying is mostly untested at this moment, it is possible to read the fuses. Note that there are two ways to read the fuses, and some chips have a silicon bug that requires using a specific method of reading.

A few use cases for the SID are, but not limited to:
 * Generate per-device unique MAC address
 * Store/use as an RSA etc key
 * Write in-house serial numbers
 * Control Boot ROM behavior

A10/A20/A33
SID Base address: 0x01c23800

SID_KEY[0-3]
Default value: undefined

Offset: 0x0{0, 4, 8, c}

SID_WRITE_DATA
Default value: 0x00000000

Offset: 0x40

We think this is the data register used when programming the SID efuses.

There is also a EFUSE_VDDQ pin (pin T9 on A10) which is normally tied to GND but which we guess needs to have suitable power to enable efuse programming. Details unknown.

SID_WRITE_CTRL
Default value: 0x00000000

Offset: 0x44

A83T/A64/H3/H6
Newer SoCs have a 2 kbit eFUSE area with a new controller.

For Allwinner A83T and H3 the SID address space starts at 0x01c14000, and the e-fuses are at offset 0x200 - so the address to use for these SoCs is 0x01c14200.

Registers
Base address: 0x01c14000

SID_RDKEY
= eFUSE Contents =

ROTPK_HASH
Contains the SHA256 hash of the 2048-bit RSA public key used to verify the signature of the first code executed after BROM, the so-called TOC0. In the case of a TOC0 containing a key item, the ROTPK is used to sign the key item, and the secondary key in the key item is used to sign the TOC0 firmware contents.

ROTPK_HASH = SHA256([Byte 0-255] = RSA modulus || [Byte 256-x] = RSA public exponent || [Byte x-511] filled with 0x91)

The hash isn't checked as long as all 32-bit words in this eFUSE have the same value. This means, only the signature is verified, but not the key used to sign, so any key can be used.

BROM CONFIG
Note: Addresses below come from the H6 SBROM.

= Currently known SID's =

You may try to retrieve the SID value via our sunxi-tools - or dump it from within U-Boot using the corresponding, SoC-specific address (e.g.  ). If running a mainline kernel hexdump should be sufficient. hexdump -C /sys/bus/nvmem/devices/sunxi-sid0/nvmem 00000000 16 51 66 c6 80 51 77 89  54 53 48 48 0a 40 f2 67  |.Qf..Qw.TSHH.@.g| 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Simple script to run on legacy kernel with devmem2: d0=`./devmem2 0x01c14200 w|grep Value|sed 's/^.*: 0x/ /'` d1=`./devmem2 0x01c14204 w|grep Value|sed 's/^.*: 0x/ /'` d2=`./devmem2 0x01c14208 w|grep Value|sed 's/^.*: 0x/ /'` d3=`./devmem2 0x01c1420c w|grep Value|sed 's/^.*: 0x/ /'` echo $d0 $d1 $d2 $d3


 * A silicon bug manifests itself in a way that returns a garbled SID (root key) when reading the values solely via memory access. Accessing the SID once via register access seems to fix this, even for subsequent memory reading - see the discussion on the mailing list. Corresponding entries in the table above therefore cannot be trusted, and need to be refreshed. A fix for sunxi-fel is now available.

Newer SoC families no longer seem to follow the above pattern of containing the SoC ID within the first value. However, the leading 32 bits still appear to be consistent among the same SoCs: