Genio 520 - failures reading efuse

Hi - we’re experiencing intermittent failures when reading efuse registers.

I don’t have steps to reproduce the failure yet.

Below are my observations:

  1. Start an ssh session using ssh root@192.168.96.1
  2. Run the following command: for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''

Successful run displays the following output:

root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
09f85af255008516b325a00e6f4d0ac7

Failed command displays the following output:

root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
ecf9f735failed to read efusefailed to read efusefailed to read efuse

In addition, here’s a log where I repeatedly ran the command when it was failing:

root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
failed to read efuse55008516b325a00efailed to read efuse
root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
failed to read efuse55008516failed to read efusefailed to read efuse
root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
failed to read efusefailed to read efusefailed to read efusefailed to read efuse
root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
09f85af2failed to read efusefailed to read efusefailed to read efuse
root@genio520:~# for i in {12..15} ; do ewriter 0 $i 4 | head -n 2 | tail -n 1 | head -c -1; done; echo ''
09f85af2failed to read efusefailed to read efuse6f4d0ac7

Upon rebooting the hardware, the command does appear to run successfully, though.

Could you help us understand what could be going wrong? Does this failure point to a potential flaw in the hardware design?

This is a blocker for implementing secure boot feature in our platform.

Hence any pointers or help diagnosing or working around this failure would be helpful.

Thanks in advance!

Hi - we resolved this bug. Thanks!