On Mon, Jan 19, 2009 at 8:16 AM, dwh@ovro.caltech.edu wrote:
Hi Arun,
I want to configure my board as a PCI target, its based on mcf548x processor. What are the things to be taken care to configure a board as a PCI agent in u-boot?
My processor can act as a PCI master as well as a target. I don't want master interface at all. I want to make my board as a PCI slave and let it respond to other masters by simply sitting on a PCI bus.
Try looking at the MPC8349E-MDS MPC8349EA-MDS board source. Its a PCI board that can act as a standalone master, or as a PCI slave.
Ira Snyder posted some patches for getting it to work correctly as a PCI target, and I think the current git should have the recent changes. If not, feel free to ask him/us questions. I've cc'd him on this response.
I will check this.
I have gone through the u-boot sources and I found that board/freescale/mpc8360emds/pci.c does something similar if CONFIG_PCISLAVE is defined. Its is setting up inbound windows and using pci_setup_indirect(), pci_hose_read_config_word(), pci_hose_write_config_word() functions to make the board a pci slave.
I don't really understand the use of these functions, if i am able to read and write PCI config registers(256 bytes) through my internal bus why these are required?
As per my understanding I just have to configure the PCI inbound windows and leave the rest to PCI master of the entire system. am I thinking wrong?
In addition to what U-Boot wants, you have to make sure you meet your system requirements. PCI targets have to be ready in a few 100ms after power-on. Recent PCI specs state something like 2^25 clocks before the first PCI access by a host, i.e., about 1s at 33MHz, or 0.5s at 66MHz. So when you power on a system, the BIOS on an x86 system is allowed to try to configure the PCI target base addresses and IRQs around this time. If you boot code on the agent takes too long, then things can lock up. (The x86 is supposed to retry the PCI accesses ... but YMMV).
So, in your port, you'll want to make sure that you configure your inbound PCI windows and unlock the PCI interface as soon as you can. You likely won't have 500ms available to you, as eg. a PCI hotswap controller can take 100ms waiting for the power to settle.
Another thing Ira found on the MPC8439E board was that the U-Boot code was scanning the PCI bus before it had unlocked
I won't be needing this PCI scan from the target device.
I will be doing only 1) configure my PCI target device ( do it in < 200ms) 2) Wait to be enumerated from outside 3) start the PCI communication protocol
the PCI hardware. When there were multiple boards in a PCI backplane, the two boards would attempt to read from each other, and things would lockup. That should be patched in the latest U-Boot port for the MPC8349E, so you can go through that code and see what the initialization sequence was, and use that as the basis for your port (if appropriate).
So I can steal the sequence from here great!!!
On the bright side, you're not alone in trying to use U-Boot on a PCI agent. We're doing it, and can hopefully help out when you run into trouble.
You'll also want to make sure you have a PCI logic analyzer adapter :)
Out of interest, how were you planning on communicating with your PCI agent? Ira has a very nice PCINet driver that implements ethernet over PCI, for both U-Boot and Linux.
I want to develop my on custom drivers for this. Don't want to implement console over PCI or ehernet.
Cheers, Dave
Regards, Arun C