Platform bus/ppc sys model...
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
Hi,
Quoted 3 lines
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 ;)
Quoted 3 lines
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
Quoted 2 lines
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.
Quoted 8 lines · Sylvain Munaut
Hi,
Quoted 3 lines
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?
Quoted 7 lines
I'm not aware on documentation for the
ppc_sysmodel 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
Quoted 25 lines
Quoted 3 lines
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 structplatform_devicewith the name field in structdevice_driver. The code for this magic is indrivers/base/platform.cQuoted 2 lines
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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Quoted 13 lines · Andrei Konovalov
Quoted 4 lines · Sylvain Munaut
Hi,
Quoted 1 line
Is there some good documentation about how to use the platform bus=20=
/ ppc
Quoted 1 line
Quoted 1 line
sys model or is it only possible to read and try to understand the=20=
code
Quoted 3 lines
Quoted 1 line
for the freescale devices?
Quoted 11 lines
Quoted 1 line
I'm not aware on documentation for the
ppc_sysmodel in particular=20=but
Quoted 3 lines
the code is pretty easy to understand/read.
Basically you have a ???_devices.c that describe all the devices you=20=
can
Quoted 3 lines
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
Quoted 4 lines
Quoted 1 line
are really implemented in that variant). Then somewhere in platform=20=
init
Quoted 1 line
code, you need to identify the ppc system=A0 you're runngin on ( by =
a
Quoted 3 lines
Quoted 3 lines
identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).
Kumar, if I got it wrong, please correct ;)
thats a pretty fair description.
Quoted 15 lines
Do I understand correct that the
ppc_sysmodel 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=
Quoted 6 lines
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
Quoted 16 lines · Kumar Gala
Quoted 5 lines · Andrei Konovalov
Do I understand correct that the
ppc_sysmodel 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.Quoted 8 lines
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.
Quoted 3 lines
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
Quoted 7 lines
My intention was to give a device tree structure to the kernel at boot time via a (pseudo?) pointer in
bd_infoor 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?
Quoted 6 lines
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
-----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...]
Quoted 6 lines · Jon Masters
Kumar Gala wrote:
|> My intention was to give a device tree structure to the kernel at boot |> time via a (pseudo?) pointer in
bd_infoor similar.This got resurrected recently.
Hi!
Quoted 6 lines
| 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...]
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
Quoted 71 lines · Jon Loeliger
Quoted 7 lines · Jon Masters
Kumar Gala wrote:
|> My intention was to give a device tree structure to the kernel at boot |> time via a (pseudo?) pointer in
bd_infoor similar.This got resurrected recently.
Hi!
Quoted 6 lines
| 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_tstructure 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_tdata.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...]
-----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...]
In reply to Jakob ViketoftHi 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
Quoted 88 lines · 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
Quoted 74 lines · Jon Loeliger
Quoted 8 lines · Jon Masters
Kumar Gala wrote:
|> My intention was to give a device tree structure to the kernel at boot |> time via a (pseudo?) pointer in
bd_infoor similar.This got resurrected recently.
Hi!
Quoted 6 lines
| 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_tstructure 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_tdata.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...]
Quoted 2 lines · Andrei Konovalov
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.
Quoted 1 line
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 :-)
Quoted 1 line
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! :-)
Quoted 3 lines
Anyone using
arch/ppc/boot/simplebootwrapper with his Virtex 2 Pro board? If we drop Virtex 2 Pro support inarch/ppc/bootand 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...]
In reply to Andrei KonovalovHello Andrei!
Quoted 9 lines · 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).
Great! I could start and ask for assistance when needed... :)
Quoted 9 lines
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/simplebootwrapper with his Virtex 2 Pro board? If we drop Virtex 2 Pro support inarch/ppc/bootand 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
Quoted 95 lines
Quoted 91 lines · 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
Quoted 77 lines · Jon Loeliger
Quoted 9 lines · Jon Masters
Kumar Gala wrote:
|> My intention was to give a device tree structure to the kernel at boot |> time via a (pseudo?) pointer in
bd_infoor similar.This got resurrected recently.
Hi!
Quoted 6 lines
| 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_tstructure 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_tdata.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...]
In reply to Andrei KonovalovQuoted 4 lines · In message <[email protected]> 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
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] "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...]
Quoted 8 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> 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 <[email protected]>
<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
Quoted 4 lines
Best regards,
Wolfgang Denk
Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Quoted 13 lines · Andrei Konovalov
Quoted 1 line · Wolfgang Denk
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 <[email protected]>
Quoted 5 lines
<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...]
In reply to Andrei KonovalovQuoted 2 lines · Andrei Konovalov
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 :)
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Quoted 1 line · Tom Rini
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...]
Quoted 10 lines · Jon Loeliger
Quoted 1 line · Tom Rini
Part of the point of this is to move to a defined interface :)
I've extracted a defined interface for the _current_
bd_tstructure 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:
Quoted 7 lines
- I have made two files, a .c and a .h that contain essentially a grand-union of all of the
bd_tandboard_infostructure 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.
Quoted 6 lines
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:
Quoted 6 lines
- 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_tdefs.
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.
Quoted 6 lines
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.
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Quoted 1 line · Tom Rini
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...]
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
arch/ppc/boot/simple/embed_config.c 2005-04-14 11:36:49.000000000 +0200 renamed from arch/ppc/boot/simple/embed_config.c 2005-04-04 18:38:03.000000000 +0200 +3 -2
@@ -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 */
arch/ppc/boot/simple/misc-embedded.c 2005-04-14 10:22:38.000000000 +0200 renamed from arch/ppc/boot/simple/misc-embedded.c 2005-04-04 18:38:04.000000000 +0200 +1 -0
@@ -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;
Quoted 74 lines · Jon Loeliger
Quoted 1 line · Tom Rini
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.6as 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.hdefinitions into new files, arc/ppc/syslib/fw_bdt.[ch] and front them with a new, shim interface ininclude/asm-ppc/firmware.h.There is a
Kconfigoption 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_treferences to one place.- On Kumar's advice
arch/ppc/boot/simplewas totally ignored. For now; this round. It can be next on the hit parade easily. It holds the last reference toppcboot.hstill.- Earlier cut-n-paste of some devices led to me changing a few files over in 68k land to remove some now-obsolete
ppcboot.hrelated 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.hused to contain a nested include oflinux/types.hthat was tacitly used by many files. In rippingppcboot.hout 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...]
Quoted 1 line · Jakob Viketoft
Has any more happened on this off-list,
Not by me. A couple folks are also known to be on vacation.
Quoted 1 line
or it is just in testing-mode right now?
likely. Still waiting for feedback such as yours! (Thanks!)
Quoted 3 lines
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.
Quoted 1 line
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...]
In reply to Jakob ViketoftHi,
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
Quoted 129 lines · 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.cnobd-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.c2005-04-04 18:38:03.000000000 +0200+++
nobd-linux-2.6.12-rc2/arch/ppc/boot/simple/embed_config.c2005-04-14 11:36:49.000000000 +0200arch/ppc/boot/simple/embed_config.c 2005-04-14 11:36:49.000000000 +0200 renamed from arch/ppc/boot/simple/embed_config.c 2005-04-04 18:38:03.000000000 +0200 +2
-2@@ -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.cnobd-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.c2005-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 +0200arch/ppc/boot/simple/misc-embedded.c 2005-04-14 10:22:38.000000000 +0200 renamed from arch/ppc/boot/simple/misc-embedded.c 2005-04-04 18:38:04.000000000 +0200 +1
-0@@ -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;Quoted 75 lines · Jon Loeliger
Quoted 1 line · Tom Rini
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.6as 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.hdefinitions into new files, arc/ppc/syslib/fw_bdt.[ch] and front them with a new, shim interface ininclude/asm-ppc/firmware.h.There is a
Kconfigoption 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_treferences to one place.- On Kumar's advice
arch/ppc/boot/simplewas totally ignored. For now; this round. It can be next on the hit parade easily. It holds the last reference toppcboot.hstill.- Earlier cut-n-paste of some devices led to me changing a few files over in 68k land to remove some now-obsolete
ppcboot.hrelated 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.hused to contain a nested include oflinux/types.hthat was tacitly used by many files. In rippingppcboot.hout 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,
jdlSignature · 1 line
(*) -- BK is dead. Long live BK!