[U-Boot-Users] outline of bootm script

Kumar Gala
2008-08-06T21:37:24Z

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