• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1] 2 3
Author Topic: uboot-envtools  (Read 27723 times)
plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« on: April 19, 2009, 05:37:59 PM »

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)
« Last Edit: April 19, 2009, 05:39:42 PM by plugit » Logged

Rabeeh Khoury
Administrator
Full Member
*****

Karma: 5
Posts: 218


View Profile
« Reply #1 on: April 19, 2009, 10:01:51 PM »

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.
Logged

Raśl Porcel
Global Moderator
Jr. Member
*****

Karma: 0
Posts: 68


View Profile
« Reply #2 on: April 20, 2009, 03:15:12 AM »

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
Logged

Rabeeh Khoury
Administrator
Full Member
*****

Karma: 5
Posts: 218


View Profile
« Reply #3 on: April 20, 2009, 03:59:56 AM »

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
--------
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #4 on: April 20, 2009, 05:49:26 AM »

Nifty. Thanks for the offset info, Rabeeh!
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #5 on: April 20, 2009, 07:08:45 AM »

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
Logged

rshitrit
Global Moderator
Newbie
*****

Karma: 0
Posts: 14


View Profile
« Reply #6 on: April 20, 2009, 09:38:06 AM »

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.

Logged

Ann Onemouse
Newbie
*

Karma: 0
Posts: 12


View Profile
« Reply #7 on: August 16, 2009, 08:31:54 PM »

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

 Undecided
Logged

dieterk
Newbie
*

Karma: 0
Posts: 21


View Profile
« Reply #8 on: September 21, 2009, 01:16:21 AM »

Hi all,

are there any news regarding this issue?

Many thanks,
Dieter
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #9 on: September 21, 2009, 12:47:37 PM »

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

e-squizo
Newbie
*

Karma: 3
Posts: 22


View Profile
« Reply #10 on: March 18, 2010, 05:52:51 AM »

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!
Logged

pingtoo
Sr. Member
****

Karma: 15
Posts: 318


View Profile
« Reply #11 on: March 18, 2010, 10:36:06 AM »

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.
Logged

Good Luck Smiley

e-squizo
Newbie
*

Karma: 3
Posts: 22


View Profile
« Reply #12 on: March 18, 2010, 12:21:07 PM »

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.

Quote
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.
Logged

pingtoo
Sr. Member
****

Karma: 15
Posts: 318


View Profile
« Reply #13 on: March 18, 2010, 02:16:26 PM »

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.

Quote
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  Cheesy
Logged

Good Luck Smiley

e-squizo
Newbie
*

Karma: 3
Posts: 22


View Profile
« Reply #14 on: March 18, 2010, 03:14:31 PM »

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.

Quote
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.

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

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

Pages: [1] 2 3
Print
Jump to: