[U-Boot] Using Uboot to communicate a PCI device.

[dwh at ovro.caltech.edu]

Hi Darshan,

> Cavium's U-boot version included has been modified to support
> multicore OCTEON processors. The 'bootoct' command has been
> added, which supports the booting of an Octeon simple
> executive application.

Ok. Since the processor is already supported in U-Boot,
your life is much easier.

> In my case I dont have any OS on the board

Ok.

> U-boot is responsible for loading applications into
> the Octeon Memory space.

Ok.

> But i have heard that Uboot(inside Octeon) can be modified
> to communicate to a device.

If the other processors are in the address space of the
Octeon processor, or if an Octeon PCI window can be moved
to overlay each of the NPs, then host read/write accesses
can be used to initialize the slave NPs. There is no
additional 'communication' code needed.

> Since No OS such as Linux exists, Cavium's U-Boot will initialize the
> processor itself (As a Simple Executive) along with its PCI interface
> initialization is also done. Now, how should i go ahead in talking to the
> Winpath NP for doing a task. For eg, Copying the Winpath Boot Image onto
> the NP via the PCI interface?

Once the NP PCI interface is configured and enabled, you
should be able to use read/write accesses on your host that
hit the PCI addresses corresponding to the NP.

As an analogy, we have a single x86 host processor in a cPCI
interface with 15 PowerPC boards plugged into the backplane.
The host BIOS initializes the PCI interfaces on the PowerPC boards
and enables them. On the PowerPCs, if U-Boot has not been
installed, a default PCI window is setup, and if U-Boot is
installed a custom setting is used (the local-side PCI
initialization completes before the x86 BIOS enables the
interfaces). As far as the x86 host is concerned, each
PowerPC appears as at least two windows in the PCI space;
one window is a set of PowerPC control registers, and
another window points to an arbitrary address in the
PowerPC memory map. Manipulation of a control register
changes the base address, so the window can be moved around.

Your NPs should have something similar. The host's U-Boot can
initialize the PCI interfaces on the NPs, and then later your
U-Boot 'NP boot' command (U-boot application) can use the PCI
interface registers to move the window around while copying
application code into the NP memory space. You would need
to have access via PCI to NP control registers too, so that
you can release the NP core from reset and allow it to boot
from the application code your host just copied into its
address space.

Based on your current understanding of the processors,
does any of this sound possible?

> The Winpath has a similar U-boot*-like* bootloader to boot
> up the processor... since it doesn't have tftp or flash
> interface for copying the bootloader image... Cavium has
> to do this task via its PCI interface.
> Cavium's task is to load Wintegra NP's Bootloader into the
> memory space of Wintegra so that WinPath boots itself and
> further all the applications that Winpath has to run shall
> be "loaded" to Winpath into its memory addresses. The
> bottomline is Winapth NP does not have direct access to
> TFTP/Flash for loading the applications or even the
> bootloader, it has to do it via the Cavium on the PCI interface.

Ok. This is should be no problem.

These devices are 'network processors'. Do they have a direct
network connection, or do they get all their network data
via the host processor?

The host can copy all data into the NP memory space, however,
once the NP is booted, you will want some form of commincations;
which is what you are asking. However, there are more questions:

- Cavium host boots U-Boot
- NP boots Winpath NP bootloader

Do you have access to the source code for the NP bootloader
so that you can implement both ends of the communication path?

Depending on the complexity needed, the communications can
be as simple as an interlock to indicate to the NP that a
new application is needed, or it can be as complex as
an emulated serial-port-over-PCI and network-over-PCI as
demonstrated in Ira's drivers.

> Since Cavium's Octeon and Wintegra's Winpath are 'sitting' on the same
> board as two chips they cant communicate over the network.

Why not? It doesn't matter where they are sitting if they
both have a network interface. However, I assume you mean
they do not have an external connection via the network.

> I hope i am much clearer this time.

We're getting there :)

Is there any documentation on the boards you are working on
that is available online? At a minimum links to the Cavium
and NP data sheets would be useful.

Cheers,
Dave