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

Greg Ungerer
2005-05-23T01:32:05Z

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