[PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware

Timur Tabi timur at freescale.com
Sat May 19 03:39:19 EST 2007


Jerry Van Baren wrote:

>> I'd like to point out that what I originally proposed was much simpler
>> than this; 

Actually, we're talking about the same thing, but I guess my over-simplification back-fired.

> Aye, that looks useful and reasonable to me.  In one of my previous 
> spiels I talked about merging fragments of fdt blobs.  That was a 
> half-baked thought, the above dts (blob) would have all the fragments in 
> it and the u-boot board-specific logic would be copying/moving the 
> selected nodes.  That has a lot of benefits...

The idea stemmed from a desire to have a single DTS file for a given board, even in 
situations where jumpers changed what hardware was enabled.

> * The above should result in reasonable board-specific code.
>   * We may want to invent a libfdt move/copy subtree function (I don't
>       recall one being in there).  Board specific code would want to
>       move selected subtrees out of /u-boot,hwoptions into the
>       appropriate final node.  All the pieces are in libfdt, just would
>       need to be hooked together in a utility subroutine.

Just being able to delete a given node/property would be enough.  By default, the nodes 
with conditionals would be present in the device tree.  The boot loader would then also 
strip out all conditionals from the device tree before passing it to the kernel.  The 
kernel would then receive a standard device tree like it does today.

> * With the above, nothing in the infrastructure (dtc, libfdt) needs to
>     change.
> 
> On a related note, would it be better to name the node 
> "/u-boot/hwoptions" (two levels deep)?  It seems very desirable to me to 

It's not a u-boot-specific concept.  The idea of representing jumpers (and other hardware 
options) in the device tree is not something that's unique to u-boot or any boot loader. 
The conditionals, however, are a bootloader-specific concept.  We don't want Linux to see 
them.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale



More information about the Linuxppc-dev mailing list