Occasional Contributorrsu_client failing to write to slot
Hello,
I am trying to exercise the rsu_client (from Intel's remote system update feature) by erasing a partition on the flash and writing a new file and loading that on the next reboot.
This feature works but very very occasionally I encounter an issue where the writing portion fails and the only way that I know to recover from this is to rewrite the flash with the JIC file.
I am wondering if someone can advise on how/why this could happen?
The feature works robustly most of the time but the said error would require a manual intervention by connecting the JTAG cable.
also is it possible to recover from this using the existing rsu_client?
I have attached some of the output of the rsu_client for your reference.
I do not see any specific message when running `dmesg` on HPS or by inspecting the log in u-boot related to the SPTs/CPBs or QSPI read failure.
Note that I do not think this is related to the Flash being worn-out from 1000s of write cycles, the Flash is new and I am seeing this issue on multiple different boards.
root@stratix10:~# rsu_client --log VERSION: 0x00000202 STATE: 0x00000000 CURRENT IMAGE: 0x0000000001000000 FAIL IMAGE: 0x0000000000000000 ERROR LOC: 0x00000000 ERROR DETAILS: 0x00000000 RETRY COUNTER: 0x00000000 Operation completed root@stratix10:~# rsu_client --list 0 NAME: P1 OFFSET: 0x0000000001000000 SIZE: 0x01000000 PRIORITY: 1 Operation completed root@stratix10:~# rsu_client --list 1 NAME: P2 OFFSET: 0x0000000002000000 SIZE: 0x01000000 PRIORITY: [disabled] Operation completed root@stratix10:~# rsu_client --list 2 NAME: P3 OFFSET: 0x0000000003000000 SIZE: 0x01000000 PRIORITY: [disabled] Operation completed root@stratix10:~# rsu_client -y DCMF0: OK DCMF1: OK DCMF2: OK DCMF3: OK Operation completed root@stratix10:~# rsu_client -m DCMF0 version = 23.1.0 DCMF1 version = 23.1.0 DCMF2 version = 23.1.0 DCMF3 version = 23.1.0 Operation completed root@stratix10:~# rsu_client --erase 1 Operation completed root@stratix10:~#rsu_client --add application.hps.rpd --slot 1 librsu: priority_add(): Compressing CPB [MED] librsu: erase_dev(): error: Erase length 32768 not erase block aligned [LOW] librsu: writeback_cpb(): error: Unable to ease CPBx [LOW] ERROR: Failed to enable slot
Thank you!
Dear all,
I had the same issue. Here is my solution for future reference.
I can reproduce this using the following script:
for i in {1..2000}; do
echo "Iteration $i"
rsu_client --erase 0 || break
rsu_client --add update.rpd --slot 0 || break
done
Using this script the problem occurs every 508th iteration on my system. Once in the error state, I can only get out of it by flashing the .jic file. Running the commands in U-Boot did not work for me.
In iteration 1-507 the rsu_client performs a "write" to update the CPB. In the 508th iteration it performs an additional "erase" before the "write". This is why it occurs so infrequently.
For me the fix was to increase the size of the SPT and CPB partitions to the erase size of my QSPI flash (64KiB) in the programming file generator file (.pfg).
Kind Regards,
Eric Opitz
