Add qemu 2.4.0

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

1 files changed, 264 insertions, 0 deletions

diff --git a/qemu/roms/u-boot/doc/README.mxs b/qemu/roms/u-boot/doc/README.mxs
new file mode 100644
index 000000000..0235a5aea
--- /dev/null
+++ b/qemu/roms/u-boot/doc/README.mxs
@@ -0,0 +1,264 @@
+Booting U-boot on a MXS processor
+=================================
+
+This document describes the MXS U-Boot port. This document mostly covers topics
+related to making the module/board bootable.
+
+Terminology
+-----------
+
+The term "MXS" refers to a family of Freescale SoCs that is composed by MX23
+and MX28.
+
+The dollar symbol ($) introduces a snipped of shell code. This shall be typed
+into the unix command prompt in U-Boot source code root directory.
+
+The (=>) introduces a snipped of code that should by typed into U-Boot command
+prompt
+
+Contents
+--------
+
+1) Prerequisites
+2) Compiling U-Boot for a MXS based board
+3) Installation of U-Boot for a MXS based board to SD card
+4) Installation of U-Boot into NAND flash on a MX28 based board
+
+1) Prerequisites
+----------------
+
+To make a MXS based board bootable, some tools are necessary. The only
+mandatory tool is the "mxsboot" tool found in U-Boot source tree. The
+tool is built automatically when compiling U-Boot for i.MX23 or i.MX28.
+
+The production of BootStream image is handled via "mkimage", which is
+also part of the U-Boot source tree. The "mkimage" requires OpenSSL
+development libraries to be installed. In case of Debian and derivates,
+this is installed by running:
+
+	$ sudo apt-get install libssl-dev
+
+NOTE: The "elftosb" tool distributed by Freescale Semiconductor is no
+      longer necessary for general use of U-Boot on i.MX23 and i.MX28.
+      The mkimage supports generation of BootStream images encrypted
+      with a zero key, which is the vast majority of use-cases. In
+      case you do need to produce image encrypted with non-zero key
+      or other special features, please use the "elftosb" tool,
+      otherwise continue to section 2). The installation procedure of
+      the "elftosb" is outlined below:
+
+Firstly, obtain the elftosb archive from the following location:
+
+	ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
+
+We use a $VER variable here to denote the current version. At the time of
+writing of this document, that is "10.12.01". To obtain the file from command
+line, use:
+
+	$ VER="10.12.01"
+	$ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
+
+Extract the file:
+
+	$ tar xzf elftosb-${VER}.tar.gz
+
+Compile the file. We need to manually tell the linker to use also libm:
+
+	$ cd elftosb-${VER}/
+	$ make LIBS="-lstdc++ -lm" elftosb
+
+Optionally, remove debugging symbols from elftosb:
+
+	$ strip bld/linux/elftosb
+
+Finally, install the "elftosb" binary. The "install" target is missing, so just
+copy the binary by hand:
+
+	$ sudo cp bld/linux/elftosb /usr/local/bin/
+
+Make sure the "elftosb" binary can be found in your $PATH, in this case this
+means "/usr/local/bin/" has to be in your $PATH.
+
+2) Compiling U-Boot for a MXS based board
+-------------------------------------------
+
+Compiling the U-Boot for a MXS board is straightforward and done as compiling
+U-Boot for any other ARM device. For cross-compiler setup, please refer to
+ELDK5.0 documentation. First, clean up the source code:
+
+	$ make mrproper
+
+Next, configure U-Boot for a MXS based board
+
+	$ make <mxs_based_board_name>_config
+
+Examples:
+
+1. For building U-boot for Denx M28EVK board:
+
+	$ make m28evk_config
+
+2. For building U-boot for Freescale MX28EVK board:
+
+	$ make mx28evk_config
+
+3. For building U-boot for Freescale MX23EVK board:
+
+	$ make mx23evk_config
+
+4. For building U-boot for Olimex MX23 Olinuxino board:
+
+	$ make mx23_olinuxino_config
+
+Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a special
+type of file, which MXS CPUs can boot. This is handled by the following
+command:
+
+	$ make u-boot.sb
+
+HINT: To speed-up the build process, you can add -j<N>, where N is number of
+      compiler instances that'll run in parallel.
+
+The code produces "u-boot.sb" file. This file needs to be augmented with a
+proper header to allow successful boot from SD or NAND. Adding the header is
+discussed in the following chapters.
+
+NOTE: The process that produces u-boot.sb uses the mkimage to generate the
+      BootStream. The BootStream is encrypted with zero key. In case you need
+      some special features of the BootStream and plan on using the "elftosb"
+      tool instead, the invocation to produce a compatible BootStream with the
+      one produced by mkimage is outlined below. For further details, refer to
+      the documentation bundled with the "elftosb" package.
+
+	$ elftosb -zf imx23 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd \
+		-o u-boot.sb
+	$ elftosb -zf imx28 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd \
+		-o u-boot.sb
+
+3) Installation of U-Boot for a MXS based board to SD card
+----------------------------------------------------------
+
+To boot a MXS based board from SD, set the boot mode DIP switches according to
+to MX28 manual, section 12.2.1 (Table 12-2) or MX23 manual, section 35.1.2
+(Table 35-3).
+
+The SD card used to boot U-Boot must contain a DOS partition table, which in
+turn carries a partition of special type and which contains a special header.
+The rest of partitions in the DOS partition table can be used by the user.
+
+To prepare such partition, use your favourite partitioning tool. The partition
+must have the following parameters:
+
+	* Start sector .......... sector 2048
+	* Partition size ........ at least 1024 kb
+	* Partition type ........ 0x53 (sometimes "OnTrack DM6 Aux3")
+
+For example in Linux fdisk, the sequence for a clear card follows. Be sure to
+run fdisk with the option "-u=sectors" to set units to sectors:
+
+	* o ..................... create a clear partition table
+	* n ..................... create new partition
+		* p ............. primary partition
+		* 1 ............. first partition
+		* 2048 .......... first sector is 2048
+		* +1M ........... make the partition 1Mb big
+	* t 1 ................... change first partition ID
+		* 53 ............ change the ID to 0x53 (OnTrack DM6 Aux3)
+	* <create other partitions>
+	* w ..................... write partition table to disk
+
+The partition layout is ready, next the special partition must be filled with
+proper contents. The contents is generated by running the following command
+(see chapter 2)):
+
+	$ ./tools/mxsboot sd u-boot.sb u-boot.sd
+
+The resulting file, "u-boot.sd", shall then be written to the partition. In this
+case, we assume the first partition of the SD card is /dev/mmcblk0p1:
+
+	$ dd if=u-boot.sd of=/dev/mmcblk0p1
+
+Last step is to insert the card into the MXS based board and boot.
+
+NOTE: If the user needs to adjust the start sector, the "mxsboot" tool contains
+      a "-p" switch for that purpose. The "-p" switch takes the sector number as
+      an argument.
+
+4) Installation of U-Boot into NAND flash on a MX28 based board
+---------------------------------------------------------------
+
+To boot a MX28 based board from NAND, set the boot mode DIP switches according
+to MX28 manual section 12.2.1 (Table 12-2), PORT=GPMI, NAND 1.8 V.
+
+There are two possibilities when preparing an image writable to NAND flash.
+
+	I) The NAND wasn't written at all yet or the BCB is broken
+	----------------------------------------------------------
+	   In this case, both BCB (FCB and DBBT) and firmware needs to be
+	   written to NAND. To generate NAND image containing all these,
+	   there is a tool called "mxsboot" in the "tools/" directory. The tool
+	   is invoked on "u-boot.sb" file from chapter 2):
+
+		 $ ./tools/mxsboot nand u-boot.sb u-boot.nand
+
+	   NOTE: The above invokation works for NAND flash with geometry of
+		 2048b per page, 64b OOB data, 128kb erase size. If your chip
+		 has a different geometry, please use:
+
+		 -w <size>	change page size (default 2048 b)
+		 -o <size>	change oob size (default 64 b)
+		 -e <size>	change erase size (default 131072 b)
+
+		 The geometry information can be obtained from running U-Boot
+		 on the MX28 board by issuing the "nand info" command.
+
+	   The resulting file, "u-boot.nand" can be written directly to NAND
+	   from the U-Boot prompt. To simplify the process, the U-Boot default
+	   environment contains script "update_nand_full" to update the system.
+
+	   This script expects a working TFTP server containing the file
+	   "u-boot.nand" in it's root directory. This can be changed by
+	   adjusting the "update_nand_full_filename" varible.
+
+	   To update the system, run the following in U-Boot prompt:
+
+		 => run update_nand_full
+
+	   In case you would only need to update the bootloader in future,
+	   see II) below.
+
+	II) The NAND was already written with a good BCB
+	------------------------------------------------
+	   This part applies after the part I) above was done at least once.
+
+	   If part I) above was done correctly already, there is no need to
+	   write the FCB and DBBT parts of NAND again. It's possible to upgrade
+	   only the bootloader image.
+
+	   To simplify the process of firmware update, the U-Boot default
+	   environment contains script "update_nand_firmware" to update only
+	   the firmware, without rewriting FCB and DBBT.
+
+	   This script expects a working TFTP server containing the file
+	   "u-boot.sb" in it's root directory. This can be changed by
+	   adjusting the "update_nand_firmware_filename" varible.
+
+	   To update the system, run the following in U-Boot prompt:
+
+		 => run update_nand_firmware
+
+	III) Special settings for the update scripts
+	--------------------------------------------
+	   There is a slight possibility of the user wanting to adjust the
+	   STRIDE and COUNT options of the NAND boot. For description of these,
+	   see MX28 manual section 12.12.1.2 and 12.12.1.3.
+
+	   The update scripts take this possibility into account. In case the
+	   user changes STRIDE by blowing fuses, the user also has to change
+	   "update_nand_stride" variable. In case the user changes COUNT by
+	   blowing fuses, the user also has to change "update_nand_count"
+	   variable for the update scripts to work correctly.
+
+	   In case the user needs to boot a firmware image bigger than 1Mb, the
+	   user has to adjust the "update_nand_firmware_maxsz" variable for the
+	   update scripts to work properly.