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.john...@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, > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot