In message <1083C28A-076D-4D63-B9B6-9FFFABFF4B54 at 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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ever try. Ever fail. No matter. Try again. Fail again. Fail better.
-- S. Beckett