Dear Vitaly,

in message 42518178.60801@ru.mvista.com you wrote:

I have a small question - do you have any comments/objection on adding support for PCI bridge of 8272ADS to the CVS?

I hesitate. I feel it is the wrong thing to do, but I can understand your concerns.

It turned out now, that this can solve amount of problems concerning too slow board startup (http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/017447.html) . In short, some PCI cards need the udelay up to (1000000) after deassertion of RST#, which is... slow, at least.

I understand that thisi s unacceptably slow for some situations, but then it's required by the standard, and you will have to live with it one way or abother - the other option is not to use PCI connected devices, i. e. fix the hardware design.

While doing all necessary init in the firmware, enough time will almost surely be spent after clearing RST, so that resetting and delay can be eliminated from the kernel code.

I see the following problems:

* If you want to do it right you must MAKE SURE to wait for the required time, i. e. even if you clear RST in the boot loader, you will still have to make sure to wait in Linux until 2**25 clocks later; this requires passing some time information between the bootloader and the kernel which is not in the current design. Of course this is not difficult to add if there is a general agreement to do this - but remeber that this affects everybody, not only PowerPC and not only U-Boot.

* I think it is not a good idea to export kernel problems to the boot loader. IMHO the kernel (and all subsytems and drivers in the kernel) should be as independent from a boot loader as possible. They should not make any assumptions about the previous state of the hardware, but always initialize it as they need it. Assumptions about certain pre-set staes only cause a lot of pain later, for example when the operation of drivers depends on the sequence in which modules get loaded, or drivers don't work when loaded as module at all, or ...

* Adding new requirements for bootloaders is a bad idea in general: instead of solving the problem once (where it originates - in the kernel) they would enforce changes to many boot loaders, and make the kernel break on old versions of the boot loaders, or even useless on boards where it is not possible to get newer, modified versions of the boot loader.

* I think it is also a bad idea to rely on the fact that U-Boot is used as boot loader. Linux should never rely on a specific boot loader being used.

I can see that the suggested change solves your immediate problem, but I don't think it's a good solution in general. [No, I don't know of a "good" general solution - except avoiding PCI where this delay is unacceptable.]

Best regards,

Wolfgang Denk