[U-Boot-Users] outline of bootm script

[Kumar Gala]

>>> 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