Hi Ame,
Yes, what is the main reason you want to do this?
Ok, here is what I want to do. I have a board that has several PPC460s on it. Each has its own DDR2. One of them is the master and boots up normally today with uboot, launches linux, etc. What I want to do is have that master load the flash binary image into memory and then lock that memory down (via whatever kernel calls are required). Then I want to configure each slaves PCI bar registers to be able to read from this main memory and then tell them to go. So my thought was that it would appear to the slaves that they are just loading from a regular flash and this image would contain uboot, kernel, root filesystem. Basically everything a flash normally would have. It sounded reasonable at the time. The reason to avoid a flash on every one is so that we don't have to reflash that many CPUs every time and because it will take up more board space. Thanks
Here's a few ideas then.
1) Use the main host to setup DDR on each of the targets, copy a U-Boot image to each target, and then enable the targets to boot from DDR.
The target U-Boot versions would have to skip all DDR initialization, since they are running from DDR.
I believe this code would come under ...
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted...
Which contains the warning:
'But it is difficult, unsupported, and fraught with peril.'
Wolfgang and Stephan could probably comment more on this.
2) Configure an inbound translation window on the host to point a PCI window to its *flash*.
Configure the outbound translation windows on the targets to point to the host inbound window.
Each target would then boot from the same flash as the host. Assuming there was some I/O to distinguish the targets from the host, the code could determine what to do at runtime.
This has the disadvantage that all boards are booting from potentially slower flash memory, but that may not matter.
3) Configure the host DDR memory such that the OS does not use all installed memory, eg. reserves enough memory for a U-Boot image.
Setup the host inbound translation window to point to that linear DDR region, and have the host copy the image there.
Setup the targets as in (2) and let them boot.
The nice thing about (2) and (3) is that the target processors are effectively in the 'virgin' state that flash booting expects, so the modifications to U-Boot required to support the booting scheme would be minimal.
4) Another option would be to place SRAM on each of the other processors, and copy the U-Boot image there. That way flash on the targets is replaced with SRAM.
However, this would require a hardware change, and is not much of an improvement.
As for the root filesystem, there's more to think about there :)
I will soon have a similar situation to yours. I'll have a master CPU (an x86 host CPU in a compact PCI crate), and 15 to 20 boards in peripheral slots (MPC8349EA processors). Each processor has a gigabit ethernet port, so during development, I'll just use an NFS mounted rootfs. However, once I deploy about 8 crates worth of this hardware, I don't want to have lots of Gbe cables and switches. At that point I plan to change to a scheme where I create a virtual network interface over PCI. If there is stuff that needs to be stored locally, then I'll setup a RAM disk and rsync the contents from an NFS mount at boot time. The only issue with this approach is whether a virtual network over PCI driver exists. The MPC8349EA development kit comes with a driver that sounds like it does some of this, so I'll start with that.
The scheme I envisage is; the peripheral boards boot U-Boot, and that U-Boot port has a 'terminal over PCI' and 'ethernet over PCI' driver built in. Back on the host CPU, I can get to the terminals via /dev/ttyPCI# nodes, and get to each board via ethernet connections, where the slot numbers of the boards define unique MAC addresses. The U-Boots on each board can then tftp a kernel and boot. The kernel command line will use an NFS path that comes back through the x86 host CPU.
None of this is implemented, but its only software ... right :)
Cheers, Dave