[U-Boot] zImage on ARM

[U-Boot] zImage on ARM

[Steve Sakoman]

I have a client that has asked me to look into loading zImage files
instead of uImage for some ARM based boards.

A quick search of the code base turned up some zimage code in the i386 area.

Any words of advice or warning in doing something similar for ARM?

Anyone familiar with the history of why uImage is the preferred
format?  Just trying to learn . . .

Regards,

Steve

[U-Boot] zImage on ARM

[Paulraj, Sandeep]

> 
> I have a client that has asked me to look into loading zImage files
> instead of uImage for some ARM based boards.
> 
> A quick search of the code base turned up some zimage code in the i386
> area.
> 
> Any words of advice or warning in doing something similar for ARM?
> 
> Anyone familiar with the history of why uImage is the preferred
> format?  Just trying to learn . . .
> 
> Regards,
> 
> Steve

Honestly I do not know about pitfalls but using I have used zImage will doing board bring ups of new SOCs. It is easy to load a zImage from a IDE like CCS in TI's case. 

When we get the first EVMs even the bootloaders are not up and running so zImage along with CCS comes in very handy. You can directly load into DDR and boot up the kernel.

Sandeep

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Steve Sakoman,

In message <AANLkTi=VbVrSfP1rLGGsEGuWH9kwVy_3TzU_QRQRVD87@mail.gmail.com> you wrote:
> I have a client that has asked me to look into loading zImage files
> instead of uImage for some ARM based boards.

Why?

> Any words of advice or warning in doing something similar for ARM?

No. IMO it makes little sense.

> Anyone familiar with the history of why uImage is the preferred
> format?  Just trying to learn . . .

uImage, when done correctly, avoids that you have to add a pre-loader
(including all of gzip and what else is needed to copy the uncom-
pressed image to it's final location in RAM) to each and every kernel
image - which is just a waste of time and resources as we already
have all that code present in U-Boot.

Note that the mainline ARM kernel does not make use of this; instead,
it adds the preloader anyway.  I never understood why.

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
You are only young once, but you can stay immature indefinitely.

[U-Boot] zImage on ARM

[Loïc Minier]

On Fri, Sep 03, 2010, Wolfgang Denk wrote:
> > I have a client that has asked me to look into loading zImage files
> > instead of uImage for some ARM based boards.
> 
> Why?

 It's the direct output of the kernel build process; typically,
 distributions ship a /boot/zImage-foo which gets converted into an
 uImage and flashed if the bootloader is u-boot.  If that step could be
 skipped, it would make things easier!

> > Anyone familiar with the history of why uImage is the preferred
> > format?  Just trying to learn . . .
> 
> uImage, when done correctly, avoids that you have to add a pre-loader
> (including all of gzip and what else is needed to copy the uncom-
> pressed image to it's final location in RAM) to each and every kernel
> image - which is just a waste of time and resources as we already
> have all that code present in U-Boot.
> 
> Note that the mainline ARM kernel does not make use of this; instead,
> it adds the preloader anyway.  I never understood why.

 Seems zImage is quite widespread now; would it make sense to allow
 builing u-boot without that code and rely on the kernel code to unpack?
 Or should u-boot just gain a new image type for zImage?

-- 
Lo?c Minier

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message <20100903214753.GA8552@bee.dooz.org> you wrote:
> On Fri, Sep 03, 2010, Wolfgang Denk wrote:
> > > I have a client that has asked me to look into loading zImage files
> > > instead of uImage for some ARM based boards.
> > >
> > Why?
>
>  It's the direct output of the kernel build process; typically,
>  distributions ship a /boot/zImage-foo which gets converted into an
>  uImage and flashed if the bootloader is u-boot.  If that step could be
>  skipped, it would make things easier!

zImage does not contain any visible information about what it is,
when it was build, etc. It is not checksum protected so you cannot
verify if the image you just downloaded is good enough to erase what
you have in flash, etc. etc.

> > Note that the mainline ARM kernel does not make use of this; instead,
> > it adds the preloader anyway.  I never understood why.
>
>  Seems zImage is quite widespread now; would it make sense to allow
>  builing u-boot without that code and rely on the kernel code to unpack?

Why duplicating the stuff again and again and again?

>  Or should u-boot just gain a new image type for zImage?

Why not use uImage like we do with other architectures? 

Why is it that ARM always has to try to reinvent the wheels?

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
There is a multi-legged creature crawling on your shoulder.
	-- Spock, "A Taste of Armageddon", stardate 3193.9

[U-Boot] zImage on ARM

[Scott Wood]

On Wed, 8 Sep 2010 01:04:39 +0200
Wolfgang Denk <wd@denx.de> wrote:

> >  Or should u-boot just gain a new image type for zImage?
> 
> Why not use uImage like we do with other architectures? 

Whereas they'd say why can't U-Boot accept a simple binary, and just
run it in place without copying, like any other loader can?

Sure, uImage has some advantages, but why force the matter?

> Why is it that ARM always has to try to reinvent the wheels?

I believe the zImage wheel was invented before the uImage wheel. :-)

-Scott

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Scott Wood,

In message <20100908152335.6d280806@schlenkerla.am.freescale.net> you wrote:
>
> > Why not use uImage like we do with other architectures? 
> 
> Whereas they'd say why can't U-Boot accept a simple binary, and just
> run it in place without copying, like any other loader can?

U-Boot can do that. Use the "go" command.

> Sure, uImage has some advantages, but why force the matter?

We don't force it. uImage is used because of the advantages, but
if you feel like it you can always use "go". Just don't complain that
you then lose some nice features ;-)

> > Why is it that ARM always has to try to reinvent the wheels?
> 
> I believe the zImage wheel was invented before the uImage wheel. :-)

Yes, and it was found to have a number of deficiencies when used in
embedded systems.

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
Certainly there are things in life that money  can't  buy,  but  it's
very funny - Did you ever try buying them without money? - Ogden Nash

[U-Boot] zImage on ARM

[Scott Wood]

On Wed, 8 Sep 2010 22:32:56 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20100908152335.6d280806@schlenkerla.am.freescale.net> you wrote:
> >
> > > Why not use uImage like we do with other architectures? 
> > 
> > Whereas they'd say why can't U-Boot accept a simple binary, and just
> > run it in place without copying, like any other loader can?
> 
> U-Boot can do that. Use the "go" command.

Will things like the device tree get passed just as if the bootm
command were used?

-Scott

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Scott Wood,

In message <20100908153455.527fcd70@schlenkerla.am.freescale.net> you wrote:
>
> > > > Why not use uImage like we do with other architectures? 
> > > 
> > > Whereas they'd say why can't U-Boot accept a simple binary, and just
> > > run it in place without copying, like any other loader can?
> > 
> > U-Boot can do that. Use the "go" command.
> 
> Will things like the device tree get passed just as if the bootm
> command were used?

No, of course not.  You asked about starting "a simple binary".

I warned you that you might lose some nice features...


But then - which other popular ARM boot loader supports passing a
device tree?  Or which other popular embedded boot loader?

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
All I ask is a chance to prove that money can't make me happy.

[U-Boot] zImage on ARM

[Scott Wood]

On Wed, 8 Sep 2010 22:43:48 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20100908153455.527fcd70@schlenkerla.am.freescale.net> you wrote:
> >
> > > > > Why not use uImage like we do with other architectures? 
> > > > 
> > > > Whereas they'd say why can't U-Boot accept a simple binary, and just
> > > > run it in place without copying, like any other loader can?
> > > 
> > > U-Boot can do that. Use the "go" command.
> > 
> > Will things like the device tree get passed just as if the bootm
> > command were used?
> 
> No, of course not.  You asked about starting "a simple binary".
> 
> I warned you that you might lose some nice features...

What does passing a device tree have to do with the image format?

It seems like it should be an orthogonal issue.  At most it would
require the user to specify an argument to the go command, that
provides information (calling convention) that with uImage would have
been guessed from the OS type.  Though OSes can share a calling
convention, and OSes can change conventions... a Linux uImage that wants
a bd_t has the same OS type as one that wants a device tree.  Our
hypervisor lies and claims to be Linux so as to not require special
U-Boot support.

> But then - which other popular ARM boot loader supports passing a
> device tree?  Or which other popular embedded boot loader?

It's not a matter of whether it's a device tree versus something else,
but whether it is whatever Linux normally expects a loader to pass
(e.g. ATAGs).

It looks like the go command only supports passing argc/argv, so
U-Boot cannot boot a zImage with the go command.

-Scott

[U-Boot] zImage on ARM

[Loïc Minier]

On Wed, Sep 08, 2010, Wolfgang Denk wrote:
> zImage does not contain any visible information about what it is,
> when it was build, etc. It is not checksum protected so you cannot
> verify if the image you just downloaded is good enough to erase what
> you have in flash, etc. etc.

 These are indeed nice features of uImages (checksums +
 build date information); but they are not needed in all use cases for
 U-Boot.  Distributions are shipping zImage for ARM nowadays and when
 shipping zImage files withing packages (.deb for instance), there are
 already checksums, file timestamps, public build logs etc. as part of
 the distro toolkit.
   Also, this means end-user systems need mkimage installed (because
 uImage differ slightly across boards).  Not a problem for an embedded
 developer obviously, but would prefer avoiding this need on an end-user
 system.

 (Nitpick: if you want an accurate time for the kernel build, them this
 should rather be recorded during the upstream linux kernel build rather
 than at the time the uImage is created, which could be quite some time
 later!)

> >  Seems zImage is quite widespread now; would it make sense to allow
> >  builing u-boot without that code and rely on the kernel code to unpack?
> Why duplicating the stuff again and again and again?

 Well, I'm proposing skipping one copy   ;-)   the U-Boot one

> >  Or should u-boot just gain a new image type for zImage?
> Why not use uImage like we do with other architectures? 
> Why is it that ARM always has to try to reinvent the wheels?

 Eh, zImage has been around for a while!

 I guess it's just that we don't /need/ the couple extra uImage
 features, and would rather ship zImage directly.

 It would also remove the need for maintaining the table of magic values
 for uImage / uInitrd generation; a problem I described recently on
 another list:
 http://lists.linaro.org/pipermail/linaro-dev/2010-August/000493.html

 So we'd be happy if you'd take patches to have U-Boot accept this
 "dumber" format.

   Cheers,
-- 
Lo?c Minier

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Scott Wood,

In message <20100908160001.374ff382@schlenkerla.am.freescale.net> you wrote:
>
> > In message <20100908153455.527fcd70@schlenkerla.am.freescale.net> you wrote:
> > >
> > > > > > Why not use uImage like we do with other architectures? 
> > > > > 
> > > > > Whereas they'd say why can't U-Boot accept a simple binary, and just
> > > > > run it in place without copying, like any other loader can?
> > > > 
> > > > U-Boot can do that. Use the "go" command.
> > > 
> > > Will things like the device tree get passed just as if the bootm
> > > command were used?
> > 
> > No, of course not.  You asked about starting "a simple binary".
> > 
> > I warned you that you might lose some nice features...
> 
> What does passing a device tree have to do with the image format?

Nothing.

I don't really understand what you want.

Your question was if U-Boot could "accept a simple binary, and just
run it in place without copying, like any other loader can".

I told you: Yes, we can.

Now you come up asking for fancy features like passing device tree
information (and probably boot arguments as well? and ATAGs in case of
an ARM kernel? and ... ?) which goes way beyond the "just run it in
place", and also way beyond what "any other loader can".

Yes, U-Boot supports all this stuff. It is supported in the context of
U-Boot images, usign FIT images as the recommended format, and still
supporting the old legacy image format.


> It seems like it should be an orthogonal issue.  At most it would
> require the user to specify an argument to the go command, that

The go command takes arguments, which get passed to the started
application in the standard C calling convention. It is up to the
image to interpret these, then.

Note that you left the "simple binary ... like any other loader can"
track.


> > But then - which other popular ARM boot loader supports passing a
> > device tree?  Or which other popular embedded boot loader?
> 
> It's not a matter of whether it's a device tree versus something else,
> but whether it is whatever Linux normally expects a loader to pass
> (e.g. ATAGs).

For a "simple binary" that we "just run in place"?


> It looks like the go command only supports passing argc/argv, so
> U-Boot cannot boot a zImage with the go command.

If zImage needs such additional information, then it's probably not a
"simple binary".

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
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message <20100908232753.GA20336@bee.dooz.org> you wrote:
>
>  These are indeed nice features of uImages (checksums +
>  build date information); but they are not needed in all use cases for
>  U-Boot.  Distributions are shipping zImage for ARM nowadays and when
>  shipping zImage files withing packages (.deb for instance), there are
>  already checksums, file timestamps, public build logs etc. as part of
>  the distro toolkit.

Hm... the checksum of the distributyed poackage gives you zero help
when it comes to check the image after a download to the target.

Keep in mind that the uImage format was invented to address typical
problems of embedded systems:

You have a device with some data in flash. You don't know what
happened to the device. Now quickly check:
  - Is it a kernel? Is it a file system?
  - Has the image been corrupted / partially overwritten?
  - Which version / production ID / production time is this image
    from?
 

Please also note that what most people refer to when talking about
"uImage" files (data payload with prepended 64 byte header) is
considered to be the old, obsolete legacy image format. The officially
recommended image format for U-Boot is FIT images, which allow for
very powerful extensions; see doc/uImage.FIT/

>    Also, this means end-user systems need mkimage installed (because
>  uImage differ slightly across boards).  Not a problem for an embedded
>  developer obviously, but would prefer avoiding this need on an end-user
>  system.

I don't see why uImages differ across boards - if the same kernel
image can be used (i. e. the same zImage file use to generate the
uImages) on these boards?

>  (Nitpick: if you want an accurate time for the kernel build, them this
>  should rather be recorded during the upstream linux kernel build rather
>  than at the time the uImage is created, which could be quite some time
>  later!)

This is not a bug, but a feature. We don't want the time of the
kernel build, because the kernel is often just one component in an
image file, which may contain more than one kernel image, plus one or
more device tree blobs, plus one or more file system images, etc.

It is intentional to use the timestamp when the image was created.

> > >  Seems zImage is quite widespread now; would it make sense to allow
> > >  builing u-boot without that code and rely on the kernel code to unpack?
> > Why duplicating the stuff again and again and again?
> 
>  Well, I'm proposing skipping one copy   ;-)   the U-Boot one

U-Boot does not perform any additional copies on the target, if the
image was build correctly and in a sane way.

> > >  Or should u-boot just gain a new image type for zImage?
> > Why not use uImage like we do with other architectures? 
> > Why is it that ARM always has to try to reinvent the wheels?
> 
>  Eh, zImage has been around for a while!

Indeed. But has been around a decade as well.

>  I guess it's just that we don't /need/ the couple extra uImage
>  features, and would rather ship zImage directly.

You still need some information on the target when it comes to booting
the image - at least you need to know the entry point address (or it's
offset into the image).

>  It would also remove the need for maintaining the table of magic values
>  for uImage / uInitrd generation; a problem I described recently on
>  another list:
>  http://lists.linaro.org/pipermail/linaro-dev/2010-August/000493.html

In that message you write:

| So what kind of operations do we want to be able to do?
| 
|  * generate an u-boot kernel image from a zImage
|    - input: zImage, kernel load address
|    - output: uImage

Actually you need load address and entry point address.

If you can come up with position independent payload, you still need
the entry point (then probably in terms of offset relative to the
current image address).

Patches to implement this (in the context of FIT images) are welcome.

|  * generate an u-boot initrd image from an initrd.gz
|    - input: initrd.gz, initrd load address
|    - output: uInitrd

This makes no sense to me. Ramdisk images don't need to be loaded
anywhere.  I consider it a bug in the ARM Linux kernel that you have
to load a compressed initrd image to RAM first, then uncompress it,
then use it. In other architectures (say PPC) we can pass the address
of the image in flash memory to the kernel, which saves one copy
operation.

Patches to support this for ARM as well have been submitted - and
rejected.

You talk about making code more efficient and saving unnecessary copy
operations - I recommend to fix this in Linux.

For PowerPC, initrd images have load address and entry point address
set to dummy values (0), which are not used anywhere in U-Boot.

>  So we'd be happy if you'd take patches to have U-Boot accept this
>  "dumber" format.

You may be aware that the implementation of the "bootm" command has
been split into small building blocks some time ago. The idea was to
allow for easy customizing, eventually even on command line level.
You should be able to craft a custom boot command this way, which
omits the header check.

But I don't think that this solves your problem - you still need
information at least about the entry point address, which then has to
be stored separate from the image file, which just shifts the problem
to another area.

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
I mean, I . . . think to understand you, I just don't know  what  you
are saying ...                        - Terry Pratchett, _Soul Music_

[U-Boot] zImage on ARM

[Lei Wen]

Hi,

On Thu, Sep 9, 2010 at 4:43 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott Wood,
>
> In message <20100908153455.527fcd70@schlenkerla.am.freescale.net> you wrote:
>>
>> > > > Why not use uImage like we do with other architectures?
>> > >
>> > > Whereas they'd say why can't U-Boot accept a simple binary, and just
>> > > run it in place without copying, like any other loader can?
>> >
>> > U-Boot can do that. Use the "go" command.
>>
>> Will things like the device tree get passed just as if the bootm
>> command were used?
>
> No, of course not. ?You asked about starting "a simple binary".
>
> I warned you that you might lose some nice features...
>
>
> But then - which other popular ARM boot loader supports passing a
> device tree? ?Or which other popular embedded boot loader?
>

Don't forget Linux kernel itself could be a bootloader. :-)
Kexec would be a perfect one, if its size could be get smaller like uboot does.

Best regards,
Lei

[U-Boot] zImage on ARM

[Scott Wood]

On Thu, 9 Sep 2010 09:26:39 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20100908160001.374ff382@schlenkerla.am.freescale.net> you wrote:
> >
> > > In message <20100908153455.527fcd70@schlenkerla.am.freescale.net> you wrote:
> > > >
> > > > > > > Why not use uImage like we do with other architectures? 
> > > > > > 
> > > > > > Whereas they'd say why can't U-Boot accept a simple binary, and just
> > > > > > run it in place without copying, like any other loader can?
> > > > > 
> > > > > U-Boot can do that. Use the "go" command.
> > > > 
> > > > Will things like the device tree get passed just as if the bootm
> > > > command were used?
> > > 
> > > No, of course not.  You asked about starting "a simple binary".
> > > 
> > > I warned you that you might lose some nice features...
> > 
> > What does passing a device tree have to do with the image format?
> 
> Nothing.

Then why does u-boot only support certain calling conventions with
certain image formats?

> Now you come up asking for fancy features like passing device tree
> information (and probably boot arguments as well? and ATAGs in case of
> an ARM kernel? and ... ?) which goes way beyond the "just run it in
> place", and also way beyond what "any other loader can".

Are you really claiming that booting a Linux zImage is "way beyond what
any other loader can" do?  I'm pretty sure I've seen that happen on
RedBoot, PlanetCore, and probably half a dozen others that I've
forgotten.

> Yes, U-Boot supports all this stuff. It is supported in the context of
> U-Boot images, usign FIT images as the recommended format, and still
> supporting the old legacy image format.

So in other words, for booting an OS, U-Boot insists on particular
image formats.

> > It seems like it should be an orthogonal issue.  At most it would
> > require the user to specify an argument to the go command, that
> 
> The go command takes arguments, which get passed to the started
> application in the standard C calling convention. It is up to the
> image to interpret these, then.

It passes *text* arguments supplied by the command line, in argc/argv
format.  Which seems like it's not intended to be an arbitrary image
loading command, but rather a facility to execute things that look and
feel like shell commands.

> > > But then - which other popular ARM boot loader supports passing a
> > > device tree?  Or which other popular embedded boot loader?
> > 
> > It's not a matter of whether it's a device tree versus something else,
> > but whether it is whatever Linux normally expects a loader to pass
> > (e.g. ATAGs).
> 
> For a "simple binary" that we "just run in place"?

Yes.  "simple" refers to the image format, not the calling convention.

-Scott

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Scott Wood,

In message <20100909112816.7bd37645@schlenkerla.am.freescale.net> you wrote:
>
> Then why does u-boot only support certain calling conventions with
> certain image formats?

The "bootm" command supports only images it understands.

> So in other words, for booting an OS, U-Boot insists on particular
> image formats.

No, it does not. You can provide the OS in a  U-Boot specific
standard way (FIT or legacy image format), you can provide it in a
system independent format (ELF), or you can provide it in a "simple
binary" format (to be used with "go").

> > The go command takes arguments, which get passed to the started
> > application in the standard C calling convention. It is up to the
> > image to interpret these, then.
> 
> It passes *text* arguments supplied by the command line, in argc/argv
> format.  Which seems like it's not intended to be an arbitrary image
> loading command, but rather a facility to execute things that look and
> feel like shell commands.

It's the standard C calling convention, i. e. pretty common standard.

> Yes.  "simple" refers to the image format, not the calling convention.

As I explained before: feel free to craft your own specific boot
command from the building blocks provided.

There is a standard way of doing this; if you don't want to use it
it's fine with me. Define a "bootz" command or whatever you like.

Don't expect me to scratch your itches, though. In all the past 10
years when I've been working with PPCBoot and U-Boot I never felt the
need to boot a zImage.

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
Due to lack of disk space, this fortune database has been discontinued.

[U-Boot] zImage on ARM

[Loïc Minier]

On Thu, Sep 09, 2010, Wolfgang Denk wrote:
> >  These are indeed nice features of uImages (checksums +
> >  build date information); but they are not needed in all use cases for
> >  U-Boot.  Distributions are shipping zImage for ARM nowadays and when
> >  shipping zImage files withing packages (.deb for instance), there are
> >  already checksums, file timestamps, public build logs etc. as part of
> >  the distro toolkit.
> 
> Hm... the checksum of the distributyed poackage gives you zero help
> when it comes to check the image after a download to the target.

 Note that packages are downloaded directly *on* the target; that is,
 the target is running e.g. Debian or Ubuntu, one gets a kernel upgrade
 in the form of a .deb which is checksummed, installed and its contents
 get written to flash.

> Keep in mind that the uImage format was invented to address typical
> problems of embedded systems:
> 
> You have a device with some data in flash. You don't know what
> happened to the device. Now quickly check:
>   - Is it a kernel? Is it a file system?
>   - Has the image been corrupted / partially overwritten?
>   - Which version / production ID / production time is this image
>     from?

 Yup; I can see how all of these make sense and are useful in the
 context of embedded systems; I think we're looking at a different use
 case for mainstream linux distributions here where processes and tools
 already deal with the above.

> >    Also, this means end-user systems need mkimage installed (because
> >  uImage differ slightly across boards).  Not a problem for an embedded
> >  developer obviously, but would prefer avoiding this need on an end-user
> >  system.
> 
> I don't see why uImages differ across boards - if the same kernel
> image can be used (i. e. the same zImage file use to generate the
> uImages) on these boards?

 Well, it was my understanding that different boards need different load
 addresses and/or different entry points; currently, for the same ARM
 SoC, it's mostly the same address.  But when you start building a
 single zImage targetting multiple SoCs, it might not be the case
 anymore.  (https://wiki.ubuntu.com/Specs/ARMSingleKernel)

[...]
> For PowerPC, initrd images have load address and entry point address
> set to dummy values (0), which are not used anywhere in U-Boot.

 We could of course ignore the data in the uImage, and write 0x0 as you
 suggest: that's why we don't need this data in the uImage in the first
 place in our use case.

> If you can come up with position independent payload, you still need
> the entry point (then probably in terms of offset relative to the
> current image address).

 Yes; but even with a position independent kernel, we need to know where
 in memory it should preferably be loaded (even if almost anywhere would
 work, there's a limited range or physical memory).

> Patches to implement this (in the context of FIT images) are welcome.

 To make sure I got that right: you propose extending the uImage.FIT
 format to allow for a relative entry address instead of absolute load
 address + absolute entry point, correct?  That sounds like something
 useful indeed.

 My understanding of the ARM zImage uncompress code is that the entry
 point would basically be at offset zero once loaded in memory, for all
 targets/boards.

> This makes no sense to me. Ramdisk images don't need to be loaded
> anywhere.  I consider it a bug in the ARM Linux kernel that you have
> to load a compressed initrd image to RAM first, then uncompress it,
> then use it. In other architectures (say PPC) we can pass the address
> of the image in flash memory to the kernel, which saves one copy
> operation.

 I don't know enough about the ARM kernel's ramdisk code to comment on
 whether or not it could be uncompressed directly from flash into RAM;
 the way these are usually handled in Debian/Ubuntu so far is that the
 bootloader has a load command for the ramdisk from persistent storage
 to RAM (either NAND or MMC), then a load command for the kernel from
 persistent storage to RAM (either NAND or MMC), then calls the kernel
 entry point with the ramdisk address as an ATAG.  You could argue that
 we could also run zImage directly from flash, and let it unpack itself
 into RAM.  I suspect the reason it's not commonly done is because it's
 very specialized to flash and doesn't apply to e.g. MMC, but I don't
 really know for sure.

> Patches to support this for ARM as well have been submitted - and
> rejected.

 Hmm ok; do you have some pointers/rationale?  It's interesting to
 gather past ideas and counter-arguments to try to improve the ARM boot
 architecture.

> >  So we'd be happy if you'd take patches to have U-Boot accept this
> >  "dumber" format.
> You may be aware that the implementation of the "bootm" command has
> been split into small building blocks some time ago. The idea was to
> allow for easy customizing, eventually even on command line level.
> You should be able to craft a custom boot command this way, which
> omits the header check.

 Ok; I wonder if we could just have an IMAGE_FORMAT_ZIMAGE and
 CONFIG_ZIMAGE instead?

> But I don't think that this solves your problem - you still need
> information at least about the entry point address, which then has to
> be stored separate from the image file, which just shifts the problem
> to another area.

 Isn't it always at offset 0 for an ARM zImage payload?

 The main thing I'd like the bootloader to keep track of is the physical
 load address at which to load the kernel; usually this is 0x8000 when
 possible.  I am not sure it needs to track anything else.

-- 
Lo?c Minier

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message <20100912150749.GB23760@bee.dooz.org> you wrote:
>
>  Note that packages are downloaded directly *on* the target; that is,
>  the target is running e.g. Debian or Ubuntu, one gets a kernel upgrade
>  in the form of a .deb which is checksummed, installed and its contents
>  get written to flash.

This may be the cas eon some systems - others (and I guess these are
the majority of systems) use other means, like DHCP or TFTP or loading
from USM Mass storage device or from MMC/SDCard etc.

>  Yup; I can see how all of these make sense and are useful in the
>  context of embedded systems; I think we're looking at a different use
>  case for mainstream linux distributions here where processes and tools
>  already deal with the above.

They may do for the production, distribution and maybe even installa-
tion part. When it comes to development or maintenance/repair we have
a different situation. We're not only focussed on installation, but
try to meet the requirements for the whole product cycle.

> > I don't see why uImages differ across boards - if the same kernel
> > image can be used (i. e. the same zImage file use to generate the
> > uImages) on these boards?
> 
>  Well, it was my understanding that different boards need different load
>  addresses and/or different entry points; currently, for the same ARM
>  SoC, it's mostly the same address.  But when you start building a
>  single zImage targetting multiple SoCs, it might not be the case
>  anymore.  (https://wiki.ubuntu.com/Specs/ARMSingleKernel)

Maybe this should/could be addressed on the Linux side then? We don't
have such problems on PwerPC, for example.

> > If you can come up with position independent payload, you still need
> > the entry point (then probably in terms of offset relative to the
> > current image address).
> 
>  Yes; but even with a position independent kernel, we need to know where
>  in memory it should preferably be loaded (even if almost anywhere would
>  work, there's a limited range or physical memory).

So you agree that in addition to the kexpnrel image we need information
about the entry point and the load address. Um, well, that's exactly
what uImage requires.  If this information is indeed needed, then
what's the problem of creating an uImage?


> > Patches to implement this (in the context of FIT images) are welcome.
> 
>  To make sure I got that right: you propose extending the uImage.FIT
>  format to allow for a relative entry address instead of absolute load
>  address + absolute entry point, correct?  That sounds like something
>  useful indeed.

Well, I would not oppose such an extension if it's indeed usefult -
which I doubt. If you give an absolute load address anyway, then there
is basicly no difference between a relative or an absolute entry point
address.

>  My understanding of the ARM zImage uncompress code is that the entry
>  point would basically be at offset zero once loaded in memory, for all
>  targets/boards.

Can we not omit that code, and use the one we already have in U-Boot?
Why increasing the Linux kernel image size (and thus flash footprint,
load time, etc.) without need?

>  I don't know enough about the ARM kernel's ramdisk code to comment on
>  whether or not it could be uncompressed directly from flash into RAM;

It can. We've been doing this for many years. Just never managed to
get the patches accepted for mainline.

>  the way these are usually handled in Debian/Ubuntu so far is that the
>  bootloader has a load command for the ramdisk from persistent storage
>  to RAM (either NAND or MMC), then a load command for the kernel from
>  persistent storage to RAM (either NAND or MMC), then calls the kernel
>  entry point with the ramdisk address as an ATAG.  You could argue that
>  we could also run zImage directly from flash, and let it unpack itself
>  into RAM.  I suspect the reason it's not commonly done is because it's
>  very specialized to flash and doesn't apply to e.g. MMC, but I don't
>  really know for sure.

The reason we don't do that is that we use a bare Linux image, using
U-Boot and it's uncompression code to load it from persistent storage
to RAM and uncompress it on the fly.  This avoids a copy operation and
should be faster in almost all cases.

>  Hmm ok; do you have some pointers/rationale?  It's interesting to
>  gather past ideas and counter-arguments to try to improve the ARM boot
>  architecture.

The most recent attempt can be seen here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53969

As before, RMK smashed this with his "I don't see any reason for this."

> > You may be aware that the implementation of the "bootm" command has
> > been split into small building blocks some time ago. The idea was to
> > allow for easy customizing, eventually even on command line level.
> > You should be able to craft a custom boot command this way, which
> > omits the header check.
> 
>  Ok; I wonder if we could just have an IMAGE_FORMAT_ZIMAGE and
>  CONFIG_ZIMAGE instead?

You need a command to boot his image. "bootm" cannot be used as it
tries to verify integrity of the images you pass to it, and extracts
information about load address and entry point from it, too.

You need a command that does not do this, but eventually receives
these parameters from somewhere else (command line?), but still passes
all required information like ATAGs and/or device tree, kernel command
line etc. to the image.  You might consider extending the bootelf
command and relying on information passed in the ELF header (if you
don't care to waste another 64 kB flash memory footprint for the
image, IIRC).

> > But I don't think that this solves your problem - you still need
> > information at least about the entry point address, which then has to
> > be stored separate from the image file, which just shifts the problem
> > to another area.
> 
>  Isn't it always at offset 0 for an ARM zImage payload?

I don't know. 

>  The main thing I'd like the bootloader to keep track of is the physical
>  load address at which to load the kernel; usually this is 0x8000 when
>  possible.  I am not sure it needs to track anything else.

On most ARM systems 0x8000 is in the ROM address space; I wonder if
you talk about an address offset relative to the begin of system RAM
rather than an absolute physical address?

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
"Just think, with VLSI we can have 100 ENIACS on a chip!"
- Alan Perlis

[U-Boot] zImage on ARM

[Nicolas Pitre]

On Sun, 12 Sep 2010, Wolfgang Denk wrote:

> In message <20100912150749.GB23760@bee.dooz.org> you wrote:
> > > I don't see why uImages differ across boards - if the same kernel
> > > image can be used (i. e. the same zImage file use to generate the
> > > uImages) on these boards?
> > 
> >  Well, it was my understanding that different boards need different load
> >  addresses and/or different entry points; currently, for the same ARM
> >  SoC, it's mostly the same address.  But when you start building a
> >  single zImage targetting multiple SoCs, it might not be the case
> >  anymore.  (https://wiki.ubuntu.com/Specs/ARMSingleKernel)
> 
> Maybe this should/could be addressed on the Linux side then? We don't
> have such problems on PwerPC, for example.

On the Linux side, we currently have a fully position independent 
zImage.  So you already can load it anywhere in RAM and branch to it 
with an offset of 0 from where it is loaded.

> > > If you can come up with position independent payload, you still need
> > > the entry point (then probably in terms of offset relative to the
> > > current image address).

The entry point for an ARM kernel image is always at an offset of 0.

> >  Yes; but even with a position independent kernel, we need to know where
> >  in memory it should preferably be loaded (even if almost anywhere would
> >  work, there's a limited range or physical memory).
> 
> So you agree that in addition to the kexpnrel image we need information
> about the entry point and the load address. Um, well, that's exactly
> what uImage requires.  If this information is indeed needed, then
> what's the problem of creating an uImage?

We are working on the ability for a single kernel binary image to work 
on different SOCs.  However, on one SOC, the RAM is physically located 
at 0xc0000000, on another that might be 0x02000000, on another it is 
0x00000000, etc.  While zImage could be loaded at any of those addresses 
and executed there, in the uImage case the load address has to be 
provided at mkimage time.  That makes the distribution of a single 
uImage impossible for varied targets while distributing the 
corresponding zImage would just work.

> > > Patches to implement this (in the context of FIT images) are welcome.
> > 
> >  To make sure I got that right: you propose extending the uImage.FIT
> >  format to allow for a relative entry address instead of absolute load
> >  address + absolute entry point, correct?  That sounds like something
> >  useful indeed.
> 
> Well, I would not oppose such an extension if it's indeed usefult -
> which I doubt. If you give an absolute load address anyway, then there
> is basicly no difference between a relative or an absolute entry point
> address.

We need to be able to provide the load address at _load_ time instead of 
at _mkimage_ time.  In all cases, the entry point for the ARM kernel is 
always at offset 0 from the load address as mentioned above.

> >  My understanding of the ARM zImage uncompress code is that the entry
> >  point would basically be at offset zero once loaded in memory, for all
> >  targets/boards.
> 
> Can we not omit that code, and use the one we already have in U-Boot?
> Why increasing the Linux kernel image size (and thus flash footprint,
> load time, etc.) without need?

Sorry, I'm not following you here.

> >  I don't know enough about the ARM kernel's ramdisk code to comment on
> >  whether or not it could be uncompressed directly from flash into RAM;
> 
> It can. We've been doing this for many years. Just never managed to
> get the patches accepted for mainline.

And even better: rather than decompressing a ramdisk from flash, this is 
even more efficient to set an MTD partition for it and use the ramdisk 
content directly from flash as needed through the mtdblock device and 
not pin down memory for it needlessly.

Yet, the point of a ramdisk is to let the kernel decide at run time what 
driver it really needs to mount its root fs, and load the appropriate 
module just like desktop Linux is doing.  And that's what we're looking 
for here: equivalent of a desktop Linux on ARM.

> >  the way these are usually handled in Debian/Ubuntu so far is that the
> >  bootloader has a load command for the ramdisk from persistent storage
> >  to RAM (either NAND or MMC), then a load command for the kernel from
> >  persistent storage to RAM (either NAND or MMC), then calls the kernel
> >  entry point with the ramdisk address as an ATAG.  You could argue that
> >  we could also run zImage directly from flash, and let it unpack itself
> >  into RAM.  I suspect the reason it's not commonly done is because it's
> >  very specialized to flash and doesn't apply to e.g. MMC, but I don't
> >  really know for sure.

That's correct.  Decompressing a zImage directly from flash is good for 
specific embedded applications where boot time is critical.

> The reason we don't do that is that we use a bare Linux image, using
> U-Boot and it's uncompression code to load it from persistent storage
> to RAM and uncompress it on the fly.  This avoids a copy operation and
> should be faster in almost all cases.

... except in those specific cases for which the zImage in ROM was 
created.  But that's not a case that's interesting for us here anyway.

> >  Hmm ok; do you have some pointers/rationale?  It's interesting to
> >  gather past ideas and counter-arguments to try to improve the ARM boot
> >  architecture.
> 
> The most recent attempt can be seen here:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53969
> 
> As before, RMK smashed this with his "I don't see any reason for this."

And I agree with him.  You don't need it because you may achieve better 
system resource usage by mapping an MTD block device onto a squashfs 
image instead.  And that would work for either NOR or NAND flash which 
is not the case for the patch referenced above.

> > > You may be aware that the implementation of the "bootm" command has
> > > been split into small building blocks some time ago. The idea was to
> > > allow for easy customizing, eventually even on command line level.
> > > You should be able to craft a custom boot command this way, which
> > > omits the header check.
> > 
> >  Ok; I wonder if we could just have an IMAGE_FORMAT_ZIMAGE and
> >  CONFIG_ZIMAGE instead?
> 
> You need a command to boot his image. "bootm" cannot be used as it
> tries to verify integrity of the images you pass to it, and extracts
> information about load address and entry point from it, too.
> 
> You need a command that does not do this, but eventually receives
> these parameters from somewhere else (command line?), but still passes
> all required information like ATAGs and/or device tree, kernel command
> line etc. to the image.

Exact!

> You might consider extending the bootelf
> command and relying on information passed in the ELF header (if you
> don't care to waste another 64 kB flash memory footprint for the
> image, IIRC).

We don't have an ELF image.  We want to have the option of booting a 
zImage.

> > > But I don't think that this solves your problem - you still need
> > > information at least about the entry point address, which then has to
> > > be stored separate from the image file, which just shifts the problem
> > > to another area.
> > 
> >  Isn't it always at offset 0 for an ARM zImage payload?
> 
> I don't know. 

Yes it is.

> >  The main thing I'd like the bootloader to keep track of is the physical
> >  load address at which to load the kernel; usually this is 0x8000 when
> >  possible.  I am not sure it needs to track anything else.
> 
> On most ARM systems 0x8000 is in the ROM address space; I wonder if
> you talk about an address offset relative to the begin of system RAM
> rather than an absolute physical address?

On many ARM systems the ROM is not at 0.  In those cases the hardware 
makes a part of the ROM visible at 0xffff0000 where the high reset 
vector is.

But regardless of that detail, it would be a good thing to have if we 
could script something like:

	load zImage 0x00008000
	bootz 0x00008000

The first command would load a zImage from wherever and put it at 
0x00008000 in RAM.  I think this can already be achieved with the 
standard U-Boot load command.

The second command would prepare the ATAGs as usual and boot the kernel 
known to be at 0x00008000.


Nicolas

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Nicolas,

In message <alpine.LFD.2.00.1009122338310.19366@xanadu.home> you wrote:
> 
> > Maybe this should/could be addressed on the Linux side then? We don't
> > have such problems on PwerPC, for example.
> 
> On the Linux side, we currently have a fully position independent 
> zImage.  So you already can load it anywhere in RAM and branch to it 
> with an offset of 0 from where it is loaded.

It has to be started in RAM, i. e. we cannmot run it from a ROM
location?

> > > > If you can come up with position independent payload, you still need
> > > > the entry point (then probably in terms of offset relative to the
> > > > current image address).
> 
> The entry point for an ARM kernel image is always at an offset of 0.

Fine.

So your problem could be solved if we were able to specify a relative
load address (relative to the start of system RAM), and relative
entry point address (offset into image) ?


> We are working on the ability for a single kernel binary image to work 
> on different SOCs.  However, on one SOC, the RAM is physically located 
> at 0xc0000000, on another that might be 0x02000000, on another it is 
> 0x00000000, etc.  While zImage could be loaded at any of those addresses 
> and executed there, in the uImage case the load address has to be 
> provided at mkimage time.  That makes the distribution of a single 
> uImage impossible for varied targets while distributing the 
> corresponding zImage would just work.

Understood.  But a relative load address and relative entry point
could solve this issue?

> We need to be able to provide the load address at _load_ time instead of 
> at _mkimage_ time.  In all cases, the entry point for the ARM kernel is 
> always at offset 0 from the load address as mentioned above.

Would that still be needed if the load address war relative to the
start of system RAM?

> > >  My understanding of the ARM zImage uncompress code is that the entry
> > >  point would basically be at offset zero once loaded in memory, for all
> > >  targets/boards.
> > 
> > Can we not omit that code, and use the one we already have in U-Boot?
> > Why increasing the Linux kernel image size (and thus flash footprint,
> > load time, etc.) without need?
> 
> Sorry, I'm not following you here.

Why do we have to include the uncompression and relocating code in
each Linux kernel image, when we already have it in U-Boot?

I would like to be able to omit this on resource-restricted systems.

> > >  I don't know enough about the ARM kernel's ramdisk code to comment on
> > >  whether or not it could be uncompressed directly from flash into RAM;
> > 
> > It can. We've been doing this for many years. Just never managed to
> > get the patches accepted for mainline.
> 
> And even better: rather than decompressing a ramdisk from flash, this is 
> even more efficient to set an MTD partition for it and use the ramdisk 
> content directly from flash as needed through the mtdblock device and 
> not pin down memory for it needlessly.

This may work in some cases. I agree that in almost all cases a
classical ramdisk image is not an optimal solution. However, it has
the charm that the underlying storage (the partition in flash) is not
used while the system is running, so you can overwrite it with a new
image.  Few other setups allow this.

> > The most recent attempt can be seen here:
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/53969
> > 
> > As before, RMK smashed this with his "I don't see any reason for this."
> 
> And I agree with him.  You don't need it because you may achieve better 
> system resource usage by mapping an MTD block device onto a squashfs 
> image instead.  And that would work for either NOR or NAND flash which 
> is not the case for the patch referenced above.

Just because there is methods that work well in most of the cases is
IMOP not a reason to ban support for a use case that is useful in some
other cases, especially if the code needed to support it is trivial
and does not hurt anybody.


Right now I am spending time trying to understand your requirements
and trying to come up with solutions that satisfy your needs. Note
that I do not try to argue that "you may achieve better system
resource usage" by using uImage files as they were designed, i. e.
with omitting the kernel's copy and uncomress code from the images.
At least I do not try to use this argument to kill alternative
approaches without even trying to understand why they might be useful.


> > You need a command that does not do this, but eventually receives
> > these parameters from somewhere else (command line?), but still passes
> > all required information like ATAGs and/or device tree, kernel command
> > line etc. to the image.
> 
> Exact!

I think separating image-specific information from the image is a bad
idea.  If we could agree to use relative addresses (offsets) I'd feel
much better.

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] zImage on ARM

[Nicolas Pitre]

On Mon, 13 Sep 2010, Wolfgang Denk wrote:

> Dear Nicolas,
> 
> In message <alpine.LFD.2.00.1009122338310.19366@xanadu.home> you wrote:
> > 
> > > Maybe this should/could be addressed on the Linux side then? We don't
> > > have such problems on PwerPC, for example.
> > 
> > On the Linux side, we currently have a fully position independent 
> > zImage.  So you already can load it anywhere in RAM and branch to it 
> > with an offset of 0 from where it is loaded.
> 
> It has to be started in RAM, i. e. we cannmot run it from a ROM
> location?

If you want a ROMable zImage then you need to configure the kernel build 
for that case.  So it's either zImage in ROM with a fixed address, or 
position independent zImage in RAM.

> So your problem could be solved if we were able to specify a relative
> load address (relative to the start of system RAM), and relative
> entry point address (offset into image) ?

Yes, that would work.

> Why do we have to include the uncompression and relocating code in
> each Linux kernel image, when we already have it in U-Boot?
> I would like to be able to omit this on resource-restricted systems.

Because U-Boot is not the only bootloader out there.  And all the other 
bootloaders (lilo, grub, syslinux, redboot, etc.) rely on the zImage's 
ability to self-decompress, and no bootloader specific tool like mkimage 
is required to postprocess the result.

Yet the reverse argument could be made about U-Boot: why include the 
decompression code in U-Boot when we already have it in zImage?

Still, you have the possibility to use the Image result (without the z) 
which is uncompressed and non-relocatable (has to be loaded at the 
appropriate address), and encapsulate that into a uImage if you wish for 
U-Boot to decompress.

> > And even better: rather than decompressing a ramdisk from flash, this is 
> > even more efficient to set an MTD partition for it and use the ramdisk 
> > content directly from flash as needed through the mtdblock device and 
> > not pin down memory for it needlessly.
> 
> This may work in some cases. I agree that in almost all cases a
> classical ramdisk image is not an optimal solution. However, it has
> the charm that the underlying storage (the partition in flash) is not
> used while the system is running, so you can overwrite it with a new
> image.  Few other setups allow this.

I wouldn't trust such a setup with regards to resilience against 
unexpected power failure.  But that's a topic for another discussion.


Nicolas

[U-Boot] zImage on ARM

[Wolfgang Denk]

Dear Nicolas Pitre,

In message <alpine.LFD.2.00.1009130917470.19366@xanadu.home> you wrote:
> 
> > So your problem could be solved if we were able to specify a relative
> > load address (relative to the start of system RAM), and relative
> > entry point address (offset into image) ?
> 
> Yes, that would work.

Then let's discuss how we can get there.

> > Why do we have to include the uncompression and relocating code in
> > each Linux kernel image, when we already have it in U-Boot?
> > I would like to be able to omit this on resource-restricted systems.
> 
> Because U-Boot is not the only bootloader out there.  And all the other 
> bootloaders (lilo, grub, syslinux, redboot, etc.) rely on the zImage's 
> ability to self-decompress, and no bootloader specific tool like mkimage 
> is required to postprocess the result.

I agree that it makes perfect sense to support all these restricted
boot loaders. But why not allow to use the features of U-Boot,
especially in cases where resources are tight?

> Yet the reverse argument could be made about U-Boot: why include the 
> decompression code in U-Boot when we already have it in zImage?

Because ARM is not the only architecture out there. And other
architectures do not have such problems.

Because Linux is not the only operating system out there. And other
operating systems don;t provide such fancy OS images with built-in
decompressors.

Because there is a plethora of requirements out there, including
systems that require to stroe not only a single, but two (or sometimes
even more) kernel images, and resources are expensive.


I kinf of feel ARM comes with a one-size-fits-all approach. This is
not true for embedded systems in general.

> Still, you have the possibility to use the Image result (without the z) 
> which is uncompressed and non-relocatable (has to be loaded at the 
> appropriate address), and encapsulate that into a uImage if you wish for 
> U-Boot to decompress.

That's fine with me. May we plase have a make target for this in the
mainline Linux kernel tree?

> > > And even better: rather than decompressing a ramdisk from flash, this is 
> > > even more efficient to set an MTD partition for it and use the ramdisk 
> > > content directly from flash as needed through the mtdblock device and 
> > > not pin down memory for it needlessly.
> > 
> > This may work in some cases. I agree that in almost all cases a
> > classical ramdisk image is not an optimal solution. However, it has
> > the charm that the underlying storage (the partition in flash) is not
> > used while the system is running, so you can overwrite it with a new
> > image.  Few other setups allow this.
> 
> I wouldn't trust such a setup with regards to resilience against 
> unexpected power failure.  But that's a topic for another discussion.

Agreed.  But then, do you accept this argument as valid reason to use
a ramdisk image in flash?

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
HR Manager to job candidate "I see you've had no  computer  training.
Although  that  qualifies  you  for upper management, it means you're
under-qualified for our entry level positions."

[U-Boot] zImage on ARM

[Nicolas Pitre]

On Mon, 13 Sep 2010, Wolfgang Denk wrote:

> Dear Nicolas Pitre,
> 
> In message <alpine.LFD.2.00.1009130917470.19366@xanadu.home> you wrote:
> > 
> > > So your problem could be solved if we were able to specify a relative
> > > load address (relative to the start of system RAM), and relative
> > > entry point address (offset into image) ?
> > 
> > Yes, that would work.
> 
> Then let's discuss how we can get there.

Fine with me.

> > > Why do we have to include the uncompression and relocating code in
> > > each Linux kernel image, when we already have it in U-Boot?
> > > I would like to be able to omit this on resource-restricted systems.
> > 
> > Because U-Boot is not the only bootloader out there.  And all the other 
> > bootloaders (lilo, grub, syslinux, redboot, etc.) rely on the zImage's 
> > ability to self-decompress, and no bootloader specific tool like mkimage 
> > is required to postprocess the result.
> 
> I agree that it makes perfect sense to support all these restricted
> boot loaders. But why not allow to use the features of U-Boot,
> especially in cases where resources are tight?

I don't mind having the possibility to use U-Boot features, as long as 
U-Boot lets me use a "standard" zImage if I choose to.

And the use cases we're contemplating don't have tight resources.

> > Yet the reverse argument could be made about U-Boot: why include the 
> > decompression code in U-Boot when we already have it in zImage?
> 
> Because ARM is not the only architecture out there. And other
> architectures do not have such problems.
> 
> Because Linux is not the only operating system out there. And other
> operating systems don;t provide such fancy OS images with built-in
> decompressors.
[...]

We go in circle now.  I want a single kernel binary that multiple 
bootloaders can use.  You want a single bootloader that multiple OSes 
can use.  So it is best to simply accept that there are different yet 
still valid usage patterns.

> I kinf of feel ARM comes with a one-size-fits-all approach. This is
> not true for embedded systems in general.

Well, from my perspective it seems that ARM Linux is simply trying to be 
close to X86 Linux in this regard, and not stick to one-size-fits-all 
bootloader.  So this is another circular argument.

> > Still, you have the possibility to use the Image result (without the z) 
> > which is uncompressed and non-relocatable (has to be loaded at the 
> > appropriate address), and encapsulate that into a uImage if you wish for 
> > U-Boot to decompress.
> 
> That's fine with me. May we plase have a make target for this in the
> mainline Linux kernel tree?

I should be able to arrange that.  In exchange, may we please have the 
option for booting a zImage directly in U-Boot?

> > > > And even better: rather than decompressing a ramdisk from flash, this is 
> > > > even more efficient to set an MTD partition for it and use the ramdisk 
> > > > content directly from flash as needed through the mtdblock device and 
> > > > not pin down memory for it needlessly.
> > > 
> > > This may work in some cases. I agree that in almost all cases a
> > > classical ramdisk image is not an optimal solution. However, it has
> > > the charm that the underlying storage (the partition in flash) is not
> > > used while the system is running, so you can overwrite it with a new
> > > image.  Few other setups allow this.
> > 
> > I wouldn't trust such a setup with regards to resilience against 
> > unexpected power failure.  But that's a topic for another discussion.
> 
> Agreed.  But then, do you accept this argument as valid reason to use
> a ramdisk image in flash?

Sure, why not.  However, I'd still suggest that you access it through a 
MTD block device.  This would be cleaner and would also work with NAND 
as well as with NOR.  Right now the kernel assumes a floppy device for 
this, but modifying it to accept an MTD device in init/do_mounts.c 
should be trivial.


Nicolas