[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

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

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