Jerry Van Baren wrote:
Scott Wood wrote:
On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote:
I'm a half-ack. ;-) I'm partial to u-boot's implementation rather
than using a bootwrapper for obvious reasons. The u-boot
implementation takes the blob as a boot parameter and passes it
along to the kernel after doing appropriate (optional) fixups.
And if those fixups expect a malformed device tree?
Oops, very bad choice of terms on my part. :-( The fixups I referred
to are mostly "fill in the blank" things like setting the various
clocks, MAC information, PCI information, etc. to the correct values
based on hardware probing or a priori knowledge. U-boot does not
(should not / will not!) fix broken device trees. A broken tree w/ the
u-boot methodology is fixed by loading a corrected one, not requiring a
full rebuild and reload of the firmware.
No, I understand what you meant -- I mean cases where u-boot expects the
"blanks" to be somewhere other than where they are. This has happened
in the past, with mac-address v. local-mac-address, finding the SOC
node, duplicate /chosen nodes, etc.
If all else fails, u-boot is GPLed and the user is able to get the
source and fix it (well, at least for 3 years after purchasing the
hardware).
Regardless of that, if all else fails, one can ignore the firmware's
tree and use a bootwrapper-provided tree.
There are advantages and disadvantages to u-boot and boot-wrapper
methods. There are nothing but disadvantages to having the blob
physically a part of the firmware (with a double whammy if the firmware
source is not readily available).
The advantage is that the firmware will be kept in sync with the tree
it's trying to patch.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
