Thank you for your input thus far--
I have some conflicting answers, and as such, seek further clarification if possible.
In addition, there has been a suggestion made outside of this forum which is complex, but sounds possible using SPI rather than IIC, in order to provide sufficient storage. The SPI device full boot solution is proposed as follows:
1) RCW is contained within an SPI device followed by PBL blocks
2) The PBL blocks "bit-bang" a bootstrap loader (residing in this same RCW SPI boot device, interleaved within the PBL sequences) into the L3 Cache
3) Bootstrap loader starts executing from the L3 Cache after the PBL sequences pounded the bootstrap code into the L3 Cache
4) This bootstrap loader reads the target boot loader executable code from this same SPI device, and copies it to DRAM
5) Control is transferred to the final boot loader code (DRAM) after the full image is copied to DRAM by the bootstrap loader in L3 Cache
6) The target boot loader code can load an application from other devices, or be the application itself; the choice to boot from this external SPI BOOT FLASH device overrides the on-board BOOT FLASH SPI device, allowing the end-user boot loader/application
A compiler such as GCC may be used to compile bootstrap loader into PBL register sequences. The true boot loader is just serially stored after the bootstrap loading PBL blocks.
The result is a full boot requiring only the SPI BOOT FLASH device and DRAM.
Note that the PBL section of the reference manual(s) state that the start address applies to IIC and SPI interfaces as well. This led me to believe that though these are not random access devices, nonetheless, booting could be done from these devices -- it does not state these interfaces are not available for boot code. It does however state that PBL sequences are used up to time zero, which is the start of executable boot code. So I view this as more than confusing.
Does the above mechanism work?