garagoyun Wrote:
> bootcmd=nand reset; nand read.e 0x800000
> 0x00100000 0x00199800; check_crc32 PrEr; nand
> reset; nand read.e 0x40000 0x00380000 0x0027d400;
> check_crc32 KrNl; setenv bootargs $(console)
> $(bootargs_root); bootm 0x40000;
> It has both the new and stock env. I suspect that
> could be the reason the stock envs are taking
> over.
> Interestingly, if I interrupt and just type 'run
> bootcmd_exec' and enter without repeating the
> other setenvs, the device boots from the USB.
Yes. saveenv worked in that it saves all new envs to NAND. But when the box starts, bootcmd got restored to stock (only bootcmd). This is quite common with stock u-boot whether it is intenionally or not (I suspect that it was sloppy coding, not intentional).
Until I can find out where that happens in u-boot code, and what to do to negate that problem. We need serial console to boot the new rootfs (We cannot flash new uImage to NAND yet, because of their checksum check).
> bootcmd=nand reset; nand read.e 0x800000
> 0x00100000 0x00199800; check_crc32 PrEr; nand
> reset; nand read.e 0x40000 0x00380000 0x0027d400;
> check_crc32 KrNl; setenv bootargs $(console)
> $(bootargs_root); bootm 0x40000;
> It has both the new and stock env. I suspect that
> could be the reason the stock envs are taking
> over.
> Interestingly, if I interrupt and just type 'run
> bootcmd_exec' and enter without repeating the
> other setenvs, the device boots from the USB.
Yes. saveenv worked in that it saves all new envs to NAND. But when the box starts, bootcmd got restored to stock (only bootcmd). This is quite common with stock u-boot whether it is intenionally or not (I suspect that it was sloppy coding, not intentional).
Until I can find out where that happens in u-boot code, and what to do to negate that problem. We need serial console to boot the new rootfs (We cannot flash new uImage to NAND yet, because of their checksum check).
