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).
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 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 >> > >
