* Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 15:22 ` Icenowy Zheng
0 siblings, 0 replies; 20+ messages in thread
From: Icenowy Zheng @ 2016-12-19 15:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).
See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.
>From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).
According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )
However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.
The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.
Then I found the SID-reading code from BSP U-Boot[2], which is based on
register operations. With this kind of code (I wrote one prototype in
userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
And, after accessing to the SID by registers, the value of *0x01c14200 become
also "02c00081".
With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".
Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
Summary:
+-----------------------------------------------+----------------+
| Read situation | The first word |
+-----------------------------------------------+----------------+
| Direct read by sunxi-fel | 02004620 |
| Direct read in mainline /dev/mem | 02004620 |
| Direct read in legacy /dev/mem | 02c00081 |
| Register access in FEL | 02c00081 |
| Register access in mainline | 02c00081 |
| Direct read after register access in FEL | 02c00081 |
| Direct read after register access in mainline | 02c00081 |
+-----------------------------------------------+----------------+
According to some facts:
- The register based access to SID is weird: it needs ~5 register
operations per word of SID.
- Reading via register access will change the value when reading by accessing
0x01c14200.
- In the u-boot code[2] there's some functions which read out the SID by
registers and then abandoned the value.
- This mismatch do not exist on A64.
I think that: Allwinner designed a "cache" to the SID to make the simplify the
code to read it, and it automatically loaded the cache when booting; however,
when doing first cache on H3, some byte shifts occured, and the value become
wrong. A manual read on H3 can make the cache right again. This is a silicon
bug, and fixed in A64.
This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.
However, if this bug is not workarounded, the sun8i-ths driver won't work well
(as some calibartion value lies in eFUSE). I think some early user of this
driver has already experienced bad readout value.
(The calibration value differs on my opi1 and KotCzarny's opipc)
And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)
Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
Furthermore, A83T may also have this problem, testers are welcome!
[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
Experiments:
- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
A SID readout shell script via FEL with register access.
- https://31.135.195.151:20281/d/efuse/
A SID readout program via /dev/mem with register access by KotCzarny.
(with statically compiled binary)
Regards,
Icenowy
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 15:22 ` Icenowy Zheng
0 siblings, 0 replies; 20+ messages in thread
From: Icenowy Zheng @ 2016-12-19 15:22 UTC (permalink / raw)
To: u-boot
Hi everyone,
Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).
See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.
From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).
According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )
However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.
The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.
Then I found the SID-reading code from BSP U-Boot[2], which is based on
register operations. With this kind of code (I wrote one prototype in
userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
And, after accessing to the SID by registers, the value of *0x01c14200 become
also "02c00081".
With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".
Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
Summary:
+-----------------------------------------------+----------------+
| Read situation | The first word |
+-----------------------------------------------+----------------+
| Direct read by sunxi-fel | 02004620 |
| Direct read in mainline /dev/mem | 02004620 |
| Direct read in legacy /dev/mem | 02c00081 |
| Register access in FEL | 02c00081 |
| Register access in mainline | 02c00081 |
| Direct read after register access in FEL | 02c00081 |
| Direct read after register access in mainline | 02c00081 |
+-----------------------------------------------+----------------+
According to some facts:
- The register based access to SID is weird: it needs ~5 register
operations per word of SID.
- Reading via register access will change the value when reading by accessing
0x01c14200.
- In the u-boot code[2] there's some functions which read out the SID by
registers and then abandoned the value.
- This mismatch do not exist on A64.
I think that: Allwinner designed a "cache" to the SID to make the simplify the
code to read it, and it automatically loaded the cache when booting; however,
when doing first cache on H3, some byte shifts occured, and the value become
wrong. A manual read on H3 can make the cache right again. This is a silicon
bug, and fixed in A64.
This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.
However, if this bug is not workarounded, the sun8i-ths driver won't work well
(as some calibartion value lies in eFUSE). I think some early user of this
driver has already experienced bad readout value.
(The calibration value differs on my opi1 and KotCzarny's opipc)
And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)
Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
Furthermore, A83T may also have this problem, testers are welcome!
[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
Experiments:
- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
A SID readout shell script via FEL with register access.
- https://31.135.195.151:20281/d/efuse/
A SID readout program via /dev/mem with register access by KotCzarny.
(with statically compiled binary)
Regards,
Icenowy
^ permalink raw reply [flat|nested] 20+ messages in thread
* Problems to Allwinner H3's eFUSE/SID
2016-12-19 15:22 ` [U-Boot] " Icenowy Zheng
@ 2016-12-19 15:30 ` Hans de Goede
-1 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-19 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 19-12-16 16:22, Icenowy Zheng wrote:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel | 02004620 |
> | Direct read in mainline /dev/mem | 02004620 |
> | Direct read in legacy /dev/mem | 02c00081 |
> | Register access in FEL | 02c00081 |
> | Register access in mainline | 02c00081 |
> | Direct read after register access in FEL | 02c00081 |
> | Direct read after register access in mainline | 02c00081 |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> - Reading via register access will change the value when reading by accessing
> 0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
> registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
> A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
> A SID readout program via /dev/mem with register access by KotCzarny.
> (with statically compiled binary)
Good detective work!
I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.
Can you write a patch for this ?
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 15:30 ` Hans de Goede
0 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-19 15:30 UTC (permalink / raw)
To: u-boot
Hi,
On 19-12-16 16:22, Icenowy Zheng wrote:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel | 02004620 |
> | Direct read in mainline /dev/mem | 02004620 |
> | Direct read in legacy /dev/mem | 02c00081 |
> | Register access in FEL | 02c00081 |
> | Register access in mainline | 02c00081 |
> | Direct read after register access in FEL | 02c00081 |
> | Direct read after register access in mainline | 02c00081 |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> - Reading via register access will change the value when reading by accessing
> 0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
> registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
> A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
> A SID readout program via /dev/mem with register access by KotCzarny.
> (with statically compiled binary)
Good detective work!
I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.
Can you write a patch for this ?
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* Problems to Allwinner H3's eFUSE/SID
2016-12-19 15:30 ` [U-Boot] " Hans de Goede
@ 2016-12-19 16:06 ` Icenowy Zheng
-1 siblings, 0 replies; 20+ messages in thread
From: Icenowy Zheng @ 2016-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 16:22, Icenowy Zheng wrote:
>> ?Hi everyone,
>>
>> ?Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>> ?controller of H3 (incl. H2+).
>>
>> ?See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>
>> ?Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>> ?directly access 0x01c14200.
>>
>> ?From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>> ?the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>> ?legacy kernel).
>>
>> ?According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>> ?byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>> ?0x58 is H3D (currently not known SoC) )
>>
>> ?However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>> ?with 0x02004620, which do not match this rule.
>>
>> ?The readout by devmem2 is satisfying this rule: their first word is
>> ?0x02c00081, matches H3.
>>
>> ?Then I found the SID-reading code from BSP U-Boot[2], which is based on
>> ?register operations. With this kind of code (I wrote one prototype in
>> ?userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>> ?my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>> ?And, after accessing to the SID by registers, the value of *0x01c14200 become
>> ?also "02c00081".
>>
>> ?With direct access to 0x01c14200 after boot with mainline kernel, I got also
>> ?"02004620".
>>
>> ?Then I altered the program to do the register operations with sunxi-fel, the
>> ?result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>
>> ?Summary:
>>
>> ?+-----------------------------------------------+----------------+
>> ?| Read situation | The first word |
>> ?+-----------------------------------------------+----------------+
>> ?| Direct read by sunxi-fel | 02004620 |
>> ?| Direct read in mainline /dev/mem | 02004620 |
>> ?| Direct read in legacy /dev/mem | 02c00081 |
>> ?| Register access in FEL | 02c00081 |
>> ?| Register access in mainline | 02c00081 |
>> ?| Direct read after register access in FEL | 02c00081 |
>> ?| Direct read after register access in mainline | 02c00081 |
>> ?+-----------------------------------------------+----------------+
>>
>> ?According to some facts:
>> ?- The register based access to SID is weird: it needs ~5 register
>> ???operations per word of SID.
>> ?- Reading via register access will change the value when reading by accessing
>> ???0x01c14200.
>> ?- In the u-boot code[2] there's some functions which read out the SID by
>> ???registers and then abandoned the value.
>> ?- This mismatch do not exist on A64.
>>
>> ?I think that: Allwinner designed a "cache" to the SID to make the simplify the
>> ?code to read it, and it automatically loaded the cache when booting; however,
>> ?when doing first cache on H3, some byte shifts occured, and the value become
>> ?wrong. A manual read on H3 can make the cache right again. This is a silicon
>> ?bug, and fixed in A64.
>>
>> ?This raises a problem: currently many systems has used the misread SID value to
>> ?generated lots of MAC addresses, and workaround this SID bug will change them.
>>
>> ?However, if this bug is not workarounded, the sun8i-ths driver won't work well
>> ?(as some calibartion value lies in eFUSE). I think some early user of this
>> ?driver has already experienced bad readout value.
>> ?(The calibration value differs on my opi1 and KotCzarny's opipc)
>>
>> ?And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>> ?think sunxi-fel must have the workaround)
>>
>> ?Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>> ?at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>
>> ?Furthermore, A83T may also have this problem, testers are welcome!
>>
>> ?[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>> ?[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>
>> ?Experiments:
>> ?- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>> ???A SID readout shell script via FEL with register access.
>> ?- https://31.135.195.151:20281/d/efuse/
>> ???A SID readout program via /dev/mem with register access by KotCzarny.
>> ???(with statically compiled binary)
>
> Good detective work!
>
> I believe this would best be fixed by making u-boot use the register access
> method to get the SID on affected chips, and make sure u-boot reads the
> SID at-least once.
Yes.
However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.
Maybe we should add #ifdef's to MAC generation code after this fix.
(This is why I will create this discussion)
P.S. Are you still the maintainer of sunxi boards support of u-boot? The
MAINTAINER file in board/sunxi indicates this.
I've sent out a new board support several days ago (Orange Pi Zero), and got
one "Reviewd-By". Could you look at it?
>
> Can you write a patch for this ?
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 16:06 ` Icenowy Zheng
0 siblings, 0 replies; 20+ messages in thread
From: Icenowy Zheng @ 2016-12-19 16:06 UTC (permalink / raw)
To: u-boot
19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 16:22, Icenowy Zheng wrote:
>> ?Hi everyone,
>>
>> ?Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>> ?controller of H3 (incl. H2+).
>>
>> ?See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>
>> ?Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>> ?directly access 0x01c14200.
>>
>> ?From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>> ?the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>> ?legacy kernel).
>>
>> ?According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>> ?byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>> ?0x58 is H3D (currently not known SoC) )
>>
>> ?However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>> ?with 0x02004620, which do not match this rule.
>>
>> ?The readout by devmem2 is satisfying this rule: their first word is
>> ?0x02c00081, matches H3.
>>
>> ?Then I found the SID-reading code from BSP U-Boot[2], which is based on
>> ?register operations. With this kind of code (I wrote one prototype in
>> ?userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>> ?my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>> ?And, after accessing to the SID by registers, the value of *0x01c14200 become
>> ?also "02c00081".
>>
>> ?With direct access to 0x01c14200 after boot with mainline kernel, I got also
>> ?"02004620".
>>
>> ?Then I altered the program to do the register operations with sunxi-fel, the
>> ?result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>
>> ?Summary:
>>
>> ?+-----------------------------------------------+----------------+
>> ?| Read situation | The first word |
>> ?+-----------------------------------------------+----------------+
>> ?| Direct read by sunxi-fel | 02004620 |
>> ?| Direct read in mainline /dev/mem | 02004620 |
>> ?| Direct read in legacy /dev/mem | 02c00081 |
>> ?| Register access in FEL | 02c00081 |
>> ?| Register access in mainline | 02c00081 |
>> ?| Direct read after register access in FEL | 02c00081 |
>> ?| Direct read after register access in mainline | 02c00081 |
>> ?+-----------------------------------------------+----------------+
>>
>> ?According to some facts:
>> ?- The register based access to SID is weird: it needs ~5 register
>> ???operations per word of SID.
>> ?- Reading via register access will change the value when reading by accessing
>> ???0x01c14200.
>> ?- In the u-boot code[2] there's some functions which read out the SID by
>> ???registers and then abandoned the value.
>> ?- This mismatch do not exist on A64.
>>
>> ?I think that: Allwinner designed a "cache" to the SID to make the simplify the
>> ?code to read it, and it automatically loaded the cache when booting; however,
>> ?when doing first cache on H3, some byte shifts occured, and the value become
>> ?wrong. A manual read on H3 can make the cache right again. This is a silicon
>> ?bug, and fixed in A64.
>>
>> ?This raises a problem: currently many systems has used the misread SID value to
>> ?generated lots of MAC addresses, and workaround this SID bug will change them.
>>
>> ?However, if this bug is not workarounded, the sun8i-ths driver won't work well
>> ?(as some calibartion value lies in eFUSE). I think some early user of this
>> ?driver has already experienced bad readout value.
>> ?(The calibration value differs on my opi1 and KotCzarny's opipc)
>>
>> ?And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>> ?think sunxi-fel must have the workaround)
>>
>> ?Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>> ?at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>
>> ?Furthermore, A83T may also have this problem, testers are welcome!
>>
>> ?[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>> ?[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>
>> ?Experiments:
>> ?- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>> ???A SID readout shell script via FEL with register access.
>> ?- https://31.135.195.151:20281/d/efuse/
>> ???A SID readout program via /dev/mem with register access by KotCzarny.
>> ???(with statically compiled binary)
>
> Good detective work!
>
> I believe this would best be fixed by making u-boot use the register access
> method to get the SID on affected chips, and make sure u-boot reads the
> SID at-least once.
Yes.
However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.
Maybe we should add #ifdef's to MAC generation code after this fix.
(This is why I will create this discussion)
P.S. Are you still the maintainer of sunxi boards support of u-boot? The
MAINTAINER file in board/sunxi indicates this.
I've sent out a new board support several days ago (Orange Pi Zero), and got
one "Reviewd-By". Could you look at it?
>
> Can you write a patch for this ?
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* Problems to Allwinner H3's eFUSE/SID
2016-12-19 16:06 ` [U-Boot] " Icenowy Zheng
@ 2016-12-19 16:17 ` Hans de Goede
-1 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-19 16:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 19-12-16 17:06, Icenowy Zheng wrote:
>
>
> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>> Hi everyone,
>>>
>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>> controller of H3 (incl. H2+).
>>>
>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>
>>> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>> directly access 0x01c14200.
>>>
>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>> legacy kernel).
>>>
>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>> 0x58 is H3D (currently not known SoC) )
>>>
>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>> with 0x02004620, which do not match this rule.
>>>
>>> The readout by devmem2 is satisfying this rule: their first word is
>>> 0x02c00081, matches H3.
>>>
>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>> register operations. With this kind of code (I wrote one prototype in
>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>> And, after accessing to the SID by registers, the value of *0x01c14200 become
>>> also "02c00081".
>>>
>>> With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>> "02004620".
>>>
>>> Then I altered the program to do the register operations with sunxi-fel, the
>>> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>
>>> Summary:
>>>
>>> +-----------------------------------------------+----------------+
>>> | Read situation | The first word |
>>> +-----------------------------------------------+----------------+
>>> | Direct read by sunxi-fel | 02004620 |
>>> | Direct read in mainline /dev/mem | 02004620 |
>>> | Direct read in legacy /dev/mem | 02c00081 |
>>> | Register access in FEL | 02c00081 |
>>> | Register access in mainline | 02c00081 |
>>> | Direct read after register access in FEL | 02c00081 |
>>> | Direct read after register access in mainline | 02c00081 |
>>> +-----------------------------------------------+----------------+
>>>
>>> According to some facts:
>>> - The register based access to SID is weird: it needs ~5 register
>>> operations per word of SID.
>>> - Reading via register access will change the value when reading by accessing
>>> 0x01c14200.
>>> - In the u-boot code[2] there's some functions which read out the SID by
>>> registers and then abandoned the value.
>>> - This mismatch do not exist on A64.
>>>
>>> I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>> code to read it, and it automatically loaded the cache when booting; however,
>>> when doing first cache on H3, some byte shifts occured, and the value become
>>> wrong. A manual read on H3 can make the cache right again. This is a silicon
>>> bug, and fixed in A64.
>>>
>>> This raises a problem: currently many systems has used the misread SID value to
>>> generated lots of MAC addresses, and workaround this SID bug will change them.
>>>
>>> However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>> (as some calibartion value lies in eFUSE). I think some early user of this
>>> driver has already experienced bad readout value.
>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>
>>> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>> think sunxi-fel must have the workaround)
>>>
>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>
>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>
>>> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>
>>> Experiments:
>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>> A SID readout shell script via FEL with register access.
>>> - https://31.135.195.151:20281/d/efuse/
>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>> (with statically compiled binary)
>>
>> Good detective work!
>>
>> I believe this would best be fixed by making u-boot use the register access
>> method to get the SID on affected chips, and make sure u-boot reads the
>> SID at-least once.
>
> Yes.
>
> However, what I considered is that fixing this bug will change H3 devices'
> MAC addresses, as they are derived from SID.
I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the mainline kernel yet.
> Maybe we should add #ifdef's to MAC generation code after this fix.
I would rather not see #ifdefs for this, see above, but that is no
longer my call, see below.
>
> (This is why I will create this discussion)
>
> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
> MAINTAINER file in board/sunxi indicates this.
No I'm no longer the maintainer, I'm still the MAINTAINER file because
I have a lot of boards and as such I'm still the point of contact for
those boards (if there are any board specific issues / questions), but
as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
is the maintainer now.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 16:17 ` Hans de Goede
0 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-19 16:17 UTC (permalink / raw)
To: u-boot
Hi,
On 19-12-16 17:06, Icenowy Zheng wrote:
>
>
> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>> Hi everyone,
>>>
>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>> controller of H3 (incl. H2+).
>>>
>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>
>>> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>> directly access 0x01c14200.
>>>
>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>> legacy kernel).
>>>
>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>> 0x58 is H3D (currently not known SoC) )
>>>
>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>> with 0x02004620, which do not match this rule.
>>>
>>> The readout by devmem2 is satisfying this rule: their first word is
>>> 0x02c00081, matches H3.
>>>
>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>> register operations. With this kind of code (I wrote one prototype in
>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>> And, after accessing to the SID by registers, the value of *0x01c14200 become
>>> also "02c00081".
>>>
>>> With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>> "02004620".
>>>
>>> Then I altered the program to do the register operations with sunxi-fel, the
>>> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>
>>> Summary:
>>>
>>> +-----------------------------------------------+----------------+
>>> | Read situation | The first word |
>>> +-----------------------------------------------+----------------+
>>> | Direct read by sunxi-fel | 02004620 |
>>> | Direct read in mainline /dev/mem | 02004620 |
>>> | Direct read in legacy /dev/mem | 02c00081 |
>>> | Register access in FEL | 02c00081 |
>>> | Register access in mainline | 02c00081 |
>>> | Direct read after register access in FEL | 02c00081 |
>>> | Direct read after register access in mainline | 02c00081 |
>>> +-----------------------------------------------+----------------+
>>>
>>> According to some facts:
>>> - The register based access to SID is weird: it needs ~5 register
>>> operations per word of SID.
>>> - Reading via register access will change the value when reading by accessing
>>> 0x01c14200.
>>> - In the u-boot code[2] there's some functions which read out the SID by
>>> registers and then abandoned the value.
>>> - This mismatch do not exist on A64.
>>>
>>> I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>> code to read it, and it automatically loaded the cache when booting; however,
>>> when doing first cache on H3, some byte shifts occured, and the value become
>>> wrong. A manual read on H3 can make the cache right again. This is a silicon
>>> bug, and fixed in A64.
>>>
>>> This raises a problem: currently many systems has used the misread SID value to
>>> generated lots of MAC addresses, and workaround this SID bug will change them.
>>>
>>> However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>> (as some calibartion value lies in eFUSE). I think some early user of this
>>> driver has already experienced bad readout value.
>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>
>>> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>> think sunxi-fel must have the workaround)
>>>
>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>
>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>
>>> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>
>>> Experiments:
>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>> A SID readout shell script via FEL with register access.
>>> - https://31.135.195.151:20281/d/efuse/
>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>> (with statically compiled binary)
>>
>> Good detective work!
>>
>> I believe this would best be fixed by making u-boot use the register access
>> method to get the SID on affected chips, and make sure u-boot reads the
>> SID at-least once.
>
> Yes.
>
> However, what I considered is that fixing this bug will change H3 devices'
> MAC addresses, as they are derived from SID.
I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the mainline kernel yet.
> Maybe we should add #ifdef's to MAC generation code after this fix.
I would rather not see #ifdefs for this, see above, but that is no
longer my call, see below.
>
> (This is why I will create this discussion)
>
> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
> MAINTAINER file in board/sunxi indicates this.
No I'm no longer the maintainer, I'm still the MAINTAINER file because
I have a lot of boards and as such I'm still the point of contact for
those boards (if there are any board specific issues / questions), but
as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
is the maintainer now.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* Problems to Allwinner H3's eFUSE/SID
2016-12-19 16:17 ` [U-Boot] " Hans de Goede
@ 2016-12-19 16:25 ` Icenowy Zheng
-1 siblings, 0 replies; 20+ messages in thread
From: Icenowy Zheng @ 2016-12-19 16:25 UTC (permalink / raw)
To: linux-arm-kernel
20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>> ?19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>> ?Hi,
>>>
>>> ?On 19-12-16 16:22, Icenowy Zheng wrote:
>>>> ??Hi everyone,
>>>>
>>>> ??Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> ??controller of H3 (incl. H2+).
>>>>
>>>> ??See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> ??Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>> ??directly access 0x01c14200.
>>>>
>>>> ??From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>> ??the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>> ??legacy kernel).
>>>>
>>>> ??According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>> ??byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>> ??0x58 is H3D (currently not known SoC) )
>>>>
>>>> ??However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>> ??with 0x02004620, which do not match this rule.
>>>>
>>>> ??The readout by devmem2 is satisfying this rule: their first word is
>>>> ??0x02c00081, matches H3.
>>>>
>>>> ??Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> ??register operations. With this kind of code (I wrote one prototype in
>>>> ??userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>> ??my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>> ??And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>> ??also "02c00081".
>>>>
>>>> ??With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>> ??"02004620".
>>>>
>>>> ??Then I altered the program to do the register operations with sunxi-fel, the
>>>> ??result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>
>>>> ??Summary:
>>>>
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Read situation | The first word |
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Direct read by sunxi-fel | 02004620 |
>>>> ??| Direct read in mainline /dev/mem | 02004620 |
>>>> ??| Direct read in legacy /dev/mem | 02c00081 |
>>>> ??| Register access in FEL | 02c00081 |
>>>> ??| Register access in mainline | 02c00081 |
>>>> ??| Direct read after register access in FEL | 02c00081 |
>>>> ??| Direct read after register access in mainline | 02c00081 |
>>>> ??+-----------------------------------------------+----------------+
>>>>
>>>> ??According to some facts:
>>>> ??- The register based access to SID is weird: it needs ~5 register
>>>> ????operations per word of SID.
>>>> ??- Reading via register access will change the value when reading by accessing
>>>> ????0x01c14200.
>>>> ??- In the u-boot code[2] there's some functions which read out the SID by
>>>> ????registers and then abandoned the value.
>>>> ??- This mismatch do not exist on A64.
>>>>
>>>> ??I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>> ??code to read it, and it automatically loaded the cache when booting; however,
>>>> ??when doing first cache on H3, some byte shifts occured, and the value become
>>>> ??wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>> ??bug, and fixed in A64.
>>>>
>>>> ??This raises a problem: currently many systems has used the misread SID value to
>>>> ??generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>
>>>> ??However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>> ??(as some calibartion value lies in eFUSE). I think some early user of this
>>>> ??driver has already experienced bad readout value.
>>>> ??(The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> ??And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>> ??think sunxi-fel must have the workaround)
>>>>
>>>> ??Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>> ??at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> ??Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> ??[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> ??[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> ??Experiments:
>>>> ??- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> ????A SID readout shell script via FEL with register access.
>>>> ??- https://31.135.195.151:20281/d/efuse/
>>>> ????A SID readout program via /dev/mem with register access by KotCzarny.
>>>> ????(with statically compiled binary)
>>>
>>> ?Good detective work!
>>>
>>> ?I believe this would best be fixed by making u-boot use the register access
>>> ?method to get the SID on affected chips, and make sure u-boot reads the
>>> ?SID at-least once.
>>
>> ?Yes.
>>
>> ?However, what I considered is that fixing this bug will change H3 devices'
>> ?MAC addresses, as they are derived from SID.
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
>
>> ?Maybe we should add #ifdef's to MAC generation code after this fix.
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>> ?(This is why I will create this discussion)
>>
>> ?P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> ?MAINTAINER file in board/sunxi indicates this.
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.
But the current status of the file will indicates you are the maintainer of boards
support of sunxi.
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 16:25 ` Icenowy Zheng
0 siblings, 0 replies; 20+ messages in thread
From: Icenowy Zheng @ 2016-12-19 16:25 UTC (permalink / raw)
To: u-boot
20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>> ?19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>> ?Hi,
>>>
>>> ?On 19-12-16 16:22, Icenowy Zheng wrote:
>>>> ??Hi everyone,
>>>>
>>>> ??Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> ??controller of H3 (incl. H2+).
>>>>
>>>> ??See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> ??Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>> ??directly access 0x01c14200.
>>>>
>>>> ??From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>> ??the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>> ??legacy kernel).
>>>>
>>>> ??According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>> ??byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>> ??0x58 is H3D (currently not known SoC) )
>>>>
>>>> ??However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>> ??with 0x02004620, which do not match this rule.
>>>>
>>>> ??The readout by devmem2 is satisfying this rule: their first word is
>>>> ??0x02c00081, matches H3.
>>>>
>>>> ??Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> ??register operations. With this kind of code (I wrote one prototype in
>>>> ??userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>> ??my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>> ??And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>> ??also "02c00081".
>>>>
>>>> ??With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>> ??"02004620".
>>>>
>>>> ??Then I altered the program to do the register operations with sunxi-fel, the
>>>> ??result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>
>>>> ??Summary:
>>>>
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Read situation | The first word |
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Direct read by sunxi-fel | 02004620 |
>>>> ??| Direct read in mainline /dev/mem | 02004620 |
>>>> ??| Direct read in legacy /dev/mem | 02c00081 |
>>>> ??| Register access in FEL | 02c00081 |
>>>> ??| Register access in mainline | 02c00081 |
>>>> ??| Direct read after register access in FEL | 02c00081 |
>>>> ??| Direct read after register access in mainline | 02c00081 |
>>>> ??+-----------------------------------------------+----------------+
>>>>
>>>> ??According to some facts:
>>>> ??- The register based access to SID is weird: it needs ~5 register
>>>> ????operations per word of SID.
>>>> ??- Reading via register access will change the value when reading by accessing
>>>> ????0x01c14200.
>>>> ??- In the u-boot code[2] there's some functions which read out the SID by
>>>> ????registers and then abandoned the value.
>>>> ??- This mismatch do not exist on A64.
>>>>
>>>> ??I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>> ??code to read it, and it automatically loaded the cache when booting; however,
>>>> ??when doing first cache on H3, some byte shifts occured, and the value become
>>>> ??wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>> ??bug, and fixed in A64.
>>>>
>>>> ??This raises a problem: currently many systems has used the misread SID value to
>>>> ??generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>
>>>> ??However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>> ??(as some calibartion value lies in eFUSE). I think some early user of this
>>>> ??driver has already experienced bad readout value.
>>>> ??(The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> ??And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>> ??think sunxi-fel must have the workaround)
>>>>
>>>> ??Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>> ??at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> ??Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> ??[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> ??[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> ??Experiments:
>>>> ??- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> ????A SID readout shell script via FEL with register access.
>>>> ??- https://31.135.195.151:20281/d/efuse/
>>>> ????A SID readout program via /dev/mem with register access by KotCzarny.
>>>> ????(with statically compiled binary)
>>>
>>> ?Good detective work!
>>>
>>> ?I believe this would best be fixed by making u-boot use the register access
>>> ?method to get the SID on affected chips, and make sure u-boot reads the
>>> ?SID at-least once.
>>
>> ?Yes.
>>
>> ?However, what I considered is that fixing this bug will change H3 devices'
>> ?MAC addresses, as they are derived from SID.
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
>
>> ?Maybe we should add #ifdef's to MAC generation code after this fix.
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>> ?(This is why I will create this discussion)
>>
>> ?P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> ?MAINTAINER file in board/sunxi indicates this.
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.
But the current status of the file will indicates you are the maintainer of boards
support of sunxi.
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* Problems to Allwinner H3's eFUSE/SID
2016-12-19 16:25 ` [U-Boot] " Icenowy Zheng
@ 2016-12-19 16:27 ` Hans de Goede
-1 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-19 16:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 19-12-16 17:25, Icenowy Zheng wrote:
>
>
> 20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>> Hi,
>>>>
>>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>> controller of H3 (incl. H2+).
>>>>>
>>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>>> directly access 0x01c14200.
>>>>>
>>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>>> legacy kernel).
>>>>>
>>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>>> 0x58 is H3D (currently not known SoC) )
>>>>>
>>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>>> with 0x02004620, which do not match this rule.
>>>>>
>>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>>> 0x02c00081, matches H3.
>>>>>
>>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>> register operations. With this kind of code (I wrote one prototype in
>>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>>> And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>>> also "02c00081".
>>>>>
>>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>>> "02004620".
>>>>>
>>>>> Then I altered the program to do the register operations with sunxi-fel, the
>>>>> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>>
>>>>> Summary:
>>>>>
>>>>> +-----------------------------------------------+----------------+
>>>>> | Read situation | The first word |
>>>>> +-----------------------------------------------+----------------+
>>>>> | Direct read by sunxi-fel | 02004620 |
>>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>>> | Register access in FEL | 02c00081 |
>>>>> | Register access in mainline | 02c00081 |
>>>>> | Direct read after register access in FEL | 02c00081 |
>>>>> | Direct read after register access in mainline | 02c00081 |
>>>>> +-----------------------------------------------+----------------+
>>>>>
>>>>> According to some facts:
>>>>> - The register based access to SID is weird: it needs ~5 register
>>>>> operations per word of SID.
>>>>> - Reading via register access will change the value when reading by accessing
>>>>> 0x01c14200.
>>>>> - In the u-boot code[2] there's some functions which read out the SID by
>>>>> registers and then abandoned the value.
>>>>> - This mismatch do not exist on A64.
>>>>>
>>>>> I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>>> code to read it, and it automatically loaded the cache when booting; however,
>>>>> when doing first cache on H3, some byte shifts occured, and the value become
>>>>> wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>>> bug, and fixed in A64.
>>>>>
>>>>> This raises a problem: currently many systems has used the misread SID value to
>>>>> generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>>
>>>>> However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>>> (as some calibartion value lies in eFUSE). I think some early user of this
>>>>> driver has already experienced bad readout value.
>>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>>> think sunxi-fel must have the workaround)
>>>>>
>>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>> Experiments:
>>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>> A SID readout shell script via FEL with register access.
>>>>> - https://31.135.195.151:20281/d/efuse/
>>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>>> (with statically compiled binary)
>>>>
>>>> Good detective work!
>>>>
>>>> I believe this would best be fixed by making u-boot use the register access
>>>> method to get the SID on affected chips, and make sure u-boot reads the
>>>> SID at-least once.
>>>
>>> Yes.
>>>
>>> However, what I considered is that fixing this bug will change H3 devices'
>>> MAC addresses, as they are derived from SID.
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>>
>>> Maybe we should add #ifdef's to MAC generation code after this fix.
>>
>> I would rather not see #ifdefs for this, see above, but that is no
>> longer my call, see below.
>>
>>> (This is why I will create this discussion)
>>>
>>> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>>> MAINTAINER file in board/sunxi indicates this.
>>
>> No I'm no longer the maintainer, I'm still the MAINTAINER file because
>> I have a lot of boards and as such I'm still the point of contact for
>> those boards (if there are any board specific issues / questions), but
>> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
>> is the maintainer now.
>
> But the current status of the file will indicates you are the maintainer of boards
> support of sunxi.
No it indicates that I'm the maintainer for the defconfig files for a whole list
of boards, nothing more and nothing less.
If you think it needs to be clarified, feel free to submit a patch to make this
more clear.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-19 16:27 ` Hans de Goede
0 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-19 16:27 UTC (permalink / raw)
To: u-boot
Hi,
On 19-12-16 17:25, Icenowy Zheng wrote:
>
>
> 20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>> Hi,
>>>>
>>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>> controller of H3 (incl. H2+).
>>>>>
>>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>>> directly access 0x01c14200.
>>>>>
>>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>>> legacy kernel).
>>>>>
>>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>>> 0x58 is H3D (currently not known SoC) )
>>>>>
>>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>>> with 0x02004620, which do not match this rule.
>>>>>
>>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>>> 0x02c00081, matches H3.
>>>>>
>>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>> register operations. With this kind of code (I wrote one prototype in
>>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>>> And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>>> also "02c00081".
>>>>>
>>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>>> "02004620".
>>>>>
>>>>> Then I altered the program to do the register operations with sunxi-fel, the
>>>>> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>>
>>>>> Summary:
>>>>>
>>>>> +-----------------------------------------------+----------------+
>>>>> | Read situation | The first word |
>>>>> +-----------------------------------------------+----------------+
>>>>> | Direct read by sunxi-fel | 02004620 |
>>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>>> | Register access in FEL | 02c00081 |
>>>>> | Register access in mainline | 02c00081 |
>>>>> | Direct read after register access in FEL | 02c00081 |
>>>>> | Direct read after register access in mainline | 02c00081 |
>>>>> +-----------------------------------------------+----------------+
>>>>>
>>>>> According to some facts:
>>>>> - The register based access to SID is weird: it needs ~5 register
>>>>> operations per word of SID.
>>>>> - Reading via register access will change the value when reading by accessing
>>>>> 0x01c14200.
>>>>> - In the u-boot code[2] there's some functions which read out the SID by
>>>>> registers and then abandoned the value.
>>>>> - This mismatch do not exist on A64.
>>>>>
>>>>> I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>>> code to read it, and it automatically loaded the cache when booting; however,
>>>>> when doing first cache on H3, some byte shifts occured, and the value become
>>>>> wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>>> bug, and fixed in A64.
>>>>>
>>>>> This raises a problem: currently many systems has used the misread SID value to
>>>>> generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>>
>>>>> However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>>> (as some calibartion value lies in eFUSE). I think some early user of this
>>>>> driver has already experienced bad readout value.
>>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>>> think sunxi-fel must have the workaround)
>>>>>
>>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>> Experiments:
>>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>> A SID readout shell script via FEL with register access.
>>>>> - https://31.135.195.151:20281/d/efuse/
>>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>>> (with statically compiled binary)
>>>>
>>>> Good detective work!
>>>>
>>>> I believe this would best be fixed by making u-boot use the register access
>>>> method to get the SID on affected chips, and make sure u-boot reads the
>>>> SID at-least once.
>>>
>>> Yes.
>>>
>>> However, what I considered is that fixing this bug will change H3 devices'
>>> MAC addresses, as they are derived from SID.
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>>
>>> Maybe we should add #ifdef's to MAC generation code after this fix.
>>
>> I would rather not see #ifdefs for this, see above, but that is no
>> longer my call, see below.
>>
>>> (This is why I will create this discussion)
>>>
>>> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>>> MAINTAINER file in board/sunxi indicates this.
>>
>> No I'm no longer the maintainer, I'm still the MAINTAINER file because
>> I have a lot of boards and as such I'm still the point of contact for
>> those boards (if there are any board specific issues / questions), but
>> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
>> is the maintainer now.
>
> But the current status of the file will indicates you are the maintainer of boards
> support of sunxi.
No it indicates that I'm the maintainer for the defconfig files for a whole list
of boards, nothing more and nothing less.
If you think it needs to be clarified, feel free to submit a patch to make this
more clear.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
2016-12-19 15:22 ` [U-Boot] " Icenowy Zheng
@ 2016-12-20 11:18 ` Bernhard Nortmann
-1 siblings, 0 replies; 20+ messages in thread
From: Bernhard Nortmann @ 2016-12-20 11:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi all!
This is rather interesting stuff. Actually it's possible to find partial
documentation for this method (of reading SID/efuse values) even for older
SoCs. There's an early version of the A20 User Manual (Revision 1.0 -
Feb. 18, 2013) available on the net, where chapter 1.18 describes the
registers involved. This section seems to have been removed in later
editions. (Search for the file A20_UM-V1.020130322.pdf)
The U-Boot code that Allwinner published also has source files for various
SoCs that contain corresponding implementations of `sid_program_key()` and
`sid_read_key()` (in efuse.c),
see https://github.com/allwinner-zh/bootloader/search?q=sid_read_key.
Regards, B. Nortmann
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel | 02004620 |
> | Direct read in mainline /dev/mem | 02004620 |
> | Direct read in legacy /dev/mem | 02c00081 |
> | Register access in FEL | 02c00081 |
> | Register access in mainline | 02c00081 |
> | Direct read after register access in FEL | 02c00081 |
> | Direct read after register access in mainline | 02c00081 |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> - Reading via register access will change the value when reading by accessing
> 0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
> registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
> A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
> A SID readout program via /dev/mem with register access by KotCzarny.
> (with statically compiled binary)
>
> Regards,
> Icenowy
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-20 11:18 ` Bernhard Nortmann
0 siblings, 0 replies; 20+ messages in thread
From: Bernhard Nortmann @ 2016-12-20 11:18 UTC (permalink / raw)
To: u-boot
Hi all!
This is rather interesting stuff. Actually it's possible to find partial
documentation for this method (of reading SID/efuse values) even for older
SoCs. There's an early version of the A20 User Manual (Revision 1.0 -
Feb. 18, 2013) available on the net, where chapter 1.18 describes the
registers involved. This section seems to have been removed in later
editions. (Search for the file A20_UM-V1.020130322.pdf)
The U-Boot code that Allwinner published also has source files for various
SoCs that contain corresponding implementations of `sid_program_key()` and
`sid_read_key()` (in efuse.c),
see https://github.com/allwinner-zh/bootloader/search?q=sid_read_key.
Regards, B. Nortmann
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel | 02004620 |
> | Direct read in mainline /dev/mem | 02004620 |
> | Direct read in legacy /dev/mem | 02c00081 |
> | Register access in FEL | 02c00081 |
> | Register access in mainline | 02c00081 |
> | Direct read after register access in FEL | 02c00081 |
> | Direct read after register access in mainline | 02c00081 |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> - Reading via register access will change the value when reading by accessing
> 0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
> registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
> A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
> A SID readout program via /dev/mem with register access by KotCzarny.
> (with statically compiled binary)
>
> Regards,
> Icenowy
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
2016-12-19 15:22 ` [U-Boot] " Icenowy Zheng
@ 2016-12-21 15:11 ` Bernhard Nortmann
-1 siblings, 0 replies; 20+ messages in thread
From: Bernhard Nortmann @ 2016-12-21 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Side note:
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> [...]
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> [...]
>
My experiments seem to indicate that Allwinner's implementation might be
overly complicated. I have used an alternative approach and did not notice
any issues so far.
They start by reading SID_PRCTL and use bit mask operations to get in the
key index value (PG_INDEX), then use a second write to set OP_LOCK and
READ_START. As far as I can tell, it's sufficient to construct (and write)
a single value from these three components. Allwinner finally clears out
the used bits by another mask operation, simply writing zero seems to get
that job done equally well.
My implementation can be seen in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/uart0-helloworld-sdboot.c#L242-L256
or as assembler code in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/sid_read_root.S#L43-L65
A corresponding PR is at
https://github.com/linux-sunxi/sunxi-tools/pull/91 ,
or you may clone my branch directly
("git clone https://github.com/n1tehawk/sunxi-tools.git -b
20161220_sid-fix").
Testers would be very welcome.
Regards, B. Nortmann
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
@ 2016-12-21 15:11 ` Bernhard Nortmann
0 siblings, 0 replies; 20+ messages in thread
From: Bernhard Nortmann @ 2016-12-21 15:11 UTC (permalink / raw)
To: u-boot
Side note:
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> [...]
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> [...]
>
My experiments seem to indicate that Allwinner's implementation might be
overly complicated. I have used an alternative approach and did not notice
any issues so far.
They start by reading SID_PRCTL and use bit mask operations to get in the
key index value (PG_INDEX), then use a second write to set OP_LOCK and
READ_START. As far as I can tell, it's sufficient to construct (and write)
a single value from these three components. Allwinner finally clears out
the used bits by another mask operation, simply writing zero seems to get
that job done equally well.
My implementation can be seen in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/uart0-helloworld-sdboot.c#L242-L256
or as assembler code in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/sid_read_root.S#L43-L65
A corresponding PR is at
https://github.com/linux-sunxi/sunxi-tools/pull/91 ,
or you may clone my branch directly
("git clone https://github.com/n1tehawk/sunxi-tools.git -b
20161220_sid-fix").
Testers would be very welcome.
Regards, B. Nortmann
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
2016-12-19 16:17 ` [U-Boot] " Hans de Goede
@ 2016-12-22 10:31 ` Chen-Yu Tsai
-1 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Tsai @ 2016-12-22 10:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>>
>>
>>
>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>
>>> Hi,
>>>
>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> controller of H3 (incl. H2+).
>>>>
>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> Two read method of the H3 eFUSE is used in the BSP: by register
>>>> accessing, or
>>>> directly access 0x01c14200.
>>>>
>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference
>>>> between
>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
>>>> (in
>>>> legacy kernel).
>>>>
>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by
>>>> the last
>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
>>>> H3,
>>>> 0x58 is H3D (currently not known SoC) )
>>>>
>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
>>>> start
>>>> with 0x02004620, which do not match this rule.
>>>>
>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>> 0x02c00081, matches H3.
>>>>
>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> register operations. With this kind of code (I wrote one prototype in
>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
>>>> on
>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel
>>>> sid)
>>>> And, after accessing to the SID by registers, the value of *0x01c14200
>>>> become
>>>> also "02c00081".
>>>>
>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got
>>>> also
>>>> "02004620".
>>>>
>>>> Then I altered the program to do the register operations with
>>>> sunxi-fel, the
>>>> result is also "02c00081", and changed `sunxi-fel sid` result to
>>>> "02c00081".
>>>>
>>>> Summary:
>>>>
>>>> +-----------------------------------------------+----------------+
>>>> | Read situation | The first word |
>>>> +-----------------------------------------------+----------------+
>>>> | Direct read by sunxi-fel | 02004620 |
>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>> | Register access in FEL | 02c00081 |
>>>> | Register access in mainline | 02c00081 |
>>>> | Direct read after register access in FEL | 02c00081 |
>>>> | Direct read after register access in mainline | 02c00081 |
>>>> +-----------------------------------------------+----------------+
>>>>
>>>> According to some facts:
>>>> - The register based access to SID is weird: it needs ~5 register
>>>> operations per word of SID.
>>>> - Reading via register access will change the value when reading by
>>>> accessing
>>>> 0x01c14200.
>>>> - In the u-boot code[2] there's some functions which read out the SID
>>>> by
>>>> registers and then abandoned the value.
>>>> - This mismatch do not exist on A64.
>>>>
>>>> I think that: Allwinner designed a "cache" to the SID to make the
>>>> simplify the
>>>> code to read it, and it automatically loaded the cache when booting;
>>>> however,
>>>> when doing first cache on H3, some byte shifts occured, and the value
>>>> become
>>>> wrong. A manual read on H3 can make the cache right again. This is a
>>>> silicon
>>>> bug, and fixed in A64.
>>>>
>>>> This raises a problem: currently many systems has used the misread SID
>>>> value to
>>>> generated lots of MAC addresses, and workaround this SID bug will
>>>> change them.
>>>>
>>>> However, if this bug is not workarounded, the sun8i-ths driver won't
>>>> work well
>>>> (as some calibartion value lies in eFUSE). I think some early user of
>>>> this
>>>> driver has already experienced bad readout value.
>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> And many wrong SID values have been generated by `sunxi-fel sid`.
>>>> (Although I
>>>> think sunxi-fel must have the workaround)
>>>>
>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on
>>>> H3/A64
>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> [1]
>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> [2]
>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> Experiments:
>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> A SID readout shell script via FEL with register access.
>>>> - https://31.135.195.151:20281/d/efuse/
>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>> (with statically compiled binary)
>>>
>>>
>>> Good detective work!
>>>
>>> I believe this would best be fixed by making u-boot use the register
>>> access
>>> method to get the SID on affected chips, and make sure u-boot reads the
>>> SID at-least once.
>>
>>
>> Yes.
>>
>> However, what I considered is that fixing this bug will change H3 devices'
>> MAC addresses, as they are derived from SID.
>
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
Do we still need to do the CRC32 across the SID values to generate
the MAC addresses?
ChenYu
>> Maybe we should add #ifdef's to MAC generation code after this fix.
>
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>>
>> (This is why I will create this discussion)
>>
>> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> MAINTAINER file in board/sunxi indicates this.
>
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.
>
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
@ 2016-12-22 10:31 ` Chen-Yu Tsai
0 siblings, 0 replies; 20+ messages in thread
From: Chen-Yu Tsai @ 2016-12-22 10:31 UTC (permalink / raw)
To: u-boot
On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>>
>>
>>
>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>
>>> Hi,
>>>
>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> controller of H3 (incl. H2+).
>>>>
>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> Two read method of the H3 eFUSE is used in the BSP: by register
>>>> accessing, or
>>>> directly access 0x01c14200.
>>>>
>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference
>>>> between
>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
>>>> (in
>>>> legacy kernel).
>>>>
>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by
>>>> the last
>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
>>>> H3,
>>>> 0x58 is H3D (currently not known SoC) )
>>>>
>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
>>>> start
>>>> with 0x02004620, which do not match this rule.
>>>>
>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>> 0x02c00081, matches H3.
>>>>
>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> register operations. With this kind of code (I wrote one prototype in
>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
>>>> on
>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel
>>>> sid)
>>>> And, after accessing to the SID by registers, the value of *0x01c14200
>>>> become
>>>> also "02c00081".
>>>>
>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got
>>>> also
>>>> "02004620".
>>>>
>>>> Then I altered the program to do the register operations with
>>>> sunxi-fel, the
>>>> result is also "02c00081", and changed `sunxi-fel sid` result to
>>>> "02c00081".
>>>>
>>>> Summary:
>>>>
>>>> +-----------------------------------------------+----------------+
>>>> | Read situation | The first word |
>>>> +-----------------------------------------------+----------------+
>>>> | Direct read by sunxi-fel | 02004620 |
>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>> | Register access in FEL | 02c00081 |
>>>> | Register access in mainline | 02c00081 |
>>>> | Direct read after register access in FEL | 02c00081 |
>>>> | Direct read after register access in mainline | 02c00081 |
>>>> +-----------------------------------------------+----------------+
>>>>
>>>> According to some facts:
>>>> - The register based access to SID is weird: it needs ~5 register
>>>> operations per word of SID.
>>>> - Reading via register access will change the value when reading by
>>>> accessing
>>>> 0x01c14200.
>>>> - In the u-boot code[2] there's some functions which read out the SID
>>>> by
>>>> registers and then abandoned the value.
>>>> - This mismatch do not exist on A64.
>>>>
>>>> I think that: Allwinner designed a "cache" to the SID to make the
>>>> simplify the
>>>> code to read it, and it automatically loaded the cache when booting;
>>>> however,
>>>> when doing first cache on H3, some byte shifts occured, and the value
>>>> become
>>>> wrong. A manual read on H3 can make the cache right again. This is a
>>>> silicon
>>>> bug, and fixed in A64.
>>>>
>>>> This raises a problem: currently many systems has used the misread SID
>>>> value to
>>>> generated lots of MAC addresses, and workaround this SID bug will
>>>> change them.
>>>>
>>>> However, if this bug is not workarounded, the sun8i-ths driver won't
>>>> work well
>>>> (as some calibartion value lies in eFUSE). I think some early user of
>>>> this
>>>> driver has already experienced bad readout value.
>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> And many wrong SID values have been generated by `sunxi-fel sid`.
>>>> (Although I
>>>> think sunxi-fel must have the workaround)
>>>>
>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on
>>>> H3/A64
>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> [1]
>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> [2]
>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> Experiments:
>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> A SID readout shell script via FEL with register access.
>>>> - https://31.135.195.151:20281/d/efuse/
>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>> (with statically compiled binary)
>>>
>>>
>>> Good detective work!
>>>
>>> I believe this would best be fixed by making u-boot use the register
>>> access
>>> method to get the SID on affected chips, and make sure u-boot reads the
>>> SID at-least once.
>>
>>
>> Yes.
>>
>> However, what I considered is that fixing this bug will change H3 devices'
>> MAC addresses, as they are derived from SID.
>
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
Do we still need to do the CRC32 across the SID values to generate
the MAC addresses?
ChenYu
>> Maybe we should add #ifdef's to MAC generation code after this fix.
>
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>>
>> (This is why I will create this discussion)
>>
>> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> MAINTAINER file in board/sunxi indicates this.
>
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.
>
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
2016-12-22 10:31 ` [U-Boot] " Chen-Yu Tsai
@ 2016-12-22 10:41 ` Hans de Goede
-1 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-22 10:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 22-12-16 11:31, Chen-Yu Tsai wrote:
> On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>>
>>>
>>>
>>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>>
>>>> Hi,
>>>>
>>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>> controller of H3 (incl. H2+).
>>>>>
>>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>> Two read method of the H3 eFUSE is used in the BSP: by register
>>>>> accessing, or
>>>>> directly access 0x01c14200.
>>>>>
>>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference
>>>>> between
>>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
>>>>> (in
>>>>> legacy kernel).
>>>>>
>>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by
>>>>> the last
>>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
>>>>> H3,
>>>>> 0x58 is H3D (currently not known SoC) )
>>>>>
>>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
>>>>> start
>>>>> with 0x02004620, which do not match this rule.
>>>>>
>>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>>> 0x02c00081, matches H3.
>>>>>
>>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>> register operations. With this kind of code (I wrote one prototype in
>>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
>>>>> on
>>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel
>>>>> sid)
>>>>> And, after accessing to the SID by registers, the value of *0x01c14200
>>>>> become
>>>>> also "02c00081".
>>>>>
>>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got
>>>>> also
>>>>> "02004620".
>>>>>
>>>>> Then I altered the program to do the register operations with
>>>>> sunxi-fel, the
>>>>> result is also "02c00081", and changed `sunxi-fel sid` result to
>>>>> "02c00081".
>>>>>
>>>>> Summary:
>>>>>
>>>>> +-----------------------------------------------+----------------+
>>>>> | Read situation | The first word |
>>>>> +-----------------------------------------------+----------------+
>>>>> | Direct read by sunxi-fel | 02004620 |
>>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>>> | Register access in FEL | 02c00081 |
>>>>> | Register access in mainline | 02c00081 |
>>>>> | Direct read after register access in FEL | 02c00081 |
>>>>> | Direct read after register access in mainline | 02c00081 |
>>>>> +-----------------------------------------------+----------------+
>>>>>
>>>>> According to some facts:
>>>>> - The register based access to SID is weird: it needs ~5 register
>>>>> operations per word of SID.
>>>>> - Reading via register access will change the value when reading by
>>>>> accessing
>>>>> 0x01c14200.
>>>>> - In the u-boot code[2] there's some functions which read out the SID
>>>>> by
>>>>> registers and then abandoned the value.
>>>>> - This mismatch do not exist on A64.
>>>>>
>>>>> I think that: Allwinner designed a "cache" to the SID to make the
>>>>> simplify the
>>>>> code to read it, and it automatically loaded the cache when booting;
>>>>> however,
>>>>> when doing first cache on H3, some byte shifts occured, and the value
>>>>> become
>>>>> wrong. A manual read on H3 can make the cache right again. This is a
>>>>> silicon
>>>>> bug, and fixed in A64.
>>>>>
>>>>> This raises a problem: currently many systems has used the misread SID
>>>>> value to
>>>>> generated lots of MAC addresses, and workaround this SID bug will
>>>>> change them.
>>>>>
>>>>> However, if this bug is not workarounded, the sun8i-ths driver won't
>>>>> work well
>>>>> (as some calibartion value lies in eFUSE). I think some early user of
>>>>> this
>>>>> driver has already experienced bad readout value.
>>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>> And many wrong SID values have been generated by `sunxi-fel sid`.
>>>>> (Although I
>>>>> think sunxi-fel must have the workaround)
>>>>>
>>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on
>>>>> H3/A64
>>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>> [1]
>>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>> [2]
>>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>> Experiments:
>>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>> A SID readout shell script via FEL with register access.
>>>>> - https://31.135.195.151:20281/d/efuse/
>>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>>> (with statically compiled binary)
>>>>
>>>>
>>>> Good detective work!
>>>>
>>>> I believe this would best be fixed by making u-boot use the register
>>>> access
>>>> method to get the SID on affected chips, and make sure u-boot reads the
>>>> SID at-least once.
>>>
>>>
>>> Yes.
>>>
>>> However, what I considered is that fixing this bug will change H3 devices'
>>> MAC addresses, as they are derived from SID.
>>
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>
> Do we still need to do the CRC32 across the SID values to generate
> the MAC addresses?
Yes this does not change that a single word has not enough
randomness in it.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
@ 2016-12-22 10:41 ` Hans de Goede
0 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2016-12-22 10:41 UTC (permalink / raw)
To: u-boot
Hi,
On 22-12-16 11:31, Chen-Yu Tsai wrote:
> On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>>
>>>
>>>
>>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>>
>>>> Hi,
>>>>
>>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>> controller of H3 (incl. H2+).
>>>>>
>>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>> Two read method of the H3 eFUSE is used in the BSP: by register
>>>>> accessing, or
>>>>> directly access 0x01c14200.
>>>>>
>>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference
>>>>> between
>>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
>>>>> (in
>>>>> legacy kernel).
>>>>>
>>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by
>>>>> the last
>>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
>>>>> H3,
>>>>> 0x58 is H3D (currently not known SoC) )
>>>>>
>>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
>>>>> start
>>>>> with 0x02004620, which do not match this rule.
>>>>>
>>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>>> 0x02c00081, matches H3.
>>>>>
>>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>> register operations. With this kind of code (I wrote one prototype in
>>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
>>>>> on
>>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel
>>>>> sid)
>>>>> And, after accessing to the SID by registers, the value of *0x01c14200
>>>>> become
>>>>> also "02c00081".
>>>>>
>>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got
>>>>> also
>>>>> "02004620".
>>>>>
>>>>> Then I altered the program to do the register operations with
>>>>> sunxi-fel, the
>>>>> result is also "02c00081", and changed `sunxi-fel sid` result to
>>>>> "02c00081".
>>>>>
>>>>> Summary:
>>>>>
>>>>> +-----------------------------------------------+----------------+
>>>>> | Read situation | The first word |
>>>>> +-----------------------------------------------+----------------+
>>>>> | Direct read by sunxi-fel | 02004620 |
>>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>>> | Register access in FEL | 02c00081 |
>>>>> | Register access in mainline | 02c00081 |
>>>>> | Direct read after register access in FEL | 02c00081 |
>>>>> | Direct read after register access in mainline | 02c00081 |
>>>>> +-----------------------------------------------+----------------+
>>>>>
>>>>> According to some facts:
>>>>> - The register based access to SID is weird: it needs ~5 register
>>>>> operations per word of SID.
>>>>> - Reading via register access will change the value when reading by
>>>>> accessing
>>>>> 0x01c14200.
>>>>> - In the u-boot code[2] there's some functions which read out the SID
>>>>> by
>>>>> registers and then abandoned the value.
>>>>> - This mismatch do not exist on A64.
>>>>>
>>>>> I think that: Allwinner designed a "cache" to the SID to make the
>>>>> simplify the
>>>>> code to read it, and it automatically loaded the cache when booting;
>>>>> however,
>>>>> when doing first cache on H3, some byte shifts occured, and the value
>>>>> become
>>>>> wrong. A manual read on H3 can make the cache right again. This is a
>>>>> silicon
>>>>> bug, and fixed in A64.
>>>>>
>>>>> This raises a problem: currently many systems has used the misread SID
>>>>> value to
>>>>> generated lots of MAC addresses, and workaround this SID bug will
>>>>> change them.
>>>>>
>>>>> However, if this bug is not workarounded, the sun8i-ths driver won't
>>>>> work well
>>>>> (as some calibartion value lies in eFUSE). I think some early user of
>>>>> this
>>>>> driver has already experienced bad readout value.
>>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>> And many wrong SID values have been generated by `sunxi-fel sid`.
>>>>> (Although I
>>>>> think sunxi-fel must have the workaround)
>>>>>
>>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on
>>>>> H3/A64
>>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>> [1]
>>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>> [2]
>>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>> Experiments:
>>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>> A SID readout shell script via FEL with register access.
>>>>> - https://31.135.195.151:20281/d/efuse/
>>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>>> (with statically compiled binary)
>>>>
>>>>
>>>> Good detective work!
>>>>
>>>> I believe this would best be fixed by making u-boot use the register
>>>> access
>>>> method to get the SID on affected chips, and make sure u-boot reads the
>>>> SID at-least once.
>>>
>>>
>>> Yes.
>>>
>>> However, what I considered is that fixing this bug will change H3 devices'
>>> MAC addresses, as they are derived from SID.
>>
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>
> Do we still need to do the CRC32 across the SID values to generate
> the MAC addresses?
Yes this does not change that a single word has not enough
randomness in it.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-12-22 10:41 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-19 15:22 Problems to Allwinner H3's eFUSE/SID Icenowy Zheng
2016-12-19 15:22 ` [U-Boot] " Icenowy Zheng
2016-12-19 15:30 ` Hans de Goede
2016-12-19 15:30 ` [U-Boot] " Hans de Goede
2016-12-19 16:06 ` Icenowy Zheng
2016-12-19 16:06 ` [U-Boot] " Icenowy Zheng
2016-12-19 16:17 ` Hans de Goede
2016-12-19 16:17 ` [U-Boot] " Hans de Goede
2016-12-19 16:25 ` Icenowy Zheng
2016-12-19 16:25 ` [U-Boot] " Icenowy Zheng
2016-12-19 16:27 ` Hans de Goede
2016-12-19 16:27 ` [U-Boot] " Hans de Goede
2016-12-22 10:31 ` [linux-sunxi] " Chen-Yu Tsai
2016-12-22 10:31 ` [U-Boot] " Chen-Yu Tsai
2016-12-22 10:41 ` Hans de Goede
2016-12-22 10:41 ` [U-Boot] " Hans de Goede
2016-12-20 11:18 ` [linux-sunxi] " Bernhard Nortmann
2016-12-20 11:18 ` [U-Boot] " Bernhard Nortmann
2016-12-21 15:11 ` Bernhard Nortmann
2016-12-21 15:11 ` [U-Boot] " Bernhard Nortmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.