[U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO
Wolfgang Denk
wd at denx.de
Thu May 19 23:18:41 EST 2005
In message <1116498144.918.97.camel at gaston> you wrote:
>
> > Without knowing the size of the code required for this, it would still
> > mean an increase by a couple of hundred percent for the boot
> > information.
>
> Well, if you build the device-tree blob at bootloader build time (you
> can then embed it in your bootloader or maybe just put it somewhere in
> flash), there is little code involved, basically passing a pointer to it
> to the kernel. Now, if you mean the kernel code, oh well, have you seen
> how big a ppc64 kernel is anyway ? :)
Marius was talking about the amount of data passed to the kernel.
And yes, we are aware how big a ppc64 kernel is. One might argue that
you need a 64 bit kernel only for big systems, so resources are
cheap. On the other hand, we are also aware how big the 2.6 kernel is
compared against 2.4, and how it suffers performancewise.
My concern is that just adding a few kB of code here and there and
passing a bit more data from A to B and using ASCII representation
for the data and all of that will result in elegant and easily
maintainable code on one side, but to even bigger memory footprints
for boot loader and kernel and longer boot times on the other side,
too. We have seen before how this works.
A few tens or hundreds of milliseconds of boot time may not mean
anything on a fast 64 bit machine which will spend ages anyway while
scanning a lot of SCSI busses and all that, but it will *hurt* on
many embedded systems.
> I would expect something like uboot to be a bit more smart though and
> provide optionally some functions to add nodes/properties, but heh,
> we'll see. I'll try to provide example code after I'm done with the spec
> part.
It's not only an issue of being smart enough. It has also a lot do to
with hardware restrictions. If you have a product that sells several
1e4 or 1e5 units per year which now works with just 4 MB of flash for
boot loader and Linux kernel and application code you have hard times
to explain that the next software generation will need bigger (and
more expensive) flashes just because of using more elegant code.
Yes, small *is* beautiful.
We had this discussion before, several times. There once was a
proposal by Mark A. Greer (see discussion on the linuxppc-embedded
mailing list that started as "EV-64260-BP & GT64260 bi_recs" around
March 19, 2002) which was elegant, flexible and lean. If it was not
actually sad it could be funny that the general agreement will always
end up to be the biggest and slowest of all possible solutioins.
But my biggest concern here on the U-Boot list is: U-Boot is not only
for PowerPC systems. We should also keep an eye on what ARM and MIPS
is doing... See my other posting.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To get something done, a committee should consist of no more than
three men, two of them absent.
More information about the Linuxppc64-dev
mailing list