Dear Greg,
in message 4292CCC5.2050104@moreton.com.au you wrote:
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
Yes, it is what *I* want :-)
filesystem that is the first part of the combined image. You
This is the catch: I wouldn't use combined images.
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.
Did you read my proposal of using a multifile image?
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
I understand this problem., It results from an unadept choice of your image layout - put the kernel first, and the problems just go away :-)
Because there is no boot loader header this image is directly mountable if I copy it into an mtd flash partition.
You can do the same with a standard multifile image.
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.
Well, the only disadvantage you get from having a header is an additional 64 bytes (or 68 + 4 * number of images in case of a multi-image file). More memory is saved by NOT adding special boot code for headerless images.
"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.
It does work. I use it all the time. You just have to use tftp twice - once for the filesystem and a second time for the kernel :-)
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).
Well, I cannot prevent anybody from not reading the documentation or from doing non-standard things. I don't consider it my problem if Snapgear comes up with a solution that ignores the existing standard methods and creates their own proprietary solutions or problems.
Quote:
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
But I will try to enforce some design principles on the official U-Boot tree, and one of these is to avoid duplication of code.
Don't use "a pretty large installed base" as an argument - it doesn't count. You could have discussed your design here on the mailing list BEFORE implementing your own proprietary stuff.
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.
Did you *read* me previous message? Why do you continue to ignore my proposal of using a multifile image instead? I really don't see where exactly your problem is.
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.
Yes, I understood this. And ALL of this is available with either two separate images or with a combined multifile image.
- the image cannot have a header - otherwise it would not be directly mountable as a filesystem on an mtd device
Wrong. As I explained before, you can use a multifile image with the header "belonging" to the kernel, which should be the first file in the image then.
- 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
You created this problem yourself. It results from your unadept design.
If you use a multifile image with a proper header the kernel start address is encoded in the header.
- 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
Agreed. But I don't see what this has to do with the current discussion. It's a completely separate issue, relevant only to ramdisk images and then more of a Linux kernel question (i. e. if it can read a [compressed] ramdisk image directly from flash or not).
You want this setup to support boot tags - since that is the ARM defined mechanism for parsing boot information to the kernel.
This is part of the standard boot command. Just use it.
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.
You repeat this again and again. I understood your intentions.
But there is amy ways to implement this, and I repeat that your method is probably not the best one.
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
Right. YOu can also save all this effort and just use a multifile image.
automating the size calculation here). But with no ARM tags in memory it is not a correct boot.
Right. Which is one of the reasons why this approach does not make sense.
From what you have said so far it seems I was right, you cannot do this currently with u-boot?
Wrong. I really ask myself if you are READING my postings????
I try to explain to you that it CAN be done, with existing commands only.
Is a command tool that allows constructing ARM tags a better solution for you?
What for? WE ALREADY HAVE A WORKING IMPLEMENTATION FOR THIS!
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.
Please explain why not?
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.
Ummm... I cannot parse this. Can you please explain how this should be any problem? I mean, any more of a problem like in your solution? I understand that your kernel uses a static partition map, right? So the kernel knows about the current partitioning?
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?
A multifile image contains one ore more (usually more, that's where the "multi" is coming from) "files" or "images". You talk allt he time about two items: the linux kernel and a file system. So we have two "files" or "images" to deal with, right?
With the multifile setup you could - for example - have 3 "files" or "images" in one combined image - say (1) the Linux kernel, (2) a read-only root file system like a cramfs image, and (3) a writable JFFS2 image for configuration data etc.
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
But you are using two images: kernel plus root filesystem - right?
Best regards,
Wolfgang Denk