In message 1083C28A-076D-4D63-B9B6-9FFFABFF4B54@kernel.crashing.org you wrote:
I think the average user does not need to now this. He can just run
the systemn-provided "bootm" command without caring if this is a
monolithic pile of unreeadable code, or a wrapper function that sequentially calls out for a list of simple helper functions, or some sort of script (or list of commands stored in an environment variable) that get executed.
But the developer gets the freedom to implement exactly the behaviour he wants by being able to redefine the steps he rund and their order.
I understand.. but moving ALL the control logic that exists in bootm into a script language just seem like a bad idea to me. This means boots will be that much slower as we have to parse all this control logic in the "shell".
If you compare the number of CPU cycles it takes to uncompress a recent kernel image against the cycles needed to parse a line of shell commands I am pretty sure that this will not actually matter. Even if it was a few milliseconds - that's something I'm more than willing to pay for the all the much cleaner code.
And keep in mind that this applies only to the expert user who plays shell tricks; Johnny Luser will just run the pre-canned function builtin.
Stop, this is not correct. "filesize" gets set when loading the (compressed) image. It contains the _file_ size, i. e. the sum of all included images plus headers etc.
bootm does not touch filesize.
in the method you guys seem to be arguing for we have to return the address the image was loaded at and the size. W/o this info I dont
No, we pass the load address as argument to the loader / uncompressor. Just like we are doing it now.
see how the next step can decide where to boot the .dtb or initrd. I was just 'filesize' just as part of my example.
Well, at the moment we don't do any such clever stuff eihter. We load the kernel low and the ramdisk high. That's all.
Do we need more?
Why cannot U-Boot just malloc() space for the fdt?
Because the memory malloc() gives me isn't guaranteed to meet the set of constraints we have. (the memory can't be part of the OS image, has to be properly aligned, has to be within the BOOTMAP_SZ).
So load it high within the limits of BOOTMAP_SZ.
Please read the README again - it explains the whole philosophy as it used to be implemented 8 years ago - plain simple and reliable: load the kernel low (because that's what the kernel needed), and the ramdisk high (within the limits of RAM size and, if defined, initrd_high). If you want to stick in the DTB here, then load it before the ramdisk, and the ramdisk below it. The DTB size is easy to get, me thinks.
Best regards,
Wolfgang Denk