In message 42913295.6080308@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