[U-Boot] Getting started with uboot

[U-Boot] Getting started with uboot

[Thomas Heller]

Where does uboot store the environment variables?

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

> U-Boot 2010.06 (Aug 02 2010 - 19:53:42)
> 
> CPU:   Freescale i.MX25 at 399 MHz
> 
> DRAM:  32 MiB
> NAND:  128 MiB
> *** Warning - bad CRC or NAND, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC_MXC
> Hit any key to stop autoboot:  0
> => setenv bootcmd
> => nand read 0x80108000 0x02040000 0x00260000
> 
> NAND read: device 0 offset 0x2040000, size 0x260000
>  2490368 bytes read: OK
> =>
> 
> NAND read: device 0 offset 0x2040000, size 0x260000
>  2490368 bytes read: OK
> => bootm 0x80108000
> ## Booting kernel from Legacy Image at 80108000 ...
>    Image Name:   Linux-2.6.31
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1517328 Bytes = 1.4 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing Linux.................................................................................................... done, booting the kernel.

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

[U-Boot] Getting started with uboot

[Elie De Brauwer]

On 08/04/10 20:47, Thomas Heller wrote:
> 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?
>

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

[U-Boot] Getting started with uboot

[Wolfgang Denk]

Dear Thomas Heller,

In message <i3ccjf$a05$1@dough.gmane.org> you wrote:
> Where does uboot store the environment variables?
> 
> I have my tx25 board booting correctly from uboot when
> entering interactive commands:

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)


> > => nand read 0x80108000 0x02040000 0x00260000
> > 
> > NAND read: device 0 offset 0x2040000, size 0x260000
> >  2490368 bytes read: OK

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

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

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.

[U-Boot] Getting started with uboot

[Thomas Heller]

Wolfgang Denk schrieb:
> Dear Thomas Heller,
> 
> In message <i3ccjf$a05$1@dough.gmane.org> you wrote:
>> Where does uboot store the environment variables?
>> 
>> I have my tx25 board booting correctly from uboot when
>> entering interactive commands:
> 
> 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)
> 
> 
>> > => nand read 0x80108000 0x02040000 0x00260000
>> > 
>> > NAND read: device 0 offset 0x2040000, size 0x260000
>> >  2490368 bytes read: OK
> 
> 0x02040000 is more than 32 MiB, i. e. far, far away from the
> envrionment.

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

[U-Boot] Getting started with uboot

[Wolfgang Denk]

Dear Thomas Heller,

In message <i3chbe$ta2$1@dough.gmane.org> you wrote:
>
> 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.

Right - it needs two more flash blocks.

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

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"

[U-Boot] Getting started with uboot

[Thomas Heller]

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:

>   UIMAGE  arch/arm/boot/uImage
> Image Name:   Linux-2.6.31
> Created:      Thu Aug  5 23:59:59 2010
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:    1517292 Bytes = 1481.73 kB = 1.45 MB
> Load Address: 0x80008000
> Entry Point:  0x80008000
>   Image arch/arm/boot/uImage is ready
> theller at tubu8:~/devel/controller/starterkit/linux$

however the embedded system tells me it is uncompressing:

> => bootm 0x80108000
> ## Booting kernel from Legacy Image at 80108000 ...
>    Image Name:   Linux-2.6.31
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1517292 Bytes = 1.4 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing Linux.................................................................................................... done, booting the kernel.



-- 
Thanks,
Thomas

[U-Boot] Getting started with uboot

[Elie De Brauwer]

On 08/05/10 16:13, Thomas Heller wrote:
> 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?
>

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

[U-Boot] Getting started with uboot

[Thomas Heller]

Elie De Brauwer schrieb:
> On 08/05/10 16:13, Thomas Heller wrote:
>> 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?
>>

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

[U-Boot] Getting started with uboot

[Wolfgang Denk]

Dear Thomas Heller,

In message <i3egu9$t2h$1@dough.gmane.org> you wrote:
> 
> '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?

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

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

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

> however the embedded system tells me it is uncompressing:
> 
> > => bootm 0x80108000
> > ## Booting kernel from Legacy Image at 80108000 ...
> >    Image Name:   Linux-2.6.31
> >    Image Type:   ARM Linux Kernel Image (uncompressed)

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

> > Starting kernel ...

Here the kernel image started running...

> > Uncompressing Linux.................................................................................................... done, booting the kernel.

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)