Hi,
we've seen platforms where the delay brings you out of problems. Of course this is caused by weird PCI hardware in most cases :-)
I must also admit that the implementation of CONFIG_PCI_BOOTDELAY is not usable in all situations. We have some boards (e.g. PMC440) that can be system cpu or PCI adapter. It's not a good idea to add a pci delay in adapter mode because your device will probably not get configured. So we implemented our own pcidelay mechanism (see board/esd/pmc440/pmc440.c), because we didn't want to adjust pcidelay when switching from system cpu to adapter mode and vice vera.
CONFIG_PCI_BOOTDELAY is of course not intended for fixing WDT issues :-)
It's a good idea to turn on this option when you are running U-Boot on system CPUs that connect to "unknown PCI hardware", e.g you have some PCI/PCIe slots on your board. We never needed it for well known onboard PCI devices.
Matthias
On Wednesday 24 March 2010 21:49, Mike.Johnson@apc.com wrote:
All,
What is the purpose of CONFIG_PCI_BOOTDELAY? I am using uboot version 1.1.4. I know it's old, but in \drivers\pci.c there is a section of code right before pci_init.c is called that can delay the call to pci_init.c.
The code is enabled by defining CONFIG_PCI_BOOTDELAY. But why would it be necessary to delay initializing the PCI hardware?
Specifically in my case, all the resets on my board have occurred well before (500 msec) this portion of the code would execute, so it would seem safe to say that any peripherals like PCI controllers would be satisfied reset-wise.
In my case though, I need to enable CONFIG_PCI_BOOTDELAY to eliminate a WDT problem with a PCI access.
If I do not use CONFIG_PCI_BOOTDELAY, my hardware can exhibit a PCI hang, leading to the above mentioned WDT.
Any information or background that this group can provide would be appreciated.
Thank-you,