riskable Posted December 23, 2016 Share Posted December 23, 2016 According to http://linux-sunxi.org/H2%2B#VariantsI should be able to differentiate between the H2+ and the H3 via the CPU SID. I have an Orange Pi Zero board with this output from /proc/cpuinfo Hardware : Allwinner sun8i Family Revision : 0000Serial : 02004620161dea8a According to that site "the last byte of the first word" should be either 0x42 or 0x83 since the Orange Pi Zero has an H2+. Yet I am not finding 0x42 or 0x83 *anywhere* in "02004620161dea8a". Anyone know how to correctly identify the CPU variant? Link to comment Share on other sites More sharing options...
jernej Posted December 23, 2016 Share Posted December 23, 2016 Serial is not same as SID. SID is special storage for one time programmable data (OTP) also known as eFuse (you can change it too). Many different things can be stored there, calibration factors among the others... I'm not sure if this data is exposed via procfs or sysfs. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted December 23, 2016 Share Posted December 23, 2016 SID != serial number displayed in /proc/cpuinfo For getting SID in the legacy kernel you need to use devmem utility, please check the details here: https://linux-sunxi.org/SID_Register_Guide#Currently_known_SID.27s Link to comment Share on other sites More sharing options...
riskable Posted December 23, 2016 Author Share Posted December 23, 2016 SID != serial number displayed in /proc/cpuinfo For getting SID in the legacy kernel you need to use devmem utility, please check the details here: https://linux-sunxi.org/SID_Register_Guide#Currently_known_SID.27s Well, the first address read by devmem2 matches the output from /proc/cpuinfo: root@orangepizero:~# devmem2 0x01c14200 w|grep Value|sed 's/^.*: 0x/ /' 2004620 root@orangepizero:~# cat /proc/cpuinfo | grep Serial Serial : 02004620161dea8a Of course, that's where it ends. Here's the next region: root@orangepizero:~# devmem2 0x01c14204 w|grep Value|sed 's/^.*: 0x/ /' 3435C614 Regardless, the "last byte of the first word" still doesn't match. So I'm guessing that sun8i.c is just plain wrong since 0x42 and 0x83 can't be found in any of these numbers. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted December 23, 2016 Share Posted December 23, 2016 On that wiki page you can see that 02004620 was already pulled from some other board, but it was the wrong value. Please look here for the sunxi-tools fix and some background info: https://github.com/linux-sunxi/sunxi-tools/pull/90 Unfortunately the legacy kernel will need to be fixed too and I'm not sure anybody will want to do this. Link to comment Share on other sites More sharing options...
Recommended Posts