uboot-envtools

[plugit]

I just discovered the apt-gettable uboot-envtools. Looks like we should be able to get / set the u-Boot environment from within Linux?

I don't have a correct fw_env.config for it yet, though...

root@rlyeh:~ 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


(that's not my environment)

[Rabeeh Khoury]

I think this is the default environment the U-Boot replaces when you have an environment that has CRC errors.
Both resides in /dev/mtdblock0 (from Linux point of view) but the default one you can't change in U-Boot (and you shouldn't change in Linux) while the second one is the actual one being accessed.

[Raúl Porcel]

You need to edit /etc/fw_env.config

With what parameters? No clue, maybe Rabeeh knows.

http://elinux.org/U-boot_environment_variables_in_linux

[Rabeeh Khoury]

U-Boot env variable resides in 0xa0000.
For the size, it didn't work for me at the beginning, but i tried some random number and got 0x70000 to do something, although 0xa0000+0x70000=0x110000, which is bigger than the partition itself.

fw_printenv worked for me, but i couldn't get fw_setenv to work. could it be that it's requiring NOR flash?

Anyhow,

edit /etc/fw_env.config
--------
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.
# MTD device name       Device offset   Env. size       Flash sector size
/dev/mtd0               0xa0000         0x70000         0x20000
--------

[plugit]

Nifty. Thanks for the offset info, Rabeeh!

[plugit]

Still getting a bad CRC here. Oh well.

root@rlyeh:~# cat /etc/fw_env.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.

# MTD device name       Device offset   Env. size       Flash sector size
/dev/mtd0               0xa0000         0x70000         0x20000
root@rlyeh:~# 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

[rshitrit]

I think it won't work...
U-Boot is burned using 4bit ECC including its env variable,
While your Linux probably support only 1 bit ECC.

For the NAND found on the SheevaPlug, 1 bit ECC should be enough since it have an SLC Nand.
However the KW BootROM support only 4bit ECC or none, so it better use the 4 bit ECC...

I think there are few options, all are not simple:
1) Changing the U-Boot to treat the env variable with 1 bit ECC.
2) Rewrite the user tool so it will write to the MTD without ECC and write the 4bit ECC to the OOB manually.
3) Add 4 bit ECC to the Linux, this will be part of future LSP releases, it should be safer for MLC NAND, however it will slow down the NAND access.

[Ann Onemouse]

So the conclusion of this thread was...
There's currently no way for the plug to update its own uBoot settings, from a script?

Is this still true?

- Ann

 

[dieterk]

Hi all,

are there any news regarding this issue?

Many thanks,
Dieter

[restamp]

At the current time, to my knowledge, no one has been successful at updating the Uboot environment from a running kernel.

[e-squizo]

At the current time, to my knowledge, no one has been successful at updating the Uboot environment from a running kernel.

This state of affairs changed yesterday :-)

You can use these tools I wrote for this purpose https://code.google.com/p/sheeva-uboot-tools/

And thanks to the participants of this thread, you guys gave me all the right clues on how to solve it!

[pingtoo]

At the current time, to my knowledge, no one has been successful at updating the Uboot environment from a running kernel.

This state of affairs changed yesterday :-)

You can use these tools I wrote for this purpose https://code.google.com/p/sheeva-uboot-tools/

And thanks to the participants of this thread, you guys gave me all the right clues on how to solve it!

I think in your step you miss the process to erase NAND.

Over all thanks for develop/test this tool. I finish my version as will but have not tested on sheevaplug yet. I want to further develop this to support kernel/initrd upgrade and look at the nandwrite source code it is unnecessary complex logic so I will write a version that will only support for sheevaplug. I will let you know once I finish coding.

[e-squizo]

I think in your step you miss the process to erase NAND.

Not really: nandwrite takes care of that. The beauty of this solution is precisely that it avoids the complexities of NAND handling, something at which mtd-utils is very good.

I want to further develop this to support kernel/initrd upgrade

The sheeva-nandrs-encode program in my package should make it possible to upgrade a plug's u-boot from a running kernel. As to the kernel image/ramdisk... can't you just do that with nandwrite?

I would expect nandwrite -p /dev/mtd1 kernel-image-file to just work, assuming that kernel-image-file is in the right format and is not large enough to overwrite the start of the ramdisk image.

[pingtoo]

I think in your step you miss the process to erase NAND.

Not really: nandwrite takes care of that. The beauty of this solution is precisely that it avoids the complexities of NAND handling, something at which mtd-utils is very good.

I want to further develop this to support kernel/initrd upgrade

The sheeva-nandrs-encode program in my package should make it possible to upgrade a plug's u-boot from a running kernel. As to the kernel image/ramdisk... can't you just do that with nandwrite?

I would expect nandwrite -p /dev/mtd1 kernel-image-file to just work, assuming that kernel-image-file is in the right format and is not large enough to overwrite the start of the ramdisk image.

Actually nandwrite does not do erase.

nandwrite does work but I want to make system that will fit in my initramfs, if I to include some part of mtd-utils and my own code it become too much to work.

Thanks anyway for pointing out.

P.S. I would leave the u-boot upgrade to JTAG itself 

[e-squizo]

Actually nandwrite does not do erase.

If it didin't, it wouldn't be writing. You can't write to NAND if you don't erase first. Either nandwrite is erasing the NAND before writing to it, or the kernel is doing so for it. But you can be sure that someone is erasing the NAND just before writing data to it.

nandwrite does work but I want to make system that will fit in my initramfs, if I to include some part of mtd-utils and my own code it become too much to work.

nandwrite itself is not too large: about 12KB. Doing a smaller program for the same purpose is going to be tricky.

P.S. I would leave the u-boot upgrade to JTAG itself 

Wise man! But well, for those days when one feels adveturous and in the mood to brick a plug for no reason at all... :-)