SID Register Guide

= Security ID = So far, all Allwinner A-series SoC come with a bit of memory called 'SID'. So far, for all chips this is 128 bits of freely? usable memory, with a catch. These 128 bits of memory, are not in RAM or ROM, they are so called e-fuses.

By default, the chip ID or revision is written to these fusions and possibly some form of serial number. While modifying is untested at this moment, it is possible to read the fuses.

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

Info
SID Base address: 0x01c23800

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.

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

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/devices/platform/soc@01c00000/1c23800.eeprom/eeprom 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: