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

[Greg Ungerer <gerg@moreton.com.au>]

Hi Wolfgang,

Wolfgang Denk wrote:
> Dear Greg,
> 
> in message <428DF0F8.5090404@moreton.com.au> you wrote:
> 
>>The gofsk command is something I added to support loading
>>snapgear/uClinux-dist style raw filesystem+kernel images. 
> 
> 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.


>>The image itself is a simple concatenation of a root filesystem
>>and a kernel. Typically it is used with a CRAMfs root filesystem.
>>The primary motivator for not having any header on this image is
>>that it can be dumped directly into an MTD flash partition, and
>>it can be directly mounted as the root filesystem. For known
> 
> 
> This is normal. We don't have headers for standard filesystem  images
> like cramfs, ext2 or jffs2 for exactly this reason.

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


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

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.


>>Patch attached is my current implementation of this.
>>
>>Is this something that you would allow into the main tree?
> 
> No, I don't think so. I don't see what it gives you what  you  cannot
> get  with the existing commands and clever usage of a few environment
> variables. Also, in general I find it is not a good idea  to  combine
> filesystem  and  OS  kernel  into  ane  image.

As a general rule I have always found the exact opposite. Although
conveient for debugging I find sepearate kernel and filesystems a
limitation in real field setups. A single flash partition with no
additional layout restrictions is a much more flexible arrangment.
Doesn't limit one or the others size or location.


>  Usually  you buy more
> restrictions than advantages this way. If you feel you  must  do  it,
> you  could extend the capabilities of mutli-file images to match your
> needs.
> 
> 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?

Regards
Greg