[U-Boot-Users] pci memory booting on ppc460

[David Hawkins]

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/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

    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