Mikrotik RouterBoard 333

[Scott Wood]

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