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

[Darshan Vasisht]

Hi Dave,
 I am really happy for your co-operation in making me understand things
which i completely don't have an idea for.
I am getting some clarity into this requirement after looking at your
answers and explanations.
Let me tell you what i am able to understand from these explanations at this
juncture.
1. Since Octeon's u-boot has the capabilities of initialize Octeon's PCI
(Assign bus address ranges used to configure devices found on the PCI bus),
we can talk to a PCI device on the other end provided we have info about
their memory addressing etc.
*Having said this, what all (info) i need to have from the PCI device
(Winpath NP) so that i am able to bring it up. I mean do i need to have some
device driver of NP so that i am able to read/write into its Config
space/Memory space?* I am really sorry if my questions are too silly. I am
new to u-boot and PCI hence such questions.

Now let me answer the questions, you have asked me.
*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?
*I am not able to apprehend the very first sentence you have quoted. The
host's U-boot can initialize its own end of the PCI interface. How can it
initialize the PCI interface of the NP? Please, can you give me more clarity
on this?
You mention, "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*.*"
In order to execute such task, do i need a program code (NP device driver)
present at my end (inside my U-boot's driver folder) so that i will be able
to write an u-boot application('NP Boot')?

*Do you have access to the source code for the NP bootloader so that you can
implement both ends of the communication path?*
Can i conclude after reading the above sentence written from you that i need
to write some code (which involves modification in the NP bootloader) to
complete the 'NP boot'  initiated from the other end?
Also, can i conclude that in order to achieve my objective of Booting an
NP(PCI device) from Octeon (PCI host) involves work at both the ends?

*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.*
I am afraid such datasheets wont be available speaking details like PIN
configuration etc.Check this link a primitive one ;-) (
http://www.caviumnetworks.com/OCTEON-Plus_CN58XX.html)


2009/7/18 <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
>
>
>