[U-Boot] Bug in saveenv handling?
U.Mutlu
for-gmane at mutluit.com
Tue Apr 9 19:05:17 UTC 2019
I just made this unpleasant observation while playing with u-boot:
On the u-boot CLI I changed an envvar and saved the env:
setenv bootdelay 5 ; saveenv
Then I issued, just for fun, the command "scsi scan", but it crashed
and rebooted the device. But this time on the display only the tuxx logo
and the very first u-boot line is displayed, nothing else happens.
It seems u-boot has overwritten parts of itself on the storage medium (uSD
with FAT boot partition).
I had this experience some more times in the past; after writing u-boot anew
to the uSD it continued working again.
Btw, I once even had the case where saveenv overwrote boot.cmd (but nothing
else) with garbage (IIRC it was filled full with the char @ ).
I mention this just because it seems that there's maybe a bug in u-boot's
saveenv handling (maybe data was not completely flushed, file handle
was not closed, or maybe the fat write routine is buggy?...).
=> setenv bootdelay 5 ; saveenv
Saving Environment to FAT... OK
=> printenv bootdelay
bootdelay=5
=> scsi scan
scanning bus for devices...
data abort
pc : [<7ef94f8e>] lr : [<7ef911a1>]
reloc pc : [<4a01af8e>] lr : [<4a0171a1>]
sp : 7af51bf8 ip : 0000001c fp : 000000c0
r10: 00000000 r9 : 7af59ed8 r8 : 00000000
r7 : 7af51e78 r6 : 7efd3f54 r5 : 7efdb9b8 r4 : 7efdb9b8
r3 : 00000000 r2 : 00000000 r1 : ea000016 r0 : 7efdb9b8
Flags: nZcv IRQs off FIQs off Mode SVC_32
Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604)
Resetting CPU ...
resetting ...
More information about the U-Boot
mailing list