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

[Jerry Van Baren]

Timur Tabi wrote:
> David Gibson wrote:
>> On Thu, May 17, 2007 at 01:46:26PM -0500, Timur Tabi wrote:
>>> Wade Farnsworth wrote:
>>>
>>>> Yes.  On rev 1.0 boards, all of the devices on the south bridge are on
>>>> bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
>>>>
>>>> I'd like to use the same dts for both rev's if possible.  But if there
>>>> is a reason why they shouldn't, I suppose I could create a separate dts.
>>> I think two DTS files is the best approach for now.  A few of us had
>>> an idea to introduce conditional statements in to the DTS, and
>> Erm... how would you encode such conditionals in the dtb?  
> 
> We'll propose a spec once we have everything figured out.  Our current idea is to allow 
> any node or property to have a conditional attached to it.  U-Boot will then scan the 
> device tree, evaluate the conditional, and if it's false, delete the particular node/property.
> 
> U-Boot will be also be expanded to include the concept of "hardware options", whether the 
> user and/or board-specific code can tell U-Boot that hardware option X is set to value Y. 
>   The conditions in the device tree will be of the form "X == Y" (or X != Y, X > Y, etc).
> 
> For instance, on some board, if jumper 22 is on, then it means that the USB port is 
> enabled.  If it's possible for software to scan the status of J22, then the board-specific 
> code will do that, and it will create an environment variable "J22=ON".  The USB node in 
> the device tree will have the conditional "J22 = ON".

I am skeptical.

If hardware can discover configuration details, u-boot software, using 
libfdt, can modify existing and add new configuration items to the fdt 
(modify properties, create nodes, add properties, select the proper fdt 
snippets and merge them into the base fdt).

As I understand it, this is what OF does.  Stuff that isn't probable 
needs to be hardcoded in the base fdt.  Stuff that is configurable 
should be probed and the pieces of fdt generated/selected and added to 
the base fdt.

U-Boot: OF without the RPN.  ;-)

>> I really
>> don't like the idea of having a generalized conditional
>> parser/evaluator built into the bootwrapper.
> 
> Well, let us present the full proposal with our reasonings when we're ready.  I don't want 
> to engage in speculative debate.

Oops, too late. :-D

>> What I'd been thinking for situations like this is to fold two dtbs
>> into the bootwrapper and have it select between them based on on board
>> revision (assuming that can be deduced from registers somehow).
> 
> Our idea is very similar, but just more standardized and more granular.

Best regards,
gvb