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

[David Hawkins <dwh@ovro.caltech.edu>]

Hi Wolfgang,

> This is not necessarily true. There may be many reasons
> why you still want to run a boot loader (like U-Boot) on
> the PCI device's local processor.

Fair enough.

>> If you want to boot your board over PCI, then the board
>> will most likely be a peripheral board (a host would need
>> to boot and setup bridges, so you would have a hard time
>> booting a host through a bridge that is not configured).
>> The host CPU would hold the image of the kernel that you were
>> planning to boot onto the PCI peripheral board. However,
>> your host would need to perform all of the tasks normally
>> performed by the bootloader; setup the memory map, memory
>> controllers, and peripherals that Linux expects to find
>> configured. Then even trickier, is to setup the kernel
>> boot command line arguments and device tree. My guess would
>> be that you would have to hardwire that info into your kernel
>> image, or add a small bootloader to the kernel image to
>> setup the arguments to the kernel proper.
> 
> You see? There is plenty of good reasons to have a well-known,
> powerful boot loader available :-)
> 
>> Save yourself a lot of trouble, and no community support,
> 
> Who says "no community support"? This is a  perfectly  legal  way  of
> using U-Boot, and we we can, we will help.

The 'no community support' referred to maintaining out-of-tree
host-side code that performed all the board-specific setup before
loading the kernel, i.e., with no U-boot interaction at all.
Sorry if that was misleading.

Ok, so given this is a perfectly legal way of booting
U-Boot, would you (Wolfgang) recommend it?

Lets take the MPC8349EA as the example here. The processor
reset configuration can be setup for PCI boot, however the
processor will come out of reset with PCI outbound translation
windows configured to fetch from PCI address 0 (I think).
A boot-sequencer EEPROM on the PowerPC would not help (for
setting up the outbound window), since it won't know the PCI
address of the U-Boot image (lets assume its an x86 running
Linux for example sake). So the x86 host would have to setup
the PCI outbound translation window to point to the U-Boot image.
But you have the issue, that the hosts MMU will be running, so
the linear U-Boot image that the host loaded into memory,
will in fact consist of 4K pages of physical addresses as
viewed over the PCI bus, i.e., the U-Boot image will be
fragmented. The PCI boot sequence from the perspective of
the PowerPC expects a linear sequence of addresses, and for
this particular example, that will not normally be the case.
The host could arrange for a block of its DDR to be reserved
(eg. using the mem= kernel argument on boot), and it could
load the U-Boot image to that, and then point the PowerPC to
boot from the PCI address that points to that window.

So, its not impossible, but it does seem like more work than
using Flash to boot the board. But of course there may be
reasons to want to boot over PCI ...

I guess once you do this, there isn't really much difference
between the U-Boot image that would have been programmed
to Flash versus the one fetched over PCI, since U-Boot
can still perform its stack-in-cache trick, setup DDR
etc.

Interesting ... if there is work done on this, I can test any
patches on the MPC8349EA.

Cheers,
Dave