Platform bus/ppc sys model...

Platform bus/ppc sys model...

[Jakob Viketoft]

Hello everyone!

This is a mail I sent to Kumar Gala, but as he rightly pointed out that 
more people might benefit from the information and contribute to it, I 
send it to the list instead.

Is there some good documentation about how to use the platform bus / ppc
sys model or is it only possible to read and try to understand the code
for the freescale devices?

Specifically, how do you make the kernel aware of a certain device and
what else is required? Do I have to "connect" the device and the driver
or will the new model find this out automagically? I'm looking at adding 
the usual serials, emacs etc...

Lastly, I suppose this will be the way all platforms should connect
their boards with the devices "from now on", right?

Cheers!

	/Jakob

Re: Platform bus/ppc sys model...

[Sylvain Munaut]

Hi,


> Is there some good documentation about how to use the platform bus / ppc
> sys model or is it only possible to read and try to understand the code
> for the freescale devices?

I'm not aware on documentation for the ppc_sys model in particular but
the code is pretty easy to understand/read.

Basically you have a ???_devices.c that describe all the devices you can
find in a family of devices (by family I mean basically the same 
processors but with slightly different options/peripheral), then a 
???_sys.c that describe each particular variant with the devices that 
are really implemented in that variant). Then somewhere in platform init 
code, you need to identify the ppc system  you're runngin on ( by a 
identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).

Kumar, if I got it wrong, please correct ;)


> Specifically, how do you make the kernel aware of a certain device and
> what else is required? Do I have to "connect" the device and the driver
> or will the new model find this out automagically? I'm looking at adding 
> the usual serials, emacs etc...

It's "automatic" by using matching of strings. The driver name has to be
the same as the device name. More specifically by matching the name 
field in struct platform_device with the name field in struct 
device_driver. The code for this magic is in drivers/base/platform.c


> Lastly, I suppose this will be the way all platforms should connect
> their boards with the devices "from now on", right?

It seems to be the trend yes.
The OCP and platform bus model have the same base idea/concept. The 
advantage of platform bus is that it's common in multiple arch, the rest 
  is mainly style. The ppc sys model is based on platform bus to ease 
working with SoC variants.



	Sylvain.

Re: Platform bus/ppc sys model...

[Andrei Konovalov]

Sylvain Munaut wrote:
> Hi,
> 
> 
>> Is there some good documentation about how to use the platform bus / ppc
>> sys model or is it only possible to read and try to understand the code
>> for the freescale devices?
> 
> 
> I'm not aware on documentation for the ppc_sys model in particular but
> the code is pretty easy to understand/read.
> 
> Basically you have a ???_devices.c that describe all the devices you can
> find in a family of devices (by family I mean basically the same 
> processors but with slightly different options/peripheral), then a 
> ???_sys.c that describe each particular variant with the devices that 
> are really implemented in that variant). Then somewhere in platform init 
> code, you need to identify the ppc system  you're runngin on ( by a 
> identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).
> 
> Kumar, if I got it wrong, please correct ;)

Do I understand correct that the ppc_sys model used by 85xx, 83xx, and 52xx
SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear in mind)?
In case of Xilinx ???_devices.c could be the list of all the IPs supported in linux.
But ???_sys.c has little sense as for any given combination of the particular
Virtex-II Pro chip and the particular board the set of IPs (as well as the memory
map, interrupt numbers, some hardware options (if ethernet has SGDMA or not))
is not fixed. I.e. ideally we would need some kind of run time system configuration
instead of compiled time system configuration implemented by ???_sys.c.

Thanks,
Andrei

>> Specifically, how do you make the kernel aware of a certain device and
>> what else is required? Do I have to "connect" the device and the driver
>> or will the new model find this out automagically? I'm looking at 
>> adding the usual serials, emacs etc...
> 
> 
> It's "automatic" by using matching of strings. The driver name has to be
> the same as the device name. More specifically by matching the name 
> field in struct platform_device with the name field in struct 
> device_driver. The code for this magic is in drivers/base/platform.c
> 
> 
>> Lastly, I suppose this will be the way all platforms should connect
>> their boards with the devices "from now on", right?
> 
> 
> It seems to be the trend yes.
> The OCP and platform bus model have the same base idea/concept. The 
> advantage of platform bus is that it's common in multiple arch, the rest 
>  is mainly style. The ppc sys model is based on platform bus to ease 
> working with SoC variants.
> 
> 
> 
>     Sylvain.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Platform bus/ppc sys model...

[Kumar Gala]

On Mar 30, 2005, at 7:52 AM, Andrei Konovalov wrote:

> Sylvain Munaut wrote:
>  > Hi,
>  >
> >
> >> Is there some good documentation about how to use the platform bus=20=

> / ppc
>  >> sys model or is it only possible to read and try to understand the=20=

> code
>  >> for the freescale devices?
>  >
> >
> > I'm not aware on documentation for the ppc_sys model in particular=20=

> but
>  > the code is pretty easy to understand/read.
> >
> > Basically you have a ???_devices.c that describe all the devices you=20=

> can
>  > find in a family of devices (by family I mean basically the same
> > processors but with slightly different options/peripheral), then a
> > ???_sys.c that describe each particular variant with the devices =
that
> > are really implemented in that variant). Then somewhere in platform=20=

> init
> > code, you need to identify the ppc system=A0 you're runngin on ( by =
a
> > identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).
>  >
> > Kumar, if I got it wrong, please correct ;)

thats a pretty fair description.

> Do I understand correct that the ppc_sys model used by 85xx, 83xx, and=20=

> 52xx
>  SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear=20=

> in mind)?
>  In case of Xilinx ???_devices.c could be the list of all the IPs=20
> supported in linux.
>  But ???_sys.c has little sense as for any given combination of the=20
> particular
>  Virtex-II Pro chip and the particular board the set of IPs (as well=20=

> as the memory
> map, interrupt numbers, some hardware options (if ethernet has SGDMA=20=

> or not))
>  is not fixed. I.e. ideally we would need some kind of run time system=20=

> configuration
>  instead of compiled time system configuration implemented by=20
> ???_sys.c.

This is correct.  There is nothing that precludes us from building up a=20=

way to dynamically create the information.  Is there some way to query=20=

the hardware itself, or is the information implied something else?

- kumar

Re: Platform bus/ppc sys model...

[Jakob Viketoft]

Kumar Gala wrote:
> On Mar 30, 2005, at 7:52 AM, Andrei Konovalov wrote:
>> Do I understand correct that the ppc_sys model used by 85xx, 83xx, and 
>> 52xx
>>  SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear 
>> in mind)?
>>  In case of Xilinx ???_devices.c could be the list of all the IPs 
>> supported in linux.
>>  But ???_sys.c has little sense as for any given combination of the 
>> particular
>>  Virtex-II Pro chip and the particular board the set of IPs (as well 
>> as the memory
>> map, interrupt numbers, some hardware options (if ethernet has SGDMA 
>> or not))
>>  is not fixed. I.e. ideally we would need some kind of run time system 
>> configuration
>>  instead of compiled time system configuration implemented by ???_sys.c.
> 
> 
> This is correct.  There is nothing that precludes us from building up a 
> way to dynamically create the information.  Is there some way to query 
> the hardware itself, or is the information implied something else?
> 
> - kumar

My intention was to give a device tree structure to the kernel at boot 
time via a (pseudo?) pointer in bd_info or similar. Then you would only 
need to recompile a little bootloader (which is needed for setting up 
the FPGA anyway) with this structure for every specific card. You could 
even be shrewd enough to have a single kernel image but several 
structures to launch several processors on the same chip. Does it sound 
like a sane solution?

Otherwise, I'm a bit unsure as to whether a system with a gigantic list 
of devices in ???_devices.c is the right way to go. In the Xilinx case, 
not only is a list of possible IP:s needed, but also the usual standard 
circuits which can be connected from outside to the chip. Wouldn't it be 
more realistic to have knowledge of the compiled in drivers somehow?

	/Jakob

Re: Platform bus/ppc sys model...

[Kumar Gala]

> My intention was to give a device tree structure to the kernel at boot
> time via a (pseudo?) pointer in bd_info or similar. Then you would only
>  need to recompile a little bootloader (which is needed for setting up
> the FPGA anyway) with this structure for every specific card. You could
> even be shrewd enough to have a single kernel image but several
> structures to launch several processors on the same chip. Does it sound
> like a sane solution?

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?

> Otherwise, I'm a bit unsure as to whether a system with a gigantic list
> of devices in ???_devices.c is the right way to go. In the Xilinx case,
> not only is a list of possible IP:s needed, but also the usual standard
>  circuits which can be connected from outside to the chip. Wouldn't it 
> be
> more realistic to have knowledge of the compiled in drivers somehow?

Your needs are a bit different than the initial purpose of ppc_sys.  
The reason the device list works well for us today is that it replaced 
duplication between every variant of 85xx.

I'm not that familiar with exactly what information you would need to 
have access to in the Xilinx case.  I would think if you information 
compiled into drivers some of this might all be moot.  Part of the 
whole device model is to have drivers that are agnostic of the system 
they are in.

- kumar

Re: Platform bus/ppc sys model...

[Jon Masters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. Then you would only
|>  need to recompile a little bootloader (which is needed for setting up
|> the FPGA anyway) with this structure for every specific card. You could
|> even be shrewd enough to have a single kernel image but several
|> structures to launch several processors on the same chip. Does it sound
|> like a sane solution?

This got resurrected recently. Some of us have been talking privately
about it and I should have time with a board and BDI shortly. The idea
above about the bd_info pointer is precisely what I've been working with
people off list on.

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

Cheers,

Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCS+38eTyyexZHHxERAhKmAJ9v2k8rvFjB+W9OmXu4P7blHiWIkQCglEFk
AA2fZEsXmpWV0Jj/Z2OCrxA=
=oVje
-----END PGP SIGNATURE-----

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

[Jon Loeliger]

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

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

[Jakob Viketoft]

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
> 

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

[Jon Masters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakob Viketoft wrote:

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

It sounds good. I'm planning to followup on that later - yes I'm pretty
tied up but I can vaguely get away with hacking on the Memec v2p board
on work time and briefly have an ML300 at home here for something else,
so I can probably test both.

Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUO1AeTyyexZHHxERAoSyAJ0TyBCTqLZoIovZ0ZW7a8Z8HGhfVwCfV3Z5
TH/5IdR8IHBo4P15GNnK/+U=
=hHAo
-----END PGP SIGNATURE-----

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

[Andrei Konovalov]

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

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

[Jon Masters]

Andrei Konovalov wrote:

> Should we rely on U-Boot to give that device tree structure to
> the kernel?

I think this is the best way to do it - there's already a ppc_md struct 
kicking around which is semi-meant for this kind of thing.

> If I got it correct this is how the Freescale team plans to proceed.

Good. It might actually happen if enough of us want it to :-)

> Jon (Masters), are you going the same way?

Yes, but I'm more than willing to pitch in with the Freescale guys if 
that'll get things done faster - they've obviously got more manpower. I 
wanted to get this thing done already! :-)

> 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?

I don't use it. I have a very simple bootloader which I use on our Memec 
based design - comes in straight off sysace and jumps at the kernel 
after doing simple diagnostics, avoided the need for porting an existing 
boot loader and it's reasonably able to cope with braindead Xilinx HALs.

Jon.

Re: 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
>>>
>>
>>
> 

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

[Wolfgang Denk]

In message <42511D55.4040507@ru.mvista.com> you wrote:
> 
> 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?

Who said this, and where? I am not aware of such a discussion.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The best index to a person's character is a) how  he  treats  people
who can't do him any good and b) how he treats people who can't fight
back."                                            - Abigail Van Buren

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

[Jon Masters]

Andrei Konovalov wrote:

> Wolfgang Denk wrote:

>> Who said this, and where? I am not aware of such a discussion.

> These are just plans:
> 
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017561.html
> 
> -------- Original Message --------
> Subject: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
> Date: Thu, 31 Mar 2005 09:55:42 -0600
> From: Jon Loeliger <jdl@freescale.com>
> 
> <snip>
> 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.)
> -------- End Original Message --------

The magic bit will be when we have automatic SYSTEM.MHS -> FlatOF BLOB 
on stuff like Virtex. That'll assist in doing away with the HAL :-)

Jon.

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

[Andrei Konovalov]

Wolfgang Denk wrote:
> In message <42511D55.4040507@ru.mvista.com> you wrote:
> 
>>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?
> 
> 
> Who said this, and where? I am not aware of such a discussion.

These are just plans:

http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017561.html

-------- Original Message --------
Subject: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Date: Thu, 31 Mar 2005 09:55:42 -0600
From: Jon Loeliger <jdl@freescale.com>

<snip>
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.)
-------- End Original Message --------

Thanks,
Andrei

> Best regards,
> 
> Wolfgang Denk
> 

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

[Tom Rini]

On Mon, Apr 04, 2005 at 02:56:21PM +0400, Andrei Konovalov wrote:

> 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

It shouldn't matter who passes the flattened tree really, so long as the
information is correct.  arch/ppc/boot/simple/ should translate
older-non-uboot-bd_t, or PReP residual, or statically construct, or
some combination, into the tree and pass it in.  U-Boot (or yaboot or
grub or whatever) can just pass it right to the kernel.

Part of the point of this is to move to a defined interface :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

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

[Jon Loeliger]

On Thu, 2005-04-07 at 12:20, Tom Rini wrote:
> Part of the point of this is to move to a defined interface :)

I've extracted a defined interface for the _current_ bd_t
structure so far.  I'm telling you, you're not going to
like it... :-)

So what do you want to do with it?  Specifically, my tree
is in this state:

    - I have made two files, a .c and a .h that contain
      essentially a grand-union of all of the bd_t and 
      board_info structure definitions that I could find.

    - I have introduced shim function definitions that are
      simple accessor functions to front the common structure
      definition.

It is semi gross in that this file contains a plethora of
#ifdef messes that span multiple PPC32 boards and architectures.
Whereas these used to be nicely distributed (:-)) they are
all gathered into one place that clearly demonstrates a 
few things:

    - This is wrong and needs to be cleaned up more :-),

    - Obvious refactoring for common functionality that
      is NOT board-specific is still needed,

    - There are 51 unique fields in all the bd_t defs.

I am currently proving that various platforms still build.
I'm not going to be able to run-test any boards except
a limited few.

I will happily supply a diff of my messings to the list or
a few individuals who want it.

jdl

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

[Tom Rini]

On Thu, Apr 07, 2005 at 12:35:51PM -0500, Jon Loeliger wrote:
> On Thu, 2005-04-07 at 12:20, Tom Rini wrote:
> > Part of the point of this is to move to a defined interface :)
> 
> I've extracted a defined interface for the _current_ bd_t
> structure so far.  I'm telling you, you're not going to
> like it... :-)
> 
> So what do you want to do with it?  Specifically, my tree
> is in this state:
> 
>     - I have made two files, a .c and a .h that contain
>       essentially a grand-union of all of the bd_t and 
>       board_info structure definitions that I could find.
> 
>     - I have introduced shim function definitions that are
>       simple accessor functions to front the common structure
>       definition.

It sounds like a start certainly.

> It is semi gross in that this file contains a plethora of
> #ifdef messes that span multiple PPC32 boards and architectures.
> Whereas these used to be nicely distributed (:-)) they are
> all gathered into one place that clearly demonstrates a 
> few things:
> 
>     - This is wrong and needs to be cleaned up more :-),
> 
>     - Obvious refactoring for common functionality that
>       is NOT board-specific is still needed,
> 
>     - There are 51 unique fields in all the bd_t defs.

The vauge idea was that we would contruct the flattened tree, somehow
along the lines of
cat totally_common.txt > tree.txt
cat cpu_specific.txt >> tree.txt
cat board_specific.txt >> tree.txt
... autogen a header, or whatever ...

But basically yes, we should and must refactor things a bit so that,
ideally, a new 440GX-based platform would just need to supply its own
board_specific.txt (or whatever) and get the rest of the truely common
bits easily.

And ideally, a lot of the generation code can be shared between
kernel/U-Boot/whatever.

> I am currently proving that various platforms still build.
> I'm not going to be able to run-test any boards except
> a limited few.
> 
> I will happily supply a diff of my messings to the list or
> a few individuals who want it.

Please post to the list as an RFC.  Thanks.

-- 
Tom Rini
http://gate.crashing.org/~trini/

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

[Jon Loeliger]

On Thu, 2005-04-07 at 12:49, Tom Rini wrote:

> Please post to the list as an RFC.  Thanks.

Folks,

Apologies to those who have received this notice twice.
I first sent it to the list where it was summarily
denied for size reasons.

I have now posted a tgz file here instead:

    http://www.jdl.com/bdt_cleanup.tgz

What follows is my original email content.


OK, for those keeping score over on the U-Boot list, _this_
message is really intended to be sent to the public list. :-)

Here (as noted above) are my diffs against a clone of
    http://linux.bkbits.net/linux-2.6
as last pulled a couple days ago. (*)

Please consider this a Request For Comments for now.  Feel free
to apply it and test it out as well, of course. :-)  I'll sign-off
on it when it has ripened some more and gets a nod or two...

These changes relocate almost all of the ppcboot.h definitions
into new files, arc/ppc/syslib/fw_bdt.[ch] and front them
with a new, shim interface in include/asm-ppc/firmware.h.

There is a Kconfig option that allows you to select between
a "bd_t" interface and a non-existant "OF Flat dev tree"
interface.  Choose wisely (default) for now.  It adds the
new fw_bdt.o file.

Some potential gotchas or points to note:

- As of this patch, no interface to any board should change.
  This just isolates the scattered bd_t references to one place.

- On Kumar's advice arch/ppc/boot/simple was totally ignored.
  For now; this round.  It can be next on the hit parade easily.
  It holds the last reference to ppcboot.h still.

- Earlier cut-n-paste of some devices led to me changing a few
  files over in 68k land to remove some now-obsolete ppcboot.h
  related comments justs for completeness.

- I've compiled uImage using defconfigs for the following boards:

        8560_ads        cpci690         ash             redwood5
        8540_ads        ads_8272        TQM8260         est8260
        rpx8260         bseip           mbx             mpc834x_sys
        ocotea          lite5200        hdpu            lopec
        TQM860L         rpxlite         radstone_ppc7d  walnut

- The file include/asm-ppc/ppcboot.h used to contain a nested
  include of linux/types.h that was tacitly used by many files.
  In ripping ppcboot.h out of many platform .h files, I've had
  to add direct #include <linux/types.h> in several places.
  If your board isn't listed above and it looks really broken,
  consider if it needs a <linux/types.h>?


Enjoy,
jdl

--
(*) -- BK is dead.  Long live BK!

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

[Jakob Viketoft]

Has any more happened on this off-list, or it is just in testing-mode 
right now?

I applied the changes to a 2.6.12-rc2 tree (with some minor rejects to 
sort out) and it compiles and boots fine on my Memec FF1152 board with 
the Virtex-II Pro chip (Xilinx ML300 config).

A couple of small changes to be able to use the simple boot-loader is below.

Cheers!

	/Jakob

diff -ruN org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c 
nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c
--- org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c 
2005-04-04 18:38:03.000000000 +0200
+++ nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c 
2005-04-14 11:36:49.000000000 +0200
@@ -23,6 +23,8 @@
  #endif
  extern unsigned long timebase_period_ns;

+#include <syslib/fw_bdt.h>
+
  /* For those boards that don't provide one.
  */
  #if !defined(CONFIG_MBX)
@@ -776,8 +778,7 @@
         bd->bi_intfreq = XPAR_CORE_CLOCK_FREQ_HZ;
         bd->bi_busfreq = XPAR_PLB_CLOCK_FREQ_HZ;
         bd->bi_pci_busfreq = XPAR_PCI_0_CLOCK_FREQ_HZ;
-       timebase_period_ns = 1000000000 / bd->bi_tbfreq;
-       /* see bi_tbfreq definition in 
arch/ppc/platforms/4xx/xilinx_ml300.h */
+       timebase_period_ns = 1000000000 / bd->bi_intfreq;
  }
  #endif /* CONFIG_XILINX_ML300 */

diff -ruN org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c 
nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c
--- org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c 
2005-04-04 18:38:04.000000000 +0200
+++ nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c 
2005-04-14 10:22:38.000000000 +0200
@@ -22,6 +22,7 @@
  #endif

  #include "nonstdio.h"
+#include <syslib/fw_bdt.h>

  /* The linker tells us where the image is. */
  extern char __image_begin, __image_end;


Jon Loeliger wrote:
> On Thu, 2005-04-07 at 12:49, Tom Rini wrote:
> 
> 
>>Please post to the list as an RFC.  Thanks.
> 
> 
> Folks,
> 
> Apologies to those who have received this notice twice.
> I first sent it to the list where it was summarily
> denied for size reasons.
> 
> I have now posted a tgz file here instead:
> 
>     http://www.jdl.com/bdt_cleanup.tgz
> 
> What follows is my original email content.
> 
> 
> OK, for those keeping score over on the U-Boot list, _this_
> message is really intended to be sent to the public list. :-)
> 
> Here (as noted above) are my diffs against a clone of
>     http://linux.bkbits.net/linux-2.6
> as last pulled a couple days ago. (*)
> 
> Please consider this a Request For Comments for now.  Feel free
> to apply it and test it out as well, of course. :-)  I'll sign-off
> on it when it has ripened some more and gets a nod or two...
> 
> These changes relocate almost all of the ppcboot.h definitions
> into new files, arc/ppc/syslib/fw_bdt.[ch] and front them
> with a new, shim interface in include/asm-ppc/firmware.h.
> 
> There is a Kconfig option that allows you to select between
> a "bd_t" interface and a non-existant "OF Flat dev tree"
> interface.  Choose wisely (default) for now.  It adds the
> new fw_bdt.o file.
> 
> Some potential gotchas or points to note:
> 
> - As of this patch, no interface to any board should change.
>   This just isolates the scattered bd_t references to one place.
> 
> - On Kumar's advice arch/ppc/boot/simple was totally ignored.
>   For now; this round.  It can be next on the hit parade easily.
>   It holds the last reference to ppcboot.h still.
> 
> - Earlier cut-n-paste of some devices led to me changing a few
>   files over in 68k land to remove some now-obsolete ppcboot.h
>   related comments justs for completeness.
> 
> - I've compiled uImage using defconfigs for the following boards:
> 
>         8560_ads        cpci690         ash             redwood5
>         8540_ads        ads_8272        TQM8260         est8260
>         rpx8260         bseip           mbx             mpc834x_sys
>         ocotea          lite5200        hdpu            lopec
>         TQM860L         rpxlite         radstone_ppc7d  walnut
> 
> - The file include/asm-ppc/ppcboot.h used to contain a nested
>   include of linux/types.h that was tacitly used by many files.
>   In ripping ppcboot.h out of many platform .h files, I've had
>   to add direct #include <linux/types.h> in several places.
>   If your board isn't listed above and it looks really broken,
>   consider if it needs a <linux/types.h>?
> 
> 
> Enjoy,
> jdl
> 
> --
> (*) -- BK is dead.  Long live BK!
> 

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

[Jon Loeliger]

On Thu, 2005-04-14 at 04:54, Jakob Viketoft wrote:
> Has any more happened on this off-list,

Not by me.  A couple folks are also known to be on vacation.

>  or it is just in testing-mode right now?

likely.  Still waiting for feedback such as yours!  (Thanks!)

> I applied the changes to a 2.6.12-rc2 tree (with some minor rejects to 
> sort out) and it compiles and boots fine on my Memec FF1152 board with 
> the Virtex-II Pro chip (Xilinx ML300 config).

Excellent.

> A couple of small changes to be able to use the simple boot-loader is below.

I'll add these to my mix!

Thanks,
jdl

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

[Andrei Konovalov]

Hi,

I've tested the Jon's patch with the changes by Jakob on ML300 board
couple days ago (just before 2.6.12-rc3) - works OK.
(got few rejects for some lite5200 files)

Thanks,
Andrei

Jakob Viketoft wrote:
> Has any more happened on this off-list, or it is just in testing-mode 
> right now?
> 
> I applied the changes to a 2.6.12-rc2 tree (with some minor rejects to 
> sort out) and it compiles and boots fine on my Memec FF1152 board with 
> the Virtex-II Pro chip (Xilinx ML300 config).
> 
> A couple of small changes to be able to use the simple boot-loader is 
> below.
> 
> Cheers!
> 
>     /Jakob
> 
> diff -ruN org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c 
> nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c
> --- org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c 
> 2005-04-04 18:38:03.000000000 +0200
> +++ nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c 2005-04-14 
> 11:36:49.000000000 +0200
> @@ -23,6 +23,8 @@
>  #endif
>  extern unsigned long timebase_period_ns;
> 
> +#include <syslib/fw_bdt.h>
> +
>  /* For those boards that don't provide one.
>  */
>  #if !defined(CONFIG_MBX)
> @@ -776,8 +778,7 @@
>         bd->bi_intfreq = XPAR_CORE_CLOCK_FREQ_HZ;
>         bd->bi_busfreq = XPAR_PLB_CLOCK_FREQ_HZ;
>         bd->bi_pci_busfreq = XPAR_PCI_0_CLOCK_FREQ_HZ;
> -       timebase_period_ns = 1000000000 / bd->bi_tbfreq;
> -       /* see bi_tbfreq definition in 
> arch/ppc/platforms/4xx/xilinx_ml300.h */
> +       timebase_period_ns = 1000000000 / bd->bi_intfreq;
>  }
>  #endif /* CONFIG_XILINX_ML300 */
> 
> diff -ruN org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c 
> nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c
> --- org-nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c 
> 2005-04-04 18:38:04.000000000 +0200
> +++ nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/misc-embedded.c 
> 2005-04-14 10:22:38.000000000 +0200
> @@ -22,6 +22,7 @@
>  #endif
> 
>  #include "nonstdio.h"
> +#include <syslib/fw_bdt.h>
> 
>  /* The linker tells us where the image is. */
>  extern char __image_begin, __image_end;
> 
> 
> Jon Loeliger wrote:
> 
>> On Thu, 2005-04-07 at 12:49, Tom Rini wrote:
>>
>>
>>> Please post to the list as an RFC.  Thanks.
>>
>>
>>
>> Folks,
>>
>> Apologies to those who have received this notice twice.
>> I first sent it to the list where it was summarily
>> denied for size reasons.
>>
>> I have now posted a tgz file here instead:
>>
>>     http://www.jdl.com/bdt_cleanup.tgz
>>
>> What follows is my original email content.
>>
>>
>> OK, for those keeping score over on the U-Boot list, _this_
>> message is really intended to be sent to the public list. :-)
>>
>> Here (as noted above) are my diffs against a clone of
>>     http://linux.bkbits.net/linux-2.6
>> as last pulled a couple days ago. (*)
>>
>> Please consider this a Request For Comments for now.  Feel free
>> to apply it and test it out as well, of course. :-)  I'll sign-off
>> on it when it has ripened some more and gets a nod or two...
>>
>> These changes relocate almost all of the ppcboot.h definitions
>> into new files, arc/ppc/syslib/fw_bdt.[ch] and front them
>> with a new, shim interface in include/asm-ppc/firmware.h.
>>
>> There is a Kconfig option that allows you to select between
>> a "bd_t" interface and a non-existant "OF Flat dev tree"
>> interface.  Choose wisely (default) for now.  It adds the
>> new fw_bdt.o file.
>>
>> Some potential gotchas or points to note:
>>
>> - As of this patch, no interface to any board should change.
>>   This just isolates the scattered bd_t references to one place.
>>
>> - On Kumar's advice arch/ppc/boot/simple was totally ignored.
>>   For now; this round.  It can be next on the hit parade easily.
>>   It holds the last reference to ppcboot.h still.
>>
>> - Earlier cut-n-paste of some devices led to me changing a few
>>   files over in 68k land to remove some now-obsolete ppcboot.h
>>   related comments justs for completeness.
>>
>> - I've compiled uImage using defconfigs for the following boards:
>>
>>         8560_ads        cpci690         ash             redwood5
>>         8540_ads        ads_8272        TQM8260         est8260
>>         rpx8260         bseip           mbx             mpc834x_sys
>>         ocotea          lite5200        hdpu            lopec
>>         TQM860L         rpxlite         radstone_ppc7d  walnut
>>
>> - The file include/asm-ppc/ppcboot.h used to contain a nested
>>   include of linux/types.h that was tacitly used by many files.
>>   In ripping ppcboot.h out of many platform .h files, I've had
>>   to add direct #include <linux/types.h> in several places.
>>   If your board isn't listed above and it looks really broken,
>>   consider if it needs a <linux/types.h>?
>>
>>
>> Enjoy,
>> jdl
>>
>> -- 
>> (*) -- BK is dead.  Long live BK!
>>
> 
>