From mboxrd@z Thu Jan  1 00:00:00 1970
From: Florian Boelstler <euphoria@arcor.de>
Date: Thu, 16 Aug 2007 13:31:21 +0200
Subject: [U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE
In-Reply-To: <464B951E.206@ovro.caltech.edu>
References: <20070516220434.ABD38352650@atlas.denx.de>	<464B818F.60509@freescale.com>
	<464B951E.206@ovro.caltech.edu>
Message-ID: <fa1cio$vqv$1@sea.gmane.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi,

yes, it's an old thread -- just for the record:

David Hawkins wrote:
> 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 ...
> 
> Yeah yeah, its contrived ...

Not really, we almost do it in that way on a custom MPC8540 and a
MPC8541 board.
Basic hardware settings are done using Boot Sequencer EEPROM.
Settings can be concluded with settings written over PCI by host
(PCSRBAR on BAR0).
U-Boot and Linux are directly written over PCI into RAM.
The boards itself didn't got flash memory at all.
U-Boot environment is contained in I2C-EEPROM as well (can be concluded
with a specially crafted environment found in RAM -- which is another
hack though).

> Of course if the host is configuring all the registers,
> then there is probably no reason for the bootloader ...
> just boot to Linux directly from SDRAM.

No, we don't want to get rid of this nice U-Boot... :)

Cheers,

   Florian