Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]

[Jakob Viketoft]

Hello Andrei!

Andrei Konovalov wrote:
> Hi Jakob!
> 
> Yes, Jon Loeliger's implementation plan looks OK for me
> (as far as I understood Jon's posting; having look at
> the current patch would be great). And I could participate
> in the implementation for Xilinx if needed too, but don't
> object if you do it by yourself (at the moment, I know
> little about the OF device tree, so just testing the patch
> on ML300 would be fine for me as well).

Great! I could start and ask for assistance when needed... :)

> Should we rely on U-Boot to give that device tree structure to
> the kernel? If I got it correct this is how the Freescale team
> plans to proceed. Jon (Masters), are you going the same way?
> Anyone using arch/ppc/boot/simple bootwrapper with his Virtex 2 Pro
> board? If we drop Virtex 2 Pro support in arch/ppc/boot and move to
> U-Boot would it hurt anyone?
> 
> Thanks,
> Andrei

My end intention is to write something that both builds the OF device 
tree from a listed number of (ip-)devices and a small FPGA-suitable 
bootloader (as a small prog separated from the kernel). It'll probably 
end up being an entire "Linux on Xilinx" howto... I say we can drop the 
simple bootwrapper once all the stages of the OF adaptation is in place 
(which might not happen overnight :).

Cheers!

	/Jakob

> 
> Jakob Viketoft wrote:
> 
>> Hi!
>>
>> You don't happen to have a patch of your current work against one of 
>> the trees (83xx and 85xx)? It would be much easier to do work in 
>> parallell, and I'd be happy to do it on the "Xilinx" tree (and help 
>> out where I can, of course).
>>
>> Jon Masters and Andrei: Does Jon Loeliger's implementation plan sound 
>> alright to you? Since you seem quite full-handed on your end anyway, 
>> Jon, I'll be happy to do the work needed unless anyone has any 
>> objections...
>>
>> Cheers!
>>
>>     /Jakob
>>
>> Jon Loeliger wrote:
>>
>>> On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
>>>
>>>> Kumar Gala wrote:
>>>>
>>>> |> My intention was to give a device tree structure to the kernel at 
>>>> boot
>>>> |> time via a (pseudo?) pointer in bd_info or similar. 
>>>
>>>
>>>
>>>
>>>> This got resurrected recently. 
>>>
>>>
>>>
>>>
>>> Hi!
>>>
>>>
>>>> | I think this is reasonable.  The best device tree would be a 
>>>> flattened
>>>> | OF tree since we are trying to move the world in that direction.  Jon
>>>> | Masters around?
>>>>
>>>> Yes, but I've been tied up with worky and magazine stuff again. If
>>>> someone wants to work with me then this might actually happen.
>>>
>>>
>>>
>>>
>>> Hi Jon,
>>>
>>> I'm here and actively(!) working on it now.   Here is the very
>>> rough plan as Kumar and I have discussed it.  Please feel free
>>> to comment on it or offer suggestions.  Ben has suggested that
>>> I start with the "second step" below.  I'd like to do a round
>>> of cleanup first.
>>>
>>> So far, I have taken the first step of isolating the references
>>> to the global __res[] variable into one file and replacing all
>>> references to the data in the bd_t structure with a thin, shim
>>> layer of function calls that are nominally into an OF-like
>>> interface.  I have done this for all the 85xx and 83xx boards
>>> in my development tree, and am working on the others now.
>>> This step effectively isolates the __res[] references to one
>>> file where a well defined interface can be created to pose as
>>> an OF Device Tree layer (briefly).
>>>
>>> As a follow-up second step, I plan on introducing essentially
>>> the same code currently in ppc64 to handle the flat device tree
>>> and provide an interface to that data in exactly the same manner
>>> as the ppc64 currently has.  I understand the desire to have the
>>> flat-tree handling be "outside the kernel".
>>>
>>> As a third step, the shim layer will be rewritten/augmented to
>>> use the actual OF device tree data where it currently fronts
>>> for the bd_t data.
>>>
>>> Finally, as time permits and maintainers allow (read: prod),
>>> the other (not 85xx, not 83xx) boards can have their setup code
>>> converted to use the "real" OF device tree function calls.
>>>
>>> When all of that is done, the shim layer can be removed, as needed.
>>>
>>>
>>> Oh, yeah.  Um, also on my plate will be to construct the
>>> original flat-tree blob in U-Boot to be handed to the kernel.
>>> (I'll start with 85xx and 83xx, naturlich.)
>>>
>>> We have not yet decided on the layout of that tree to determine
>>> where all the attributes and devices really belong.  I will
>>> also discuss with Wolfgang and crew how to generate that tree
>>> over in U-Boot land.
>>>
>>> Right?
>>>  
>>> Thanks,
>>> jdl
>>>
>>
>>
>