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