From: Andrei Konovalov <akonovalov@ru•mvista.com>
To: Jakob Viketoft <jakob.viketoft@bitsim•se>
Cc: Jon Masters <jonathan@jonmasters•org>,
Sylvain Munaut <tnt@246tNt•com>,
Linux PPC Embedded list <linuxppc-embedded@ozlabs•org>
Subject: Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Date: Mon, 04 Apr 2005 14:56:21 +0400 [thread overview]
Message-ID: <42511D55.4040507@ru.mvista.com> (raw)
In-Reply-To: <4250EACF.1040403@bitsim.se>
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
>>
>
>
next prev parent reply other threads:[~2005-04-04 10:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-30 8:00 Platform bus/ppc sys model Jakob Viketoft
2005-03-30 9:54 ` Sylvain Munaut
2005-03-30 13:52 ` Andrei Konovalov
2005-03-30 15:06 ` Kumar Gala
2005-03-30 16:12 ` Jakob Viketoft
2005-03-30 17:26 ` Kumar Gala
2005-03-31 12:33 ` Jon Masters
2005-03-31 15:55 ` Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...] Jon Loeliger
2005-04-04 7:20 ` Jakob Viketoft
2005-04-04 7:31 ` Jon Masters
2005-04-04 10:56 ` Andrei Konovalov [this message]
2005-04-04 11:01 ` Jon Masters
2005-04-04 11:08 ` Jakob Viketoft
2005-04-04 16:45 ` Wolfgang Denk
2005-04-04 16:58 ` Andrei Konovalov
2005-04-04 16:56 ` Jon Masters
2005-04-07 17:20 ` Tom Rini
2005-04-07 17:35 ` Jon Loeliger
2005-04-07 17:49 ` Tom Rini
2005-04-11 15:58 ` Jon Loeliger
2005-04-14 9:54 ` Jakob Viketoft
2005-04-15 14:22 ` Jon Loeliger
2005-04-22 17:33 ` Andrei Konovalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42511D55.4040507@ru.mvista.com \
--to=akonovalov@ru$(echo .)mvista.com \
--cc=jakob.viketoft@bitsim$(echo .)se \
--cc=jonathan@jonmasters$(echo .)org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=tnt@246tNt$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox