On 06/07/2016 11:00 AM, Claudio Leite wrote:
On 06/07/2016 10:48 AM, Dheeran Senthilvel wrote:
[snip]
=======> Step 3: Reboot <======
After the above procedures, I don’t have the error anymore.
Great -- so you're all set, as far as you can tell?
Wonder what really caused the problem in first place.
Given the date when you initially had the issue I suspected that it was
due to bugs in the NAND driver that potentially messed things up in your
u_env. I would have expected 'resetenv' to make quick work of cleaning
that up.
It sort of looks like resetenv only half-cleared the problem. At least
on the other model I tested it on it claims to erase the partition.
Something goes wrong at some point here on your model and the old
corrupted data was kept. 'saveenv' forces rewriting the good data back
to flash.
Responding to myself -- it looks like the "corruption" from u-boot I
thought was going on was just the defaults from uboot-envtools.
fw_setenv, when trying to write the 'auto_recovery=yes' value during
boot, was committing these to the then-empty flash partition.
root@wrt1900ac:/tmp# mtd erase u_env
Unlocking u_env ...
Erasing u_env ...
root@wrt1900ac:/tmp# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
root@wrt1900ac:/tmp# fw_setenv test blah
Warning: Bad CRC, using default environment
root@wrt1900ac:/tmp# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
test=blah
root@wrt1900ac:/tmp#
So, no corruption at all. The bootloader resetenv just didn't commit the
default values back to flash.
-Claudio
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
