[U-Boot] zImage on ARM

[Wolfgang Denk]

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

In message <20100912150749.GB23760 at 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