[U-Boot-Users] [PATCH] Fix PCI I/O space mapping on Freescale MPC85x0ADS

[U-Boot-Users] [PATCH] Fix PCI I/O space mapping on Freescale MPC85x0ADS

[Sergei Shtylyov]

The PCI I/O space mapping for Freescale MPC8540ADS board was broken by commit
52c7a68b8d587ebcf5a6b051b58b3d3ffa377ddc which failed to update the #define's
describing the local address window used for the PCI I/O space accesses -- fix
this and carry over the necessary changes into the MPC8560ADS code since the
PCI I/O space mapping was also broken for this board (by the earlier commit
087454609e47295443af793a282cddcd91a5f49c).  Add the comments clarifying how
the PCI I/O space must be mapped to all the MPC85xx board config. headers.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

 board/mpc8540ads/init.S      |    4 ++--
 board/mpc8560ads/init.S      |    4 ++--
 include/configs/MPC8540ADS.h |    5 ++---
 include/configs/MPC8541CDS.h |    2 +-
 include/configs/MPC8548CDS.h |    2 +-
 include/configs/MPC8560ADS.h |    8 ++++----
 6 files changed, 12 insertions(+), 13 deletions(-)

Index: u-boot/board/mpc8540ads/init.S
===================================================================
--- u-boot.orig/board/mpc8540ads/init.S
+++ u-boot/board/mpc8540ads/init.S
@@ -260,8 +260,8 @@ tlb1_entry:
 #define LAWBAR2 ((CFG_LBC_SDRAM_BASE>>12) & 0xfffff)
 #define LAWAR2	(LAWAR_EN | LAWAR_TRGT_IF_LBC | (LAWAR_SIZE & LAWAR_SIZE_256M))
 
-#define LAWBAR3 ((CFG_PCI1_IO_BASE>>12) & 0xfffff)
-#define LAWAR3	(LAWAR_EN | LAWAR_TRGT_IF_PCIX | (LAWAR_SIZE & LAWAR_SIZE_16M))
+#define LAWBAR3 ((CFG_PCI1_IO_PHYS>>12) & 0xfffff)
+#define LAWAR3	(LAWAR_EN | LAWAR_TRGT_IF_PCIX | (LAWAR_SIZE & LAWAR_SIZE_1M))
 
 /*
  * Rapid IO at 0xc000_0000 for 512 M
Index: u-boot/board/mpc8560ads/init.S
===================================================================
--- u-boot.orig/board/mpc8560ads/init.S
+++ u-boot/board/mpc8560ads/init.S
@@ -260,8 +260,8 @@ tlb1_entry:
 #define LAWBAR2 ((CFG_LBC_SDRAM_BASE>>12) & 0xfffff)
 #define LAWAR2	(LAWAR_EN | LAWAR_TRGT_IF_LBC | (LAWAR_SIZE & LAWAR_SIZE_256M))
 
-#define LAWBAR3 ((CFG_PCI1_IO_BASE>>12) & 0xfffff)
-#define LAWAR3	(LAWAR_EN | LAWAR_TRGT_IF_PCIX | (LAWAR_SIZE & LAWAR_SIZE_16M))
+#define LAWBAR3 ((CFG_PCI1_IO_PHYS>>12) & 0xfffff)
+#define LAWAR3	(LAWAR_EN | LAWAR_TRGT_IF_PCIX | (LAWAR_SIZE & LAWAR_SIZE_1M))
 
 /*
  * Rapid IO at 0xc000_0000 for 512 M
Index: u-boot/include/configs/MPC8540ADS.h
===================================================================
--- u-boot.orig/include/configs/MPC8540ADS.h
+++ u-boot/include/configs/MPC8540ADS.h
@@ -330,13 +330,12 @@
 
 /*
  * General PCI
- * Addresses are mapped 1-1.
+ * Memory space is mapped 1-1, but I/O space must start from 0.
  */
 #define CFG_PCI1_MEM_BASE	0x80000000
 #define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
 #define CFG_PCI1_MEM_SIZE	0x20000000	/* 512M */
-
-#define CFG_PCI1_IO_BASE	0x0
+#define CFG_PCI1_IO_BASE	0x00000000
 #define CFG_PCI1_IO_PHYS	0xe2000000
 #define CFG_PCI1_IO_SIZE	0x100000	/* 1M */
 
Index: u-boot/include/configs/MPC8541CDS.h
===================================================================
--- u-boot.orig/include/configs/MPC8541CDS.h
+++ u-boot/include/configs/MPC8541CDS.h
@@ -334,7 +334,7 @@ extern unsigned long get_clock_freq(void
 
 /*
  * General PCI
- * Addresses are mapped 1-1.
+ * Memory space is mapped 1-1, but I/O space must start from 0.
  */
 #define CFG_PCI1_MEM_BASE	0x80000000
 #define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
Index: u-boot/include/configs/MPC8548CDS.h
===================================================================
--- u-boot.orig/include/configs/MPC8548CDS.h
+++ u-boot/include/configs/MPC8548CDS.h
@@ -340,7 +340,7 @@ extern unsigned long get_clock_freq(void
 
 /*
  * General PCI
- * Addresses are mapped 1-1.
+ * Memory space is mapped 1-1, but I/O space must start from 0.
  */
 #define CFG_PCI1_MEM_BASE	0x80000000
 #define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
Index: u-boot/include/configs/MPC8560ADS.h
===================================================================
--- u-boot.orig/include/configs/MPC8560ADS.h
+++ u-boot/include/configs/MPC8560ADS.h
@@ -320,14 +320,14 @@
 
 /*
  * General PCI
- * Addresses are mapped 1-1.
+ * Memory space is mapped 1-1, but I/O space must start from 0.
  */
 #define CFG_PCI1_MEM_BASE	0x80000000
 #define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
 #define CFG_PCI1_MEM_SIZE	0x20000000	/* 512M */
-#define CFG_PCI1_IO_BASE	0xe2000000
-#define CFG_PCI1_IO_PHYS	CFG_PCI1_IO_BASE
-#define CFG_PCI1_IO_SIZE	0x1000000	/* 16M */
+#define CFG_PCI1_IO_BASE	0x00000000
+#define CFG_PCI1_IO_PHYS	0xe2000000
+#define CFG_PCI1_IO_SIZE	0x100000	/* 1M */
 
 #if defined(CONFIG_PCI)
 

[U-Boot-Users] PCI MEM I/O space allocation

[York Sun]

Wolfgang,

I noticed in U-boot 1.1.6, PCI resources (MEM, I/O) are allocated from
bottom up. Is there any reason not to allocate from top down? Linux
kernel is allocating from top down.

Regards,


-- 
York Sun
 
This email, and any associated attachments have been classified as:
[x] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary

[U-Boot-Users] PCI MEM I/O space allocation

[Wolfgang Denk]

In message <1168292412.2883.6.camel@localhost.localdomain> you wrote:
> 
> I noticed in U-boot 1.1.6, PCI resources (MEM, I/O) are allocated from
> bottom up. Is there any reason not to allocate from top down? Linux
> kernel is allocating from top down.

Ummm... I can't tell. Why are you asking? TMTOWTDI...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Nobody will ever need more than 640k RAM!"       -- Bill Gates, 1981
"Windows 95 needs at least 8 MB RAM."             -- Bill Gates, 1996
"Nobody will ever need Windows 95."             -- logical conclusion

[U-Boot-Users] PCI MEM I/O space allocation

[York Sun]

> In message <1168292412.2883.6.camel@localhost.localdomain> you wrote:
> > 
> > I noticed in U-boot 1.1.6, PCI resources (MEM, I/O) are allocated from
> > bottom up. Is there any reason not to allocate from top down? Linux
> > kernel is allocating from top down.
> 
> Ummm... I can't tell. Why are you asking? TMTOWTDI...

I am trying to fix the resource allocation bugs, but found things
unexpected. I want to know if there is particular reason to allocate
from bottom up. If not, I would change it back to kernel's way.

York

[U-Boot-Users] PCI MEM I/O space allocation

[Wolfgang Denk]

In message <1168297700.2883.18.camel@localhost.localdomain> you wrote:
>
> I am trying to fix the resource allocation bugs, but found things
> unexpected. I want to know if there is particular reason to allocate
> from bottom up. If not, I would change it back to kernel's way.

What do you mean by "change it back"?

When has this been changed before?

You are aware that you will cause LOT  of  regression  testings  with
such a change?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
                                              - Franklin D. Roosevelt

[U-Boot-Users] PCI MEM I/O space allocation

[York Sun]

On Tue, 2007-01-09 at 01:55 +0100, Wolfgang Denk wrote:
> In message <1168297700.2883.18.camel@localhost.localdomain> you wrote:
> >
> > I am trying to fix the resource allocation bugs, but found things
> > unexpected. I want to know if there is particular reason to allocate
> > from bottom up. If not, I would change it back to kernel's way.
> 
> What do you mean by "change it back"?

To allocate resources from the top.

> When has this been changed before?

There isn't one. I mean back to kernel's way. Why should U-boot use
different way from kernel to allocate resources since most PCI parts are
similar (equivalent) to kernel?

> 
> You are aware that you will cause LOT  of  regression  testings  with
> such a change?

Yes, I know. Hopefully  not too much. This change will only change the
allocation direction. Once U-boot has same algorithm with kernel, it is
easier to maintain in the future.

Regards,

York

[U-Boot-Users] PCI MEM I/O space allocation

[Wolfgang Denk]

In message <1168355764.2903.10.camel@localhost.localdomain> you wrote:
>
> > What do you mean by "change it back"?
> 
> To allocate resources from the top.
> 
> > When has this been changed before?
> 
> There isn't one. I mean back to kernel's way. Why should U-boot use
> different way from kernel to allocate resources since most PCI parts are
> similar (equivalent) to kernel?

This is not a change "back" then, as we never used this setup before.

> > You are aware that you will cause LOT  of  regression  testings  with
> > such a change?
> 
> Yes, I know. Hopefully  not too much. This change will only change the

I think such a change affects about 128 boards...

*ALL* of these need thorough regression testing after such a
significant change.

I wouldn't do this lightly...

> allocation direction. Once U-boot has same algorithm with kernel, it is
> easier to maintain in the future.

What exactly is the problem you're trying to fix? The fact that it's
different is IMHO not enough of a reason to change it.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Extended Epstein-Heisenberg Principle: In an R & D orbit, only  2  of
the  existing 3 parameters can be defined simultaneously. The parame-
ters are: task, time and resources ($).

[U-Boot-Users] PCI MEM I/O space allocation

[York Sun]

On Tue, 2007-01-09 at 16:48 +0100, Wolfgang Denk wrote:
> > There isn't one. I mean back to kernel's way. Why should U-boot use
> > different way from kernel to allocate resources since most PCI parts are
> > similar (equivalent) to kernel?
> 
> This is not a change "back" then, as we never used this setup before.
> 
> > Yes, I know. Hopefully  not too much. This change will only change the
> 
> I think such a change affects about 128 boards...
> 
> *ALL* of these need thorough regression testing after such a
> significant change.
> 
> I wouldn't do this lightly...

All right. I will do it in my branch and not to submit patch for this.

> 
> > allocation direction. Once U-boot has same algorithm with kernel, it is
> > easier to maintain in the future.
> 
> What exactly is the problem you're trying to fix? The fact that it's
> different is IMHO not enough of a reason to change it.

The problem is some bridges have 64K limitation on I/O space, which
requires special care in allocation. I am fixing it in the kernel.

Regards,

York

[U-Boot-Users] PCI MEM I/O space allocation

[Wolfgang Denk]

In message <1168358761.2903.19.camel@localhost.localdomain> you wrote:
>
> > I wouldn't do this lightly...
> 
> All right. I will do it in my branch and not to submit patch for this.

This is definitely not the result I wanted to acchieve :-(

> > What exactly is the problem you're trying to fix? The fact that it's
> > different is IMHO not enough of a reason to change it.
> 
> The problem is some bridges have 64K limitation on I/O space, which
> requires special care in allocation. I am fixing it in the kernel.

Maybe we can make this optional, so we can leave  unaffected  systems
untouched, and/or give board maintainers time for a slower migration?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sometimes, too long is too long.                          - Joe Crowe

[U-Boot-Users] PCI MEM I/O space allocation

[York Sun]

On Tue, 2007-01-09 at 17:39 +0100, Wolfgang Denk wrote:
> In message <1168358761.2903.19.camel@localhost.localdomain> you wrote:
> >
> > > I wouldn't do this lightly...
> > 
> > All right. I will do it in my branch and not to submit patch for this.
> 
> This is definitely not the result I wanted to acchieve :-(

My first attempt was to find out if there was a particular reason to
allocate from bottom up. If changing it causes too much trouble, we can
keep it there until really necessary.

> 
> > > What exactly is the problem you're trying to fix? The fact that it's
> > > different is IMHO not enough of a reason to change it.
> > 
> > The problem is some bridges have 64K limitation on I/O space, which
> > requires special care in allocation. I am fixing it in the kernel.
> 
> Maybe we can make this optional, so we can leave  unaffected  systems
> untouched, and/or give board maintainers time for a slower migration?

We can leave it untouched until all the fixing is done. We will decide
from there.

Regards,

York

[U-Boot-Users] PCI MEM I/O space allocation

[Timur Tabi]

Wolfgang Denk wrote:

> Maybe we can make this optional, so we can leave  unaffected  systems
> untouched, and/or give board maintainers time for a slower migration?

That's probably a good idea.  York, let's see what your patch looks like, and 
maybe we can incorporate it into U-Boot in clean manner.  I don't know a whole 
lot about PCI, but just from this thread, it's possible that the change your 
proposing is something that needs to be available in U-Boot.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] PCI MEM I/O space allocation

[Tolunay Orkun]

York Sun wrote:
>>>> What exactly is the problem you're trying to fix? The fact that it's
>>>> different is IMHO not enough of a reason to change it.
>>>>         
>>> The problem is some bridges have 64K limitation on I/O space, which
>>> requires special care in allocation. I am fixing it in the kernel.
>>>       

May I remined that U-Boot is not solely booting Linux kernel while Linux 
is probably the most popular one. How will such change affect other OS 
booting?

Tolunay