From: Anton Vorontsov <hidden> Date: 2008-12-29 16:40:42
This patch adds pcie nodes to the appropriate dts files, plus adds
some probing code for the boards.
Note that the nodes are disabled by default (via status property),
since old (community) U-Boots don't configure PCI-E controllers.
Also, remove of_device_is_avaliable() check from the mpc837x_mds.c
board file, as mpc83xx_add_bridge() has the same check now.
Signed-off-by: Anton Vorontsov <redacted>
---
arch/powerpc/boot/dts/mpc8315erdb.dts | 42 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8377_mds.dts | 42 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8377_rdb.dts | 42 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8378_mds.dts | 42 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8378_rdb.dts | 42 +++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/mpc831x_rdb.c | 2 +
arch/powerpc/platforms/83xx/mpc837x_mds.c | 10 ++-----
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 2 +
8 files changed, 217 insertions(+), 7 deletions(-)
for pcie nodes we also include the virtual p2p bridge look at the 85xx
or 86xx .dts w/pcie in them.
(I'm only commenting on this one, assuming the comments replicate to
all other nodes)
- k
From: Anton Vorontsov <hidden> Date: 2008-12-30 20:19:18
This patch adds pcie nodes to the appropriate dts files, plus adds
some probing code for the boards.
Note that the nodes are disabled by default (via status property),
since old (community) U-Boots don't configure PCI-E controllers.
Also, remove of_device_is_avaliable() check from the mpc837x_mds.c
board file, as mpc83xx_add_bridge() has the same check now.
Signed-off-by: Anton Vorontsov <redacted>
---
On Tue, Dec 30, 2008 at 11:46:50AM -0600, Kumar Gala wrote:
[...]
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
I'd rather not pollute the .dts with this since I don't believe the
open source u-boot supports PCIe on 83xx.
- k
From: Wolfgang Denk <hidden> Date: 2008-12-31 17:10:46
Dear Kumar,
In message [off-list ref] you wrote:
quoted
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
I'd rather not pollute the .dts with this since I don't believe the
open source u-boot supports PCIe on 83xx.
What exactly do you mean by "open source u-boot"? You don't really
mean that there are propriatary (closed source) versions of U-Boot in
Freescale, or are you? I iknow that you know that it's GPL, so I
guess that was just an unlucky phrase?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The C-shell doesn't parse. It adhoculates.
- Casper.Dik@Holland.Sun.COM in [off-list ref]
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
I'd rather not pollute the .dts with this
So you prefer to change the cfg window size to 0x1000?
since I don't believe the open
source u-boot supports PCIe on 83xx.
Yes, that's correct. PCI-E support for community U-Boot is ongoing.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Kumar Gala <hidden> Date: 2009-01-01 14:26:43
On Dec 31, 2008, at 11:10 AM, Wolfgang Denk wrote:
Dear Kumar,
In message <1F7739C2-930B-49C1-
B8FF-679AF1BBAEAE@kernel.crashing.org> you wrote:
quoted
quoted
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
I'd rather not pollute the .dts with this since I don't believe the
open source u-boot supports PCIe on 83xx.
What exactly do you mean by "open source u-boot"? You don't really
mean that there are propriatary (closed source) versions of U-Boot in
Freescale, or are you? I iknow that you know that it's GPL, so I
guess that was just an unlucky phrase?
I meant the official u-boot from denx.de vs the one FSL ships w/its
boards & BSPs. The BSP u-boot has modifications that don't exist in
the denx.de u-boot (as the quality of the code is not up to open
source standards).
That is all I meant.
My statement was to convey that the kernel.org kernel should only
worry itself with the denx.de u-boot (w/regards to compatibility).
- k
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
I'd rather not pollute the .dts with this
So you prefer to change the cfg window size to 0x1000?
This is how FSL U-Boots configure the cfg window, and I'm trying to
retain the compatibility. Anyway, now Linux maps only the first 4kB
of that area, so we don't actually care about this, but dts is still
correct for older u-boots. Newer U-Boots might want to correct this
value if they want to use other cfg window setup...
I'd rather not pollute the .dts with this
So you prefer to change the cfg window size to 0x1000?
I'd prefer to drop it (assuming that is reasonable).
I see. Yes, we can drop it and just read the outwin0 BAR register
to find out the cfg space base address.
If I understood correctly, the spec describes directly mapped
cfg space, this won't work for 83xx PCI-E.
I'll post new patches soon.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Scott Wood <hidden> Date: 2009-01-05 17:46:54
On Thu, Jan 01, 2009 at 08:26:14AM -0600, Kumar Gala wrote:
I meant the official u-boot from denx.de vs the one FSL ships w/its
boards & BSPs. The BSP u-boot has modifications that don't exist in
the denx.de u-boot (as the quality of the code is not up to open
source standards).
I believe "upstream" is the word you're looking for.
My statement was to convey that the kernel.org kernel should only
worry itself with the denx.de u-boot (w/regards to compatibility).
Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).
That said, the device tree should come from u-boot, not from the kernel.
-Scott
From: Anton Vorontsov <hidden> Date: 2009-01-05 18:01:24
On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
[...]
quoted
My statement was to convey that the kernel.org kernel should only
worry itself with the denx.de u-boot (w/regards to compatibility).
Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).
Just in case, the latest version of this patch set is compatible with
the FSL u-boots.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Leon Woestenberg <hidden> Date: 2009-01-06 12:19:34
Hello,
On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov
[off-list ref] wrote:
On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
[...]
quoted
quoted
My statement was to convey that the kernel.org kernel should only
worry itself with the denx.de u-boot (w/regards to compatibility).
Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).
From: Leon Woestenberg <hidden> Date: 2009-01-06 18:55:17
Hello Anton,
On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov
[off-list ref] wrote:
On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
quoted
Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).
Just in case, the latest version of this patch set is compatible with
the FSL u-boots.
Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/
That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.
Is u-boot PCIe initialization required for this kernel patch to work?
Regards,
--
Leon
From: Anton Vorontsov <hidden> Date: 2009-01-06 19:27:50
On Tue, Jan 06, 2009 at 07:53:57PM +0100, Leon Woestenberg wrote:
Hello Anton,
On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov
[off-list ref] wrote:
quoted
On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
quoted
Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).
Just in case, the latest version of this patch set is compatible with
the FSL u-boots.
Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/
That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.
Is u-boot PCIe initialization required for this kernel patch to work?
Yup.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Kumar Gala <hidden> Date: 2009-01-06 20:41:35
On Jan 6, 2009, at 1:27 PM, Anton Vorontsov wrote:
On Tue, Jan 06, 2009 at 07:53:57PM +0100, Leon Woestenberg wrote:
quoted
Hello Anton,
On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov
[off-list ref] wrote:
quoted
On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
quoted
Why? Unless the BSP u-boots do something insane, I think we
should try
to have the upstream kernel boot on the u-boot that comes on the
board
(it's not nice to require users to reflash unnecessarily).
Just in case, the latest version of this patch set is compatible
with
the FSL u-boots.
Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/
That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.
Is u-boot PCIe initialization required for this kernel patch to work?
From: Anton Vorontsov <hidden> Date: 2009-01-06 21:15:15
On Tue, Jan 06, 2009 at 02:38:57PM -0600, Kumar Gala wrote:
[...]
quoted
quoted
quoted
quoted
Why? Unless the BSP u-boots do something insane, I think we
should try
to have the upstream kernel boot on the u-boot that comes on the
board
(it's not nice to require users to reflash unnecessarily).
Just in case, the latest version of this patch set is compatible
with
the FSL u-boots.
Up to now, I was testing PCIe with this combo:
- U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board
- dtc 1.1.0
- Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/
That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization.
Is u-boot PCIe initialization required for this kernel patch to work?
Yup.
Really? what for?
Hm. U-Boot should initialize SerDes and PCI-E controller (pcie laws,
inbound/outbound windows, clocks, etc.)
Though if PCI-E controller wasn't initialized (i.e. board reflashed
with the community u-boot), Linux just won't probe the pcie controller:
cfg_bar = in_le32(hose->cfg_data + PEX_OUTWIN0_BAR);
if (!cfg_bar) {
/* PCI-E isn't configured. */
ret = -ENODEV;
goto err1;
}
Or did I misunderstand the question?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Leon Woestenberg <hidden> Date: 2009-01-06 22:34:08
Hello Anton,
On Tue, Jan 6, 2009 at 10:15 PM, Anton Vorontsov
[off-list ref] wrote:
On Tue, Jan 06, 2009 at 02:38:57PM -0600, Kumar Gala wrote:
quoted
quoted
quoted
Is u-boot PCIe initialization required for this kernel patch to work?
Yup.
Really? what for?
Hm. U-Boot should initialize SerDes and PCI-E controller (pcie laws,
inbound/outbound windows, clocks, etc.)
Though if PCI-E controller wasn't initialized (i.e. board reflashed
with the community u-boot), Linux just won't probe the pcie controller:
cfg_bar = in_le32(hose->cfg_data + PEX_OUTWIN0_BAR);
if (!cfg_bar) {
/* PCI-E isn't configured. */
ret = -ENODEV;
goto err1;
}
Or did I misunderstand the question?
You understood correctly, thanks for answering.
So to summarize, we need u-boot to initialize the PCIe controller, in
order for Linux to further take it over.
What u-boot versions/releases do provide this initialization?
I know the u-boot with the board works, but it's incompatible with
recent Linux kernels.
Regards,
--
Leon
From: Anton Vorontsov <hidden> Date: 2009-01-06 23:42:58
On Tue, Jan 06, 2009 at 11:33:35PM +0100, Leon Woestenberg wrote:
Hello Anton,
On Tue, Jan 6, 2009 at 10:15 PM, Anton Vorontsov
[off-list ref] wrote:
quoted
On Tue, Jan 06, 2009 at 02:38:57PM -0600, Kumar Gala wrote:
quoted
quoted
quoted
Is u-boot PCIe initialization required for this kernel patch to work?
Yup.
Really? what for?
Hm. U-Boot should initialize SerDes and PCI-E controller (pcie laws,
inbound/outbound windows, clocks, etc.)
Though if PCI-E controller wasn't initialized (i.e. board reflashed
with the community u-boot), Linux just won't probe the pcie controller:
cfg_bar = in_le32(hose->cfg_data + PEX_OUTWIN0_BAR);
if (!cfg_bar) {
/* PCI-E isn't configured. */
ret = -ENODEV;
goto err1;
}
Or did I misunderstand the question?
You understood correctly, thanks for answering.
So to summarize, we need u-boot to initialize the PCIe controller, in
order for Linux to further take it over.
What u-boot versions/releases do provide this initialization?
Only FSL U-Boots so far (i.e. community u-boot + fsl patches).
I know the u-boot with the board works, but it's incompatible with
recent Linux kernels.
We should fix that (if possible).
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Leon Woestenberg <hidden> Date: 2009-01-07 00:40:57
Hello Anton,
On Wed, Jan 7, 2009 at 12:42 AM, Anton Vorontsov
[off-list ref] wrote:
On Tue, Jan 06, 2009 at 11:33:35PM +0100, Leon Woestenberg wrote:
quoted
So to summarize, we need u-boot to initialize the PCIe controller, in
order for Linux to further take it over.
What u-boot versions/releases do provide this initialization?
Only FSL U-Boots so far (i.e. community u-boot + fsl patches).
Could you be more specific?
I would like to test your Linux kernel patch for 83xx/PCIe mainlining.
What version (and what patches) of u-boot do both initialize pcie
*and* work with recent Linux kernels?
I am aware of the latest MPC8315E BSP (~2008-06), bitshrine.org/gpp/,
the 83xx git tree at denx, and master git.
The first works with 2.6.24, but not with 2.6.25+
The patches at bitshrine are not newer than that.
The tree's are not FSL, or is this the FSL U-Boot you mean?
quoted
I know the u-boot with the board works, but it's incompatible with
recent Linux kernels.
From: Scott Wood <hidden> Date: 2009-01-07 15:43:47
On Tue, Jan 06, 2009 at 01:18:56PM +0100, Leon Woestenberg wrote:
Hello,
On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov
[off-list ref] wrote:
quoted
On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote:
[...]
quoted
quoted
My statement was to convey that the kernel.org kernel should only
worry itself with the denx.de u-boot (w/regards to compatibility).
Why? Unless the BSP u-boots do something insane, I think we should try
to have the upstream kernel boot on the u-boot that comes on the board
(it's not nice to require users to reflash unnecessarily).