Getting started with uboot

Where does uboot store the environment variables?

I have my tx25 board booting correctly from uboot when entering interactive commands:

But when I call 'saveenv' then it doesn't boot any longer; it seems that 'saveenv' overwrites parts of the root file system.

So, my question is: where does uboot save the environment?

Thanks,
Thomas

If you take a look in include/configs/xt25.h (which should be the definition of your board) this contains (e.g. on a 2010.06)

...
#define CONFIG_SYS_MONITOR_LEN (256 << 10) /* 256 kB for U-Boot */
...
/* No NOR flash present */
#define CONFIG_SYS_NO_FLASH 1
#define CONFIG_ENV_IS_IN_NAND
#define CONFIG_ENV_OFFSET CONFIG_SYS_MONITOR_LEN
#define CONFIG_ENV_SIZE (128 * 1024) /* 128 kB NAND block size */
#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)

It will look for the environment@offset 256k and for a redundant one at 256k+128k.

hth
E.

Elie De Brauwer

Dear Thomas Heller,

Check the board config file:

include/configs/tx25.h:
33
34 #define CONFIG_SYS_MONITOR_LEN (256 << 10) /* 256 kB for U-Boot */
35
...

102 #define CONFIG_ENV_IS_IN_NAND
103 #define CONFIG_ENV_OFFSET CONFIG_SYS_MONITOR_LEN
104 #define CONFIG_ENV_SIZE (128 * 1024) /* 128 kB NAND block size */
105 #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)

0x02040000 is more than 32 MiB, i. e. far, far away from the envrionment.

This does not happen on my system. "saveenv" leaves the whole NAND starting at offset 0x80000 and above untouched.

Is this an original TX25 board? Did you make any modifications to U-Boot?

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hi there! This is just a note from me, to you, to tell you, the  per-
son  reading this note, that I can't think up any more famous quotes,
jokes, nor bizarre stories, so you may as well go home.

Yes, but this is the kernel partition. The rootfs starts at a lower address. And actually this is the problem: I put uboot into the RedBoot flash partition, which is only 0x40000 in size (256 kB), but uboot apparently needs much more.

Which raises the question: why is the environment so large? Wouldn't a few kB be enough (4kB, 16kB for example)?

Thanks, also to Elie, for the quick answers. I'll get it to work now.

Thomas

Dear Thomas Heller,

Right - it needs two more flash blocks.

NAND flash cannot be erased in arbitray sizes, but only in blocks; on the TX25 the erase block size is 128 kB. So with redundant environment we need two block for the U-Boot code, and two more for the 2 copies of the environment = a total of 512 KiB.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The Buddha, the Godhead, resides quite as comfortably in the circuits
of a digital computer or the gears of a cycle transmission as he does
at the top of a mountain or in the petals of a flower.
            - R.  Pirsig, "Zen and the Art of Motorcycle Maintenance"

Thanks again for the help, it works now.

Next question:

'make uImage' in the linux kernel tree builds a linux kernel image that u-boot can use. How can I change the compression that is used?

Actually, I'm not even sure whether my kernel is compressed or not. Here is the laat part of the output from 'make uImage'; it tells me the kernel is not compressed:

however the embedded system tells me it is uncompressing:

Thanks,
Thomas

Take a look at mkimage (apt-get install uboot-mkimage on Debian and friends), this way you can look at the image:

$ mkimage -l   uImage
Image Name:   Linux-2.6.32-00114-g7ddb551
Created:      Wed Mar 31 07:46:05 2010
Image Type:   PowerPC Linux Kernel Image (gzip compressed)
Data Size:    3146319 Bytes = 3072.58 kB = 3.00 MB
Load Address: 0x00000000
Entry Point:  0x00000000

But also compress it (starting from the uncrompressed kernel)

$ sudo mkimage -C lzma   -d vmlinux  bla
Image Name:
Created:      Thu Aug  5 16:28:36 2010
Image Type:   PowerPC Linux Kernel Image (lzma compressed)
Data Size:    8363830 Bytes = 8167.80 kB = 7.98 MB
Load Address: 0x00000000
Entry Point:  0x00000000
$ mkimage -l bla
Image Name:
Created:      Thu Aug  5 16:28:36 2010
Image Type:   PowerPC Linux Kernel Image (lzma compressed)
Data Size:    8363830 Bytes = 8167.80 kB = 7.98 MB
Load Address: 0x00000000
Entry Point:  0x00000000

gr
E.

Elie De Brauwer

IIUC, mkimage only adds a header containing the information passed on the command line to the file, or prints the header contained in the file. But it doesn't compress the file, for example.

I found a few pages on the internet that described how to make uboot images, for example this one:

http://www.beattie-home.net/beattie/DSM-G600/U-Boot-README.html

Quoting from this page:

* build a standard "vmlinux" kernel image (in ELF binary format):
* convert the kernel into a raw binary image:

        ${CROSS_COMPILE}-objcopy -O binary \
                                 -R .note -R .comment \
                                 -S vmlinux linux.bin
* compress the binary image:
        gzip -9 linux.bin
* package compressed binary image for U-Boot:
        mkimage -A ppc -O linux -T kernel -C gzip \
                -a 0 -e 0 -n "Linux Kernel Image" \
                -d linux.bin.gz uImage

But that doesn't work for me.
Running 'arm-linux-objcopy -O binary ...' on the vmlinux file creates a HUGE file linux.bin (~3GB), so I suspect something is wrong.

Any idea?

Thanks,
Thomas

Dear Thomas Heller,

You can change these by changing the Make rules and/or providing appropriate options.

This not quite correct. It tells you that the payload it sees is not compressed.

That means: U-Boot does not know about any comprtession, so it does not uncompress the payload.

Here the kernel image started running...

And this is doing the uncompressions.

This is a typical (wasteful) ARM image. On ARM, the kerne image gets compressed - but instead of simply wrapping this into an uImage file, they add their own uncompress code to it, which wraps the kernel image, so what U-Boot sees is actually hte (uncompressed) wrapper code which then does the copying / uncompressing.

If you say it makes littel sense to wste space for the images and time for the loading for additional header code and uncompression routines that are already ready avaialable in U-Boot I fully agree - but the ARM kernel folks think different.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
(null cookie; hope that's ok)