[U-Boot] zImage on ARM

[Scott Wood]

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

> Dear Scott Wood,
> 
> In message <20100908160001.374ff382 at schlenkerla.am.freescale.net> you wrote:
> >
> > > In message <20100908153455.527fcd70 at 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