[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