[U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO

[Benjamin Herrenschmidt]

> Marius was talking about the amount of data passed to the kernel.

A few Kb maybe... Current implementations always provide a full featured
device-tree with pci devices so they aren't a good example (and I don't
have numbers in mind at the moment). I'll try to get some later today.
The property names are factored out (only one copy of a given name) to
avoid bloat, the node format is very compact, A small device-tree would
be only about a dozen node (the minimal is 5 nodes including the root)
with only a few properties 

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

I wouldn't say it sufferred performance wise on all architectures. Small
embedded CPUs may have sufferred (mostly because of larger memory
footprint impact on small TLBs), but ppc64 is definitely not something
you ever want to use with a 2.4 kernel, and I would expect 2.6 to be
faster on 6xx/7xx/7xxx type CPUs as well.

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

I don't think it will have any significant impact on the boot time. Not
at all. In fact, I'm not even sure the code would be that much bigger
neither. For example, all the code needed to declare all the
device-specific platform devices used in some case would be _replaced_
by a generic routine that declares a device based on the device-tree
data, that sort of thing. I honestly cannot tell what kind of bloat is
to be expected, but I really don't think it will be relevant.

Even the code for iterating the fully expanded device-tree & properties
in the kernel isn't big, but as I wrote earlier, a non-ppc architecture
wanting to use that proposal may want to work directly on the flattened
tree.

I REALLY think people are over-estimating the size & complexity of the
device-tree.
 
> 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 wouldn't even expect that much.

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

Did you read the "optional" above ? Let me repeat _AGAIN_ here: the
bootloader doesn't _need_ ANY code to deal with the device-tree if you
decide to just build the blob once for all, and embed it "as is".
However, not everybody is fighting after 10 bytes of flash, and thus it
would be useful if optionally, uboot could provide the machine specific
code with functions to do things like edit the memory or bootargs
properties in there.

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

Fuck it ! This is not by far the biggest and slowest of all solutions,
the tree format is on purpose very compact, it's not a few strings that
will make that much of a difference, damn . Do you really want me to
propose ACPI AML instead ?

Besides, I know the bi_rec stuff well as I propoed it in the first
place, and nobody ever came to an agreement about that neither.

Face it, there will NOT be any other way that will be accepted upstream
to boot a ppc64 kernel.
> 
> 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.

Sure, you are welcome to do so. I'm posting to this list because of
Marvell's intend to use uboot as a bootloader for what appear to be the
first ppc64 platform not to implement the OF command line interface.

Ben.