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

[dwh at ovro.caltech.edu]

Hi Darshan,

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

Right. The host CPU can configure the PCI interface on the NP.

> 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?

The host CPU must be able to issue configuration space
read/writes, since that is what it uses to setup devices.
The host CPU will generally also support memory and I/O
read/writes. The user manual will tell you how to generate
the configuration space read/write, whereas the memory map
configuration will generally determine whether a memory
or I/O transaction is generated. These questions are totally
independent of U-Boot and require that you read the user
manual - the trick is knowing what to look for - which you
now do.

> I am really sorry if my questions are too silly. I am
> new to u-boot and PCI hence such questions.

They're not silly, just inexperienced.

> 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?

Initialization of a PCI interface will require actions from both
the slave side (NP) of the bridge and on the host side. The
activity on the host side is standardized by the PCI spec, i.e.,
there is a standard sequence used to initialize PCI devices.
However, the configuration of the slave side of the NP PCI
interface needs to be performed to describe how many
base-address-registers (BARs) and what they point to.
For that, you need to read the user manual for the NP,
and look at the PCI initialization (its possible that its
hardcoded, but you'll have to find that out).

> 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')?

At some point you will have to write some code. But first,
you should be able to manually perform most of the operations
needed to boot an NP processor.

Once you figure that out, you can post an RFC
(request for comments) on how you plan to proceed so
others can provide feedback. Its quite possible that
once you know what you want to do, that something
already exists, or something similar that can
be generalized exists.

> *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?

Sure, its not magic. If you write a custom communications
protocol at one end, then you need to write the code at
the other end.

The board hardware engineer should have figured out how the
two devices were planning on communicating. Perhaps you are
lucky and that in addition to the PCI interfaces being
routed together, the serial ports on the cores are connected
(if the processors have such things). In that case, the
host might be able to control the slaves via serial commands.

You have not provided sufficient information to say much more.

> 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?

Maybe. Again, insufficient information.

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

- This isn't a user manual, its a block diagram and
  product request interface.
- What about the processors connected via the PCI bus?
- What about the actual wiring on the board?

One huge advantage of using open-source software is to
use the combined knowledge of the open-source community. However,
its a two-way street. If you can't provide easily accessible
low-level documentation, you're not going to get much help.

Processors have a huge amount of configuration possible,
and there are a lot of power-on pin strappings that
hardwire some features of the processor on boot. If your
board was designed without consideration for how the
processor bootup was to proceed, then you could be in
trouble.

What you need to do is read the processor documentation for
both the host and slave processors, and look at the board
design.

You need to discuss this board design with the original
hardware engineer to determine how they expected the
power-on-sequence and boot sequences to proceed.

I understand you are learning, so will help provide feedback
where I can.

Cheers,
Dave