[U-Boot] configuring the board as a pci target in u-boot

[arun c]

On Mon, Jan 19, 2009 at 8:16 AM,  <dwh at 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