[U-Boot-Users] [PATCH] add OpenGear CM4008 board support

Wolfgang Denk
2005-05-23T08:48:41Z

In message <42913295.6080308@moreton.com.au> you wrote:
>
> > I don't understand why a separate command is needed for that; you
> > need to store the start address of the image anyway, so you can also
> > store it's size and use this to compute any other offset; or store
> > the kernel address, too.
>
> Not quite. The start address is fixed (as in fixed position in flash
> normally). Size is completely dependant on the image - so you need
> to compute that at run time. You don't want to store the length
> independantly.

You can "compute" the image size at download time - actually it comes
for free in $filesize.

> Yes, but that is not the point here. The is a complete system image
> with no heads (system being kernel and root filesystem).

I think it is not a good idea to use header-less kernel images - most
projects I've seen were happy enough to be able to find outr which
image is installed in flash and if it's corrupted or not. YMMV.

> >>filesystem types (like CRAMfs and ROMfs) the loader simply looks
> >>over the filesystem to get to the kernel for boot time starting.
> >
> > Why do you need a separate command for this?
>
> The other possibility seemed to be for a complicated sequence
> of commands to extract the size - though I didn't try to actually
> do this.

"tftp ..." followed by using $filesize seems not too complicated to
me.

> But I still wanted to construct the armtags for boot. I couldn't
> see that this was currently possible if not used a strictly tagged
> ARM u-boot image.

One more reason to use headers for the kernel image.

> > But the main question is: what can you do with this setup that cannot
> > be done with the existing code, too?
>
> I couldn't see how to load a raw image (no header) and still get the
> ARM tags setup for booting. ofcousre this was with 1.1.1 when I
> originally did this. Is it possible now?

You cannot. And I will not tolerate duplication of the standard Linux
boot command code into other "private" commands. Let's keep the code
clean and implemented only once.

But this was NOT your requirement. You wanted to store a kernel image
in flash immediately following a cramfs (or other file system) image.

The file system image is usually header-less (only exception: ramdisk
images); the kernel image should have proper U-Boot headers so it can
be nooted by the standard bootm command.

If I wanted to do this, I would probly change the order: put the
kernel image first, followed by the filesystem image. Then we ar
every close to using a standard multi-file image. The only thing
still needed is to manually pad the kernel image so that the file
system will start on a sector boundary.

If this is too cumbersome, you could easily patch the mkimage tool to
take a new option ("-b blocksize" or so) to do the padding
automatically for you.

That would be even more flexible as it does not restrict you to just
two images.

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
They weren't that important. They were merely at the top. The people
who really run organizations are usually found several levels down,
where it's still possible to get things done.
- Terry Pratchett, _Small Gods_