[U-Boot-Users] [PATCH] Fix PCI I/O space mapping on Freescale MPC85x0ADS
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)
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,
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
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
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
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
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
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
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
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
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
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.
participants (5)
-
Sergei Shtylyov -
Timur Tabi -
Tolunay Orkun -
Wolfgang Denk -
York Sun