PCI stopped working on MPC8343

Last week
my PCI bus has been running fine showing all devices. Right now no devices are shown on the bus.

I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.

Nothing changed from my side during the last 2 weeks.

Did I miss any changes in u-boot ?

regards,
Andre Schwarz
Matrix Vision

Quoted 8 lines · Andre Schwarz

Last week my PCI bus has been running fine showing all devices. Right now no devices are shown on the bus.

I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.

Nothing changed from my side during the last 2 weeks.

Quoted 6 lines

Did I miss any changes in u-boot ?

regards,
Andre Schwarz
Matrix Vision

Hi Andre and everyone,

I was just about to post on I problem I belatedly found with PCI on our Korat PPC400EPx board. (I believe the same problem exists on the Sequoia board, but have not proved it.) What appears to have broken it was the following patch (I got to use "git bisect" for the first time):

<patch>
commit 55774b512fdf63c0516d441cc5da7c54bbffb7f2

Author: Nobuhiro Iwamatsu <[email protected]>
Date:   Fri Mar 7 16:04:25 2008 +0900

pci: Add CONFIG_PCI_SKIP_HOST_BRIDGE config option
In current source code, when the device number of PCI is 0,
process PCI
bridge without fail. However, when the device number is 0, it is not PCI always bridge. There are times when device of PCI allocates.
When CONFIG_PCI_SKIP_HOST_BRIDGE is enable, this problem is solved
when
use this patch.

Signed-off-by Nobuhiro Iwamatsu <[email protected]>

Acked-by Stefan Roese <[email protected]>

drivers/pci/pci.c +3 -0

index 50ca6b0..7944b66 100644
@@ -425,6 +425,9 @@ int pci_hose_scan_bus(struct pci_controller *hose, 
 int bus)
         dev <  PCI_BDF(bus,PCI_MAX_PCI_DEVICES-1,PCI_MAX_PCI_FUNCTIONS-1);
         dev += PCI_BDF(0,0,1))
    {
+
+    /* Bus 0 is not necessarily PCI bridge. */
+#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
        /* Skip our host bridge */
        if ( dev == PCI_BDF(hose->first_busno,0,0) ) {

#if defined(CONFIG_PCI_CONFIG_HOST_BRIDGE) /* don't skip
host bridge */

drivers/pci/pci.c +3 -2

@@ -434,10 +437,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, 
 int bus)
            if (getenv("pciconfighost") == NULL) {
                continue; /* Skip our host bridge */
            }
-#else
+#else /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
            continue; /* Skip our host bridge */
-#endif
+#endif /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
        }
+#endif /* CONFIG_PCI_SKIP_HOST_BRIDGE */
 
        if (PCI_FUNC(dev) && !found_multi)

            continue;

drivers/pci/pci.c +4 -1

@@ -473,8 +477,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, 
 int bus)
                hose->fixup_irq(hose, dev);
 
 #ifdef CONFIG_PCI_SCAN_SHOW
+#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
            /* Skip our host bridge */
-            if ( dev != PCI_BDF(hose->first_busno,0,0) ) {
+            if ( dev != PCI_BDF(hose->first_busno,0,0) )
+#endif
+            {
                unsigned char int_line;
 

pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_LINE,

</patch>

The patch changes the behavior of the code _unless_ CONFIG_PCI_SKIP_HOST_BRIDGE is defined. Defining that switch in the Korat configuration fixes the problem. The MPC8323ERDB configuration has also been patched to add the switch, so maybe this is is the cause of your problem as well.

I was going to submit the patch for Korat, but then decided I'd first like to ask Nobuhiro and the group whether it might not be better to change the occurrences of

#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)

in "drivers/pci/pci.c" to

#if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)

That would allow those boards that need to patch to specify it explicity, while leaving the default functionality unchanged.

Comments?

Best regards,
Larry

Larry,

you're right - but it doesn't fix my problem.

Thanks,
Andr?

Quoted 24 lines · Larry Johnson

Quoted 8 lines · Andre Schwarz

Last week my PCI bus has been running fine showing all devices. Right now no devices are shown on the bus.

I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.

Nothing changed from my side during the last 2 weeks.

Quoted 6 lines

Did I miss any changes in u-boot ?

regards,
Andre Schwarz
Matrix Vision

Hi Andre and everyone,

I was just about to post on I problem I belatedly found with PCI on our Korat PPC400EPx board. (I believe the same problem exists on the Sequoia board, but have not proved it.) What appears to have broken it was the following patch (I got to use "git bisect" for the first time):

<snip>

I was just about to post on I problem I belatedly found with PCI on our Korat PPC400EPx board. (I believe the same problem exists on the Sequoia board, but have not proved it.) What appears to have broken it was the following patch (I got to use "git bisect" for the first time):

<patch>
commit 55774b512fdf63c0516d441cc5da7c54bbffb7f2

Author: Nobuhiro Iwamatsu <[email protected]>
Date:   Fri Mar 7 16:04:25 2008 +0900

pci: Add CONFIG_PCI_SKIP_HOST_BRIDGE config option

The patch changes the behavior of the code _unless_ CONFIG_PCI_SKIP_HOST_BRIDGE is defined. Defining that switch in the Korat configuration fixes the problem. The MPC8323ERDB configuration has also been patched to add the switch, so maybe this is is the cause of your problem as well.

I was going to submit the patch for Korat, but then decided I'd first like to ask Nobuhiro and the group whether it might not be better to change the occurrences of

#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)

in "drivers/pci/pci.c" to

#if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)

That would allow those boards that need to patch to specify it explicity, while leaving the default functionality unchanged.

Comments?

Quoted 19 lines

The patch changes the behavior of the code _unless_ CONFIG_PCI_SKIP_HOST_BRIDGE is defined. Defining that switch in the Korat configuration fixes the problem. The MPC8323ERDB configuration has also been patched to add the switch, so maybe this is is the cause of your problem as well.

I was going to submit the patch for Korat, but then decided I'd first like to ask Nobuhiro and the group whether it might not be better to change the occurrences of

#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)

in "drivers/pci/pci.c" to

#if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)

That would allow those boards that need to patch to specify it explicity, while leaving the default functionality unchanged.

Quoted 1 line

Comments?

Yes, I totally agree. Patches should *not* change the default behavior. We should change it as you suggested. Sorry, I must have missed this.

Nobuhiro, could you please send a new patch to fix this problem?

Hi, all.

Sorry for the delay.

Quoted 16 lines · On Fri, 18 Apr 2008 16:57:15 +0200 Stefan Roese <[email protected]> wrote:

Quoted 16 lines

The patch changes the behavior of the code _unless_ CONFIG_PCI_SKIP_HOST_BRIDGE is defined. Defining that switch in the Korat configuration fixes the problem. The MPC8323ERDB configuration has also been patched to add the switch, so maybe this is is the cause of your problem as well.

I was going to submit the patch for Korat, but then decided I'd first like to ask Nobuhiro and the group whether it might not be better to change the occurrences of

#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)

in "drivers/pci/pci.c" to

#if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)

Quoted 8 lines

Quoted 4 lines

That would allow those boards that need to patch to specify it explicity, while leaving the default functionality unchanged.

Comments?

Yes, I totally agree. Patches should *not* change the default behavior. We should change it as you suggested. Sorry, I must have missed this.

Nobuhiro, could you please send a new patch to fix this problem?

Thank you for your check.
It has troubled you with my patch.

I rewirte new patch . Could you please check this patch and confirming the work?

Best regards,
Nobuhiro

Quoted 5 lines

Quoted 4 lines

Yes, I totally agree. Patches should *not* change the default behavior. We should change it as you suggested. Sorry, I must have missed this.

Nobuhiro, could you please send a new patch to fix this problem?

Quoted 8 lines

Thank you for your check.
It has troubled you with my patch.

I rewirte new patch . Could you please check this patch and confirming the work?

Best regards,
Nobuhiro

Hi Nobuhiro, Stefan, and everyone,

Sorry for the delay in getting back to you. My mail reader thinks your patch is part of your signature, so I missed it the first time around.

I did a quick check using the Sequoia board, and it looks like the patch isn't working there. U-Boot is reporting the class of the bridge as "0680", which I assume is why the patch doesn't skip it.

Nobuhiro and Stefan, do you think we can get a working fix for this into 1.3.3 (even if it is not the final fix)?

If not, we should patch
Sequoia and Korat to add CONFIG_PCI_SKIP_HOST_BRIDGE so they won't be broken in that release.

Quoted 14 lines · Larry Johnson

Quoted 5 lines

Quoted 4 lines

Yes, I totally agree. Patches should *not* change the default behavior. We should change it as you suggested. Sorry, I must have missed this.

Nobuhiro, could you please send a new patch to fix this problem?

Quoted 8 lines

Thank you for your check.
It has troubled you with my patch.

I rewirte new patch . Could you please check this patch and confirming the work?

Best regards,
Nobuhiro

Quoted 8 lines

Hi Nobuhiro, Stefan, and everyone,

Sorry for the delay in getting back to you. My mail reader thinks your patch is part of your signature, so I missed it the first time around.

I did a quick check using the Sequoia board, and it looks like the patch isn't working there. U-Boot is reporting the class of the bridge as "0680", which I assume is why the patch doesn't skip it.

Yes, I just gave the new patch a try and noticed (still) a problem on Sequoia. The PCI host bridge (PPC) is listed upon bootup which was not the case with the U-Boot version prior to the first patch.

Quoted 2 lines

Nobuhiro and Stefan, do you think we can get a working fix for this into 1.3.3 (even if it is not the final fix)?

I definitely hope so. Even though I will probably not find the time to submit a patch to really fix this problem till the scheduled release date. But I will gladly test a patch. :)

Quoted 3 lines

If not, we should patch
Sequoia and Korat to add CONFIG_PCI_SKIP_HOST_BRIDGE so they won't be broken in that release.

Or perhaps we should revert the first patch and give it another try in the next merge-window when/if a new patch is available.

Quoted 31 lines · Stefan Roese

Quoted 12 lines · Larry Johnson

Quoted 4 lines

Quoted 4 lines

Yes, I totally agree. Patches should *not* change the default behavior. We should change it as you suggested. Sorry, I must have missed this.

Nobuhiro, could you please send a new patch to fix this problem?

Quoted 8 lines

Thank you for your check.
It has troubled you with my patch.

I rewirte new patch . Could you please check this patch and confirming the work?

Best regards,
Nobuhiro

Quoted 8 lines

Hi Nobuhiro, Stefan, and everyone,

Sorry for the delay in getting back to you. My mail reader thinks your patch is part of your signature, so I missed it the first time around.

I did a quick check using the Sequoia board, and it looks like the patch isn't working there. U-Boot is reporting the class of the bridge as "0680", which I assume is why the patch doesn't skip it.

Yes, I just gave the new patch a try and noticed (still) a problem on Sequoia. The PCI host bridge (PPC) is listed upon bootup which was not the case with the U-Boot version prior to the first patch.

Quoted 2 lines

Nobuhiro and Stefan, do you think we can get a working fix for this into 1.3.3 (even if it is not the final fix)?

I definitely hope so. Even though I will probably not find the time to submit a patch to really fix this problem till the scheduled release date. But I will gladly test a patch. :)

Quoted 5 lines

Quoted 3 lines

If not, we should patch
Sequoia and Korat to add CONFIG_PCI_SKIP_HOST_BRIDGE so they won't be broken in that release.

Or perhaps we should revert the first patch and give it another try in the next merge-window when/if a new patch is available.

Yes, please. That patch also broke probably all Freescale PowerPC boards. Particularly, without #define CONFIG_PCI_SKIP_HOST_BRIDGE I'm getting these errors from the Linux using PCI 3com driver:

eth4: Host error, FIFO diagnostic register 0000.
eth4: PCI bus error, bus status 80000020
eth4: setting full-duplex.
[infinite times]

This is MPC8315E-RDB.

On Mon, May 05, 2008 at 08:41:59PM +0200, Stefan Roese wrote:

Quoted 2 lines

Or perhaps we should revert the first patch and give it another try in the next merge-window when/if a new patch is available.

Yes, please. That patch also broke probably all Freescale PowerPC boards. Particularly, without #define CONFIG_PCI_SKIP_HOST_BRIDGE I'm getting these errors from the Linux using PCI 3com driver:

Hi Nobuhiro, Stefan, and everyone,

Sorry for the delay in getting back to you. My mail reader thinks your patch is part of your signature, so I missed it the first time around.

I did a quick check using the Sequoia board, and it looks like the patch isn't working there. U-Boot is reporting the class of the bridge as "0680", which I assume is why the patch doesn't skip it.

Nobuhiro and Stefan, do you think we can get a working fix for this into 1.3.3 (even if it is not the final fix)? If not, we should patch Sequoia and Korat to add CONFIG_PCI_SKIP_HOST_BRIDGE so they won't be broken in that release.

I made the patch that applied your comment. This patch skips PCI bridge ( Class code : 0x06XX).

Could you check this patch?

Quoted 5 lines · In message <[email protected]> you wrote:

I made the patch that applied your comment. This patch skips PCI bridge ( Class code : 0x06XX).

Could you check this patch?

Thanks - but note that this will not make it in the v1.3.3 release in any case.

Hi, all.

2008/5/13 Wolfgang Denk <[email protected]>:

Quoted 4 lines

Quoted 3 lines · In message <[email protected]> you wrote:

I made the patch that applied your comment. This patch skips PCI bridge ( Class code : 0x06XX).

Quoted 3 lines

Quoted 1 line

Could you check this patch?

Thanks - but note that this will not make it in the v1.3.3 release in any case.

Does the developer and Board maintainer get a problem with this patch? Would you test this patch?

In current source code, when the device number of PCI is 0, process PCI bridge without fail. However, when the device number is 0, it is not PCI always bridge. There are times when device of PCI allocates.

This patch add check PCI bridge class.

- 0x0604 PCI to AGP bridge / PCI to PCI bridge
- 0x0605 PCI to PCMCIA bridge
- 0x0606 Nu Bus bridge
- 0x0607 PCMCIA CardBus controller
- 0x0608 RACEWay bridge

Hi Nobuhiro,

sorry about the late reply.

Quoted 11 lines · Nobuhiro Iwamatsu

In current source code, when the device number of PCI is 0, process PCI bridge without fail. However, when the device number is 0, it is not PCI always bridge. There are times when device of PCI allocates.

This patch add check PCI bridge class.

- 0x0604 PCI to AGP bridge / PCI to PCI bridge
- 0x0605 PCI to PCMCIA bridge
- 0x0606 Nu Bus bridge
- 0x0607 PCMCIA CardBus controller
- 0x0608 RACEWay bridge

I now finally took the time to take a closer look at this issue. Your approach doesn't look "clean" to me. To be honsest, the original code isn't "clean" either. But with your addition it really get confusing. At least for me.

So let me summarize what the current code (without your patch) does and perhaps you could write again what exactly you want to fix/change. And please correct me if I am wrong.

Currently, the configuration of the PCI device at BDF == 0,0,0 will be skipped if:

a) CONFIG_PCI_CONFIG_HOST_BRIDGE is not defined

or

b) CONFIG_PCI_CONFIG_HOST_BRIDGE is defined but the env variable "pciconfighost" is not defined

So this PCI device will get configured if:

c) CONFIG_PCI_CONFIG_HOST_BRIDGE is defined and the env variable "pciconfighost" is defined too

If I understand you correctly, then you have some PCI devices at BDF == 0,0,0 that need to be configured (and not skipped). Correct? If this is correct, wouldn't it be enough for you to use "solution" c) from above?

If this is not the case, then please explain again exactly what you need to achieve.

Quoted 6 lines

c) CONFIG_PCI_CONFIG_HOST_BRIDGE is defined and the env variable "pciconfighost" is defined too

If I understand you correctly, then you have some PCI devices at BDF == 0,0,0 that need to be configured (and not skipped). Correct? If this is correct, wouldn't it be enough for you to use "solution" c) from above?

Yes, Your indication is right. And there was the part which I did not understand.
But, I think that there is still a problem only by these measures.

For example, BDF == 0,0,0 are not displayed when I validated CONFIG_PCI_SCAN_SHOW.

475 #ifdef CONFIG_PCI_SCAN_SHOW
476 /* Skip our host bridge */
477 if ( dev != PCI_BDF(hose->first_busno,0,0) ) {
478 unsigned char int_line;
479
480 pci_hose_read_config_byte(hose, dev,
PCI_INTERRUPT_LINE, 481 &int_line);
482 printf(" %02x %02x %04x %04x %04x %02x\n",
483 PCI_BUS(dev), PCI_DEV(dev), vendor, device, class,
484 int_line);
485 }
486 #endif

I think that it is a problem to handle only "BDF == 0,0,0". I think that I had better check it in Class ID. ?Of cource, I understand that my implementation is mean.?

2008/5/13 Wolfgang Denk <[email protected]>:

Quoted 5 lines

Quoted 4 lines · In message <[email protected]> you wrote:

I made the patch that applied your comment. This patch skips PCI bridge ( Class code : 0x06XX).

Quoted 4 lines

Quoted 1 line

Could you check this patch?

Thanks - but note that this will not make it in the v1.3.3 release in any case.

Does the developer and Board maintainer get a problem with this patch? Would you test this patch?