Hi Timur,
The MPC8349E can be booted such that the core is held in reset, and the processor registers can be configured over PCI by another host computer. Therefore it is conceivable that the host can program the SDRAM controller on the MPC8349E and take the core out of reset. If the core is configured to boot from an address mapped to SDRAM, then U-Boot could have been copied to SDRAM by the host. Once U-Boot boots, it could then use FTP etc to boot the kernel blah blah ...
Ok fine, but you're talking about an 8349 on a different board. I have a *board* header file for the MPC8349E-mITX, which comes with 16MB of flash and works just fine. I've done the hard work of getting U-Boot running on that board with flash. So the question is, am I going to upset someone if I remove support for booting from RAM on that board?
In that instance, since its a board you are personally supporting, I think its your choice, so go ahead and remove it. If someone decides that they want to add RAM boot support, then they can supply the patch. If someone asks how to do it, then point them to the MPC8349E-MDS-PB source (where I assume it exists). If they get it to work on the -mITX, then they can submit a patch along with a clear explanation of why they thought it was necessary to support it.
Of course the fact that this code sounds like its being copied from BSP to BSP, when its quite possibly general code, is not that desirable. So deleting it from this BSP will hopefully discourage that practice.
Cheers, Dave