In message 1116498144.918.97.camel@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