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

[Wolfgang Denk]

In message <42913295.6080308 at 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_