Hi Darshan,
- 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