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:

quoted

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:

quoted

On Thu, 2005-03-31 at 06:33, Jon Masters wrote:

quoted

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. 

quoted

This got resurrected recently. 

Hi!

quoted

| 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