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?
Yes. bd_t for old style boot... no idea on non-ppc.
Have you looked at the fdt handling code in lib_ppc/bootm.c:
look at boot_get_fdt(), boot_relocate_fdt() and think about recoding that in a script. eeck!
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.
dtb size is NOT easy to get. It can change significantly between the "raw" dtb and after "fdt boardsetup".
- k