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

dwh at ovro.caltech.edu dwh at ovro.caltech.edu
Mon Jan 19 03:46:31 CET 2009


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 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
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).

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.

Cheers,
Dave





More information about the U-Boot mailing list