Add qemu 2.4.0

Change-Id: Ic99cbad4b61f8b127b7dc74d04576c0bcbaaf4f5
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>

1 files changed, 102 insertions, 0 deletions

diff --git a/qemu/roms/u-boot/doc/README.ramboot-ppc85xx b/qemu/roms/u-boot/doc/README.ramboot-ppc85xx
new file mode 100644
index 000000000..5cc546a36
--- /dev/null
+++ b/qemu/roms/u-boot/doc/README.ramboot-ppc85xx
@@ -0,0 +1,102 @@
+			RAMBOOT for MPC85xx Platforms
+			==============================
+
+RAMBOOT literally means boot from DDR. But since DDR is volatile memory some
+pre-mechanism is required to load the DDR with the bootloader binary.
+- In case of SD and SPI boot this is done by BootROM code inside the chip
+  itself.
+- In case of NAND boot FCM supports loading initial 4K code from NAND flash
+  which can initialize the DDR and get the complete bootloader copied to DDR.
+
+In addition to the above there could be some more methods to initialize the DDR
+and load it manually.
+Two of them are described below.There is also an explanation as to where these
+methods could be handy.
+1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then
+   execute the bootloader from DDR.
+   This may be handy in the following cases:
+     - In very early stage of platform bringup where other boot options are not
+       functional because of various reasons.
+     - In case the support to program the flashes on the board is not available.
+
+2. Load the RAM based bootloader onto DDR using already existing bootloader on
+   the board.And then execute the bootloader from DDR.
+   Some usecases where this may be used:
+      - While developing some new feature of u-boot, for example USB driver or
+	SPI driver.
+	Suppose the board already has a working bootloader on it. And you would
+	prefer to keep it intact, at the same time want to test your bootloader.
+	In this case you can get your test bootloader binary into DDR via tftp
+	for example. Then execute the test bootloader.
+     - Suppose a platform already has a propreitery bootloader which does not
+       support for example AMP boot. In this case also RAM boot loader can be
+       utilized.
+
+   So basically when the original bootloader is required to be kept intact
+   RAM based bootloader can offer an updated bootloader on the system.
+
+Both the above Bootloaders are slight variants of SDcard or SPI Flash
+bootloader or for that matter even NAND bootloader.
+All of them define CONFIG_SYS_RAMBOOT.
+The main difference among all of them is the way the pre-environment is getting
+configured and who is doing that.
+- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself.
+- In case of NAND boot SPL/TPL code does it with some support from Si itself.
+- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader.
+
+How to use them:
+1. Using JTAG
+   Boot up in core hold off mode or stop the core after reset using JTAG
+   interface.
+   Preconfigure DDR/L2SRAM through JTAG interface.
+	- setup DDR controller registers.
+	- setup DDR LAWs
+	- setup DDR TLB
+   Load the RAM based boot loader to the proper location in DDR/L2SRAM.
+   set up IAR (Instruction counter properly)
+   Enable the core to execute.
+
+2. Using already existing bootloader.
+   get the rambased boot loader binary into DDR/L2SRAM via tftp.
+   execute the RAM based bootloader.
+      => tftp 11000000 u-boot-ram.bin
+      => go 1107f000
+
+Please note that L2SRAM can also be used instead of DDR if the SOC has
+sufficient size of L2SRAM.
+
+Necessary Code changes Required:
+=====================================
+Please note that below mentioned changes are for 85xx platforms.
+They have been tested on P1020/P2020/P1010 RDB.
+
+The main difference between the above two methods from technical perspective is
+that in 1st case SOC is just out of reset so it is in default configuration.
+(CCSRBAR is at 0xff700000).
+In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000
+
+1. File name-> boards.cfg
+   There can be added specific Make options for RAMBoot. We can keep different
+   options for the two cases mentioned above.
+   for example
+   P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT.
+
+2. platform config file
+   for example include/configs/P1_P2_RDB.h
+
+   #ifdef CONFIG_RAMBOOT
+   #define CONFIG_SDCARD
+   #endif
+
+   This will finally use the CONFIG_SYS_RAMBOOT.
+
+3. File name-> arch/powerpc/include/asm/config_mpc85xx.h
+   In the section of the particular SOC, for example P1020,
+
+   #if defined(CONFIG_GO)
+   #define CONFIG_SYS_CCSRBAR_DEFAULT	0xffe00000
+   #else
+   #define CONFIG_SYS_CCSRBAR_DEFAULT	0xff700000
+   #endif
+
+For JTAG  RAMBOOT this is not required because CCSRBAR is at ff700000.