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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> 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.

It is not the filesize that you want. You want the size of the
filesystem that is the first part of the combined image. You
need to know that so you can find the the start of the kernel
image (the zImage part) that is after the filesystem.

To get the filesystem size you have to look at the first few
words when you get it in memory. Once you figure out the filesystem
type (since there is only a couple of interresting types that
can work here you only need to check for the magic number header)
you know how to determine its size.

So single file image is:


   +----------------------------------------+---------------------+
   |       filesystem                       |  kernel             |
   +----------------------------------------+---------------------+
                                            ^
                                            |

You don't know where the kernel starts until you have a look in the
header of the filesystem. If it is CRAMfs or ROMfs (or that type of
fixed filesystem) then the size is stored in the the header.

The start offset of the kernel in this file will change whenever you
change the filesystem (normally it is a readonly type, so the only
change is at compile time when you generate it).

Because there is no boot loader header this image is directly mountable
if I copy it into an mtd flash partition.


>>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.

Some people want that, some don't. There is a pretty big installed
base of configurations that don't use headers.


>>>>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.

As I pointed out that does not work, it is not filesize you want.


>>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.

Well, thats not quite the way I looked at it. I saw it as
a limitation of u-boot, something that it could not do.

This method is in common use. The snapgear guys have been
doing it for years. They would have a pretty large installed
base (though that is not relevant to this discussion).


>>>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.

It is not a question of tolerating anything, it is about
finding a solution that is acceptable to you for something
that u-boot cannot currently do.


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

Yes, the requirement is to be able to store the image in flash and have
it directly bootable and mountable, and for it to be network loadable
and to run just the same that way. Ofcourse it has to support the ARM
boot tags, this is booting an ARM linux kernel.

So there is a couple of problems that fall out of this:

1. the image cannot have a header - otherwise it would not be
    directly mountable as a filesystem on an mtd device
2. you need to determine the kernel start address so you can
    run it (irrespective of whether it is in flash or network
    loaded into RAM
3. you don't want to copy the filesystem part needlessly (so if it
    is in flash then don't bother copying it to RAM, and don require
    any additional copy of filesystem if network loaded into RAM

You want this setup to support boot tags - since that is the
ARM defined mechanism for parsing boot information to the kernel.

The fundamental idea is to have a single image that is a single file
that is capable of all of this. (in other words it can be directly
dumped into an mtd flash partition - usually within Linux, and it is
capable of being network loaded and run.

I can load a one of these combined images into RAM (or from flash)
using standard command, I can manually determine the size by dumping
memory and looking at, I can start that image. I can do all of this
without any extra command support (though I am not sure about
automating the size calculation here). But with no ARM tags in
memory it is not a correct boot.

 From what you have said so far it seems I was right, you cannot do
this currently with u-boot?

Is a command tool that allows constructing ARM tags a better solution
for you?


> 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.

But I cannot copy this "as is" into an mtd flash partition and
mount it as a filesystem.

Even if you try to pad out to mtd partition boundaries that is at best
a kludge. You will either waste too much flash space, or you will
eventually have a kernel that is too large. It will happen.


> 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.

I don't understand, two images?
Virtually all the platfoms I deal with do not have the flash space for
two images (or even just two kernels). If they did then the hardware
guys have spec'ed to much flash on the board :-)

Regards
Greg