[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