On Mon, Jan 19, 2009 at 8:16 AM, <d...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
