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