Where does u-boot store the env variables such as bootargs?

[Ann Onemouse]

Ann, Curious about the boot over nfs part.  Why not install all the development tools with apt-get? 

Yes -- I have indeed used apt-get to install build-essential and the other tools on the Plug itself.

Why NFS?
1) Because I can modify all the Plug's files from both the x86 development server (which has sophisticated editors, scripting languages, etc.), and from the stripped-down Sheeva. Sometimes it's helpful to modify the filesystem when the Sheeva is powered off.
2) When connected with cat6 cable straight to the desktop x86 NFS server (and maybe its RAID?), it's probably the Sheeva's highest-performing storage solution.
3) The Plug can use all the storage space available to the more powerful development system.

ShPlug is definitely fast enough for development. 

I agree -- the Sheeva is fast enough to do its own builds (especially for the things OTHER than the kernel!    ), so that's my intention too.

I would be interested in a full tools howto -- where to get the complete environment, ...

Me too, and have put up a thread requesting same. But in place of that, all we can do is share setups. I've only had my Plug a week, so my set up is rapidly evolving. But currently, it's like this:

I have a linux x86, full desktop / development system, which holds various kernels and root filesystems for the Sheeva. These are ultimately organized under one (grand-)parent directory, and exported over both NFS and TFTP. So switching between kernels or filesystems means changing only one u-boot parameter.

For the record, this development system is actually a VirtualBox virtual machine, hosted on my MacBook Pro, and it has two (virtual) network cards: one is connected (via NAT) to the MacBook's AirPort, for internet connectivity; the other is bridged to the laptop's gigabit ethernet card, which is cabled directly to the Sheeva.

The gigabit interface on the Mac, the gigabit interface on the VirtualBox, and the gigabit interface on the Plug are all configured  on the the 172.16.*.* subnet, and the linux system forwards packets from one interface to the other, so that the Plug can use the VBox's 172.16 address as a gateway.

End result: I can carry all gear with me in my bag, then carry out the following steps when I'm ready to play:
1) Wake laptop from sleep and restore VirtualBox from its latest snapshot (30-45 seconds)
2) Cable Sheeva to laptop and boot. (another 30 seconds or so to SSH prompt)
Any internet access the laptop has is shared among all systems, and there's no need to use the serial cable.*

*except to switch boot settings, which is one more reason why we need this thread resolved!

But I keep thinking it should be possible to write this env utility in a script language, either bash or something like php...  That is my current interest.

  Exactly!

-Ann

[Ann Onemouse]

fw_setenv fw_getenv in Ubuntu is in uboot-envtools package, simply aptitude install it.

Thanks, Rooster! Worked fine, though did not install /etc/fw_env.config. Guess we will create...

You will need to manage to get a mapping to the uboot environment settings (probably add to uboot environments to mtdparts) and then edit the /etc/fw_env.config according to flash sector size and address.

My NAND layout (post alpha6-installer) is:

Code:

root@ubuntu:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 1fb00000 00020000 "root"

My u-boot settings for successfully booting from NAND are:

Code:

setenv bootcmd 'nand read.e 0x800000 0x100000 0x400000; bootm 0x800000'
setenv bootargs 'console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000(u-boot)ro,0x400000@0x100000(uImage)ro,0x1fb00000@0x500000(rootfs)rw root=/dev/mtdblock2 rootfstype=jffs2'

though I'm currently booting from NFS, as noted above in previous post.

The for fw_env.config format is as follows:
...

Cool. Which of the above info is relevant to producing the correct config?

I will try to get the correct settings tomorrow

Thank you!

[CqCn]

Ann,  It seems you are using the original uboot and kernel out of the box?  I had the box for about 3 weeks.  After using for about two weeks, I had some problems... I was thinking of upgrading to Alpha-6 kernel and uboot anyway.  Which I did. New ones are more robust, and I read the new kernel has some distinct speed improvments in the usb disk access area.

It might be worth doing that early.   There is no easy way to port all the work I did on the initial system to the new version external disk;  hence my above recommendation.

[Ann Onemouse]

Update:

I have installed the following /etc/fw_env.config

Code:

# 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

I found this config from the following thread:
http://plugcomputer.org/plugforum/index.php?topic=117.0

As reported in that thread, this config produces a working fw_printenv, but a non-working fw_setenv.
 

Code:

root@ubuntu:~# fw_printenv | grep bootdelay
Read error on /dev/mtd0: Success
bootdelay=3

root@ubuntu:~#  fw_setenv bootdelay 4
Read error on /dev/mtd0: Success
Unlocking flash...
Done
Cannot malloc -327680 bytes: Cannot allocate memory
Error: can't write fw_env to flash

root@ubuntu:~# fw_printenv | grep bootdelay
Read error on /dev/mtd0: Success
bootdelay=3

Hopefully, a slightly tweaked config file can yield better results.

... I was thinking of upgrading to Alpha-6 kernel and uboot anyway.  Which I did.

I also updated my system to the alpha6 stuff right away, CqCn. Been running alpha6 from NFS, NAND, and USB stick, all successfully.

- Ann

[Ann Onemouse]

The error produced when I try to update the u-boot settings:
    Cannot malloc -327680 bytes: Cannot allocate memory
indicates a computational bug in either the fw_setenv tool or its interaction with a dependent library (you can't allocate negative memory!).

Unfortunately, that seems consistent with the description offered in the thread mentioned above:

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.

I was hoping that between April (when that analysis was done) and now someone might have taken on one of the three steps mentioned there.

Or perhaps that analysis is incorrect? I am not qualified to say.

- Ann

[CqCn]

I think that -ve number error can be caused by things other than ECC mismatch.  An arith lib mismatch, with 16bit, 32bit or int, uint is another possibility.  Usually the ECC is internal to the memory interface; the outside interface should not see the ECC per se, but just error msg when ecc fails with a code of type of failure.

[CqCn]

fw_setenv fw_getenv in Ubuntu is in uboot-envtools package, simply aptitude install it.

Thanks, Rooster! Worked fine, though did not install /etc/fw_env.config. Guess we will create...

What exactly is the command to install it?  The usual way I do apt-get does not work, perhaps this module is not in one of the standard repositories setup already for me?

[Ann Onemouse]

That's odd, Cq.

"apt-get install uboot-envtools" worked for me, from the Alpha6 installer. What output do you get from this command?

Can you install other packages? "apt-get install build-essential"?

Finally, what happens when you do this? :

Code:

root@ubuntu:~# cat /etc/apt/sources.list
deb http://ports.ubuntu.com/ jaunty main restricted universe multiverse
deb http://ports.ubuntu.com/ jaunty-updates main restricted universe multiverse
deb http://ports.ubuntu.com/ jaunty-security main restricted universe multiverse

-Ann

[CqCn]

Ann,

Code:

# apt-get install uboot-envtools
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  uboot-envtools
0 upgraded, 1 newly installed, 0 to remove and 21 not upgraded.
Need to get 12.5kB of archives.
After this operation, 102kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com jaunty/universe uboot-envtools 20080520-4 [12.5kB]
Fetched 12.5kB in 0s (17.4kB/s) 
Selecting previously deselected package uboot-envtools.
(Reading database ... 11640 files and directories currently installed.)
Unpacking uboot-envtools (from .../uboot-envtools_20080520-4_armel.deb) ...
Setting up uboot-envtools (20080520-4) ...
root@ubuntu:~# fw_getenv   
-bash: fw_getenv: command not found

I can apt-get install other pkgs ok.

[dattaway]

# fw_printenv
# fw_setenv

[CqCn]

Ann,

My bad   The output for me with your settings:

Code:

root@ubuntu:~# fw_printenv           
[b]Warning: Bad CRC, using default environment[/b]
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200

But the interesting thing is that it does not depend on the value in the config file settings!  I changed my line to (NO BASIS, jut a two numbers I selected):
/dev/mtd0               0xb0000         0x40000         0x20000
or to:
/dev/mtd0               0x10000         0x40000         0x20000
and get identical output for all three settings!!

[Ann Onemouse]

Hey, Rooster.

You will need to
...
edit the /etc/fw_env.config according to flash sector size and address.
...
I will try to get the correct settings tomorrow

Any luck with this?

Eagerly awaiting the ability to have the Sheeva rewrite its own firmware.

- Ann

[rooster]

The installer (sheevaplug_reflash_uboot_env) burns the uboot environments to 0xa0000, but for some reason I do not see any of them with uboot md (memory display) which puzzles me, this could be the root cause of the CRC error since the fw_printenv/setenv first validate the CRC of the environment section.

I will continue my quest for user space manipulation of uboot env...

[CqCn]

... but for some reason I do not see any of them with uboot md (memory display) which puzzles me...

md ??  Which utility is this?  Anyone?

[rooster]

md is part of uboot commands, I also tried the nand command to read the same flash sector:

Marvell>> nand read 0x00800000 a0000 20000

NAND read: device 0 offset 0xa0000, size 0x20000
 131072 bytes read: ERROR
Marvell>> md 0x00800000
00800000: 55583ff8 64756162 65746172 3531313d    .?XUbaudrate=115
00800010: 00303032 64616f6c 63655f73 303d6f68    200.loads_echo=0
00800020: 61706900 3d726464 342e3031 2e30352e    .ipaddr=10.4.50.
00800030: 00353631 76726573 70697265 2e30313d    165.serverip=10.
00800040: 30352e34 7200352e 70746f6f 3d687461    4.50.5.rootpath=
00800050: 746e6d2f 4d52412f 2f53465f 74656e00    /mnt/ARM_FS/.net
00800060: 6b73616d 3535323d 3535322e 3535322e    mask=255.255.255

So it looks like the environment settings are there but the CRC is incorrect, this could be the root cause of failed fw_printenv.

Strange also is the error the nand read returned, it did read the correct number of bytes so why return an error?