Hi Ame,
Hello, I saw a reference to PCI booting in the docs, but could not find enough detail. We would like to use PCI memory space booting on an upcoming design with the PPC460EX. Does Uboot currently support that mode of booting? Is it as easy as booting from a flash? We are developing our app with the canyonlands board, but we won't be able to try the PCI boot until we have our own board finished.
U-Boot is a bootloader. What you are describing here circumvents needing a bootloader.
I use an MPC8349EA Freescale processor, and it also has an option to boot over PCI. However, I plan to use U-Boot on Flash to boot the board. I'll tell you why ... for my hardware anyway, your reasons may end up being similar.
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. There is also the issue that the host CPU is running an OS with its MMU enabled, so the kernel image that it can present to the board over the PCI bus is fragmented. The only way to make this image linear would be to preserve a chunk of memory on boot of the OS, and load the kernel image there for the PCI board to boot from.
There's a lot of code in there that you would have to maintain on your lonesome. For the price of a flash device, I would recommend using U-Boot as the bootloader in Flash on your board. The PCI interface can be used to transfer a kernel image, and then that image can be booted by the bootloader. Note that this transfer can account for the fragmented image on the host by using scatter-gather DMA into the linear address space of the DDR memory on the board (since U-Boot is running with a flat memory map).
Save yourself a lot of trouble, and no community support, by doing things the standard way (and a good sign is, that you're already asking questions).
Note that if your processor has the option that when reset is deasserted, the core can remain in reset, make sure you implement that feature (on the MPC8349EA its controlled by the reset configuration words source pin strapping). This allows you to enable the chip, including the PCI interface, while the core is reset, and therefore does not try to boot. The MPC8349EA has default windows over PCI that then allow a host CPU to manipulate all the memory-mapped registers visible to the PowerPC core. I've been using this feature of the MPC8349EA processor to test my board over PCI from an x86 host. The DDR controller can be enabled/disabled, the clocks swept, and data patterns DMAed to/from PCI to confirm the memory controller configuration prior to attempting a U-Boot port.
Hope this helps.
Cheers, Dave