Adding qemu as a submodule of KVMFORNFV

This Patch includes the changes to add qemu as a submodule to
kvmfornfv repo and make use of the updated latest qemu for the
execution of all testcase
Change-Id: I1280af507a857675c7f81d30c95255635667bdd7
Signed-off-by:RajithaY<rajithax.yerrumsetty@intel.com>

12 files changed, 0 insertions, 1629 deletions

diff --git a/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt b/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt
deleted file mode 100644
index 6c99b1c15..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt
+++ /dev/null
@@ -1,191 +0,0 @@
-Command syntax extensions for the new uImage format
-===================================================
-
-Author: Bartlomiej Sieka <tur@semihalf.com>
-
-With the introduction of the new uImage format, bootm command (and other
-commands as well) have to understand new syntax of the arguments. This is
-necessary in order to specify objects contained in the new uImage, on which
-bootm has to operate. This note attempts to first summarize bootm usage
-scenarios, and then introduces new argument syntax.
-
-
-bootm usage scenarios
----------------------
-
-Below is a summary of bootm usage scenarios, focused on booting a PowerPC
-Linux kernel. The purpose of the following list is to document a complete list
-of supported bootm usages.
-
-Note: U-Boot supports two methods of booting a PowerPC Linux kernel: old way,
-i.e., without passing the Flattened Device Tree (FDT), and new way, where the
-kernel is passed a pointer to the FDT. The boot method is indicated for each
-scenario.
-
-
-1.  bootm		boot image at the current address, equivalent to 2,3,8
-
-Old uImage:
-2.  bootm <addr1>		    /* single image at <addr1> */
-3.  bootm <addr1>		    /* multi-image at <addr1>  */
-4.  bootm <addr1> -		    /* multi-image at <addr1>  */
-5.  bootm <addr1> <addr2>	    /* single image at <addr1> */
-6.  bootm <addr1> <addr2> <addr3>   /* single image at <addr1> */
-7.  bootm <addr1> -	  <addr3>   /* single image at <addr1> */
-
-New uImage:
-8.  bootm <addr1>
-9.  bootm [<addr1>]:<subimg1>
-10. bootm [<addr1>]#<conf>
-11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
-12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
-13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
-14. bootm [<addr1>]:<subimg1> -			  [<addr3>]:<subimg3>
-15. bootm [<addr1>]:<subimg1> -			  <addr3>
-
-
-Ad. 1. This is equivalent to cases 2,3,8, depending on the type of image at
-the current image address.
-- boot method: see cases 2,3,8
-
-Ad. 2. Boot kernel image located at <addr1>.
-- boot method: non-FDT
-
-Ad. 3. First and second components of the image at <addr1> are assumed to be a
-kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
-with the ramdisk from the image.
-- boot method: depends on the number of components at <addr1>, and on whether
-  U-Boot is compiled with OF support:
-
-		    |	       2 components |	       3 components |
-		    |	   (kernel, initrd) | (kernel, initrd, fdt) |
----------------------------------------------------------------------
-#ifdef CONFIG_OF_*  |		    non-FDT |			FDT |
-#ifndef CONFIG_OF_* |		    non-FDT |		    non-FDT |
-
-Ad. 4. Similar to case 3, but the kernel is booted without initrd.  Second
-component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
-- boot method: see case 3
-
-Ad. 5. Boot kernel image located at <addr1> with initrd loaded with ramdisk
-from the image at <addr2>.
-- boot method: non-FDT
-
-Ad. 6. <addr1> is the address of a kernel image, <addr2> is the address of a
-ramdisk image, and <addr3> is the address of a FDT binary blob.  Kernel is
-booted with initrd loaded with ramdisk from the image at <addr2>.
-- boot method: FDT
-
-Ad. 7. <addr1> is the address of a kernel image and <addr3> is the address of
-a FDT binary blob. Kernel is booted without initrd.
-- boot method: FDT
-
-Ad. 8. Image at <addr1> is assumed to contain a default configuration, which
-is booted.
-- boot method: FDT or non-FDT, depending on whether the default configuration
-  defines FDT
-
-Ad. 9. Similar to case 2: boot kernel stored in <subimg1> from the image at
-address <addr1>.
-- boot method: non-FDT
-
-Ad. 10. Boot configuration <conf> from the image at <addr1>.
-- boot method: FDT or non-FDT, depending on whether the configuration given
-  defines FDT
-
-Ad. 11. Equivalent to case 5: boot kernel stored in <subimg1> from the image
-at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
-<addr2>.
-- boot method: non-FDT
-
-Ad. 12. Equivalent to case 6: boot kernel stored in <subimg1> from the image
-at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
-<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
-- boot method: FDT
-
-Ad. 13. Similar to case 12, the difference being that <addr3> is the address
-of FDT binary blob that is to be passed to the kernel.
-- boot method: FDT
-
-Ad. 14. Equivalent to case 7: boot kernel stored in <subimg1> from the image
-at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
-<addr3>.
-- boot method: FDT
-
-Ad. 15. Similar to case 14, the difference being that <addr3> is the address
-of the FDT binary blob that is to be passed to the kernel.
-- boot method: FDT
-
-
-New uImage argument syntax
---------------------------
-
-New uImage support introduces two new forms for bootm arguments, with the
-following syntax:
-
-- new uImage sub-image specification
-<addr>:<sub-image unit_name>
-
-- new uImage configuration specification
-<addr>#<configuration unit_name>
-
-
-Examples:
-
-- boot kernel "kernel@1" stored in a new uImage located at 200000:
-bootm 200000:kernel@1
-
-- boot configuration "cfg@1" from a new uImage located at 200000:
-bootm 200000#cfg@1
-
-- boot "kernel@1" from a new uImage at 200000 with initrd "ramdisk@2" found in
-  some other new uImage stored at address 800000:
-bootm 200000:kernel@1 800000:ramdisk@2
-
-- boot "kernel@2" from a new uImage at 200000, with initrd "ramdisk@1" and FDT
-  "fdt@1", both stored in some other new uImage located at 800000:
-bootm 200000:kernel@1 800000:ramdisk@1 800000:fdt@1
-
-- boot kernel "kernel@2" with initrd "ramdisk@2", both stored in a new uImage
-  at address 200000, with a raw FDT blob stored at address 600000:
-bootm 200000:kernel@2 200000:ramdisk@2 600000
-
-- boot kernel "kernel@2" from new uImage at 200000 with FDT "fdt@1" from the
-  same new uImage:
-bootm 200000:kernel@2 - 200000:fdt@1
-
-
-Note on current image address
------------------------------
-
-When bootm is called without arguments, the image at current image address is
-booted. The current image address is the address set most recently by a load
-command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example, consider
-the following commands:
-
-tftp 200000 /tftpboot/kernel
-bootm
-Last command is equivalent to:
-bootm 200000
-
-In case of the new uImage argument syntax, the address portion of any argument
-can be omitted. If <addr3> is omitted, then it is assumed that image at
-<addr2> should be used. Similarly, when <addr2> is omitted, it is assumed that
-image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
-current image address is to be used. For example, consider the following
-commands:
-
-tftp 200000 /tftpboot/uImage
-bootm :kernel@1
-Last command is equivalent to:
-bootm 200000:kernel@1
-
-tftp 200000 /tftpboot/uImage
-bootm 400000:kernel@1 :ramdisk@1
-Last command is equivalent to:
-bootm 400000:kernel@1 400000:ramdisk@1
-
-tftp 200000 /tftpboot/uImage
-bootm :kernel@1 400000:ramdisk@1 :fdt@1
-Last command is equivalent to:
-bootm 200000:kernel@1 400000:ramdisk@1 400000:fdt@1
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/howto.txt b/qemu/roms/u-boot/doc/uImage.FIT/howto.txt
deleted file mode 100644
index 526be55a5..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/howto.txt
+++ /dev/null
@@ -1,297 +0,0 @@
-How to use images in the new image format
-=========================================
-
-Author: Bartlomiej Sieka <tur@semihalf.com>
-
-
-Overview
---------
-
-The new uImage format allows more flexibility in handling images of various
-types (kernel, ramdisk, etc.), it also enhances integrity protection of images
-with sha1 and md5 checksums.
-
-Two auxiliary tools are needed on the development host system in order to
-create an uImage in the new format: mkimage and dtc, although only one
-(mkimage) is invoked directly. dtc is called from within mkimage and operates
-behind the scenes, but needs to be present in the $PATH nevertheless. It is
-important that the dtc used has support for binary includes -- refer to
-www.jdl.com for its latest version. mkimage (together with dtc) takes as input
-an image source file, which describes the contents of the image and defines
-its various properties used during booting. By convention, image source file
-has the ".its" extension, also, the details of its format are given in
-doc/uImage.FIT/source_file_format.txt. The actual data that is to be included in
-the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
-form of paths to appropriate data files. The outcome of the image creation
-process is a binary file (by convention with the ".itb" extension) that
-contains all the referenced data (kernel, ramdisk, etc.) and other information
-needed by U-Boot to handle the uImage properly. The uImage file is then
-transferred to the target (e.g., via tftp) and booted using the bootm command.
-
-To summarize the prerequisites needed for new uImage creation:
-- mkimage
-- dtc (with support for binary includes)
-- image source file (*.its)
-- image data file(s)
-
-
-Here's a graphical overview of the image creation and booting process:
-
-image source file     mkimage + dtc		  transfer to target
-	+	     ---------------> image file --------------------> bootm
-image data file(s)
-
-
-Example 1 -- old-style (non-FDT) kernel booting
------------------------------------------------
-
-Consider a simple scenario, where a PPC Linux kernel built from sources on the
-development host is to be booted old-style (non-FDT) by U-Boot on an embedded
-target. Assume that the outcome of the build is vmlinux.bin.gz, a file which
-contains a gzip-compressed PPC Linux kernel (the only data file in this case).
-The uImage can be produced using the image source file
-doc/uImage.FIT/kernel.its (note that kernel.its assumes that vmlinux.bin.gz is
-in the current working directory; if desired, an alternative path can be
-specified in the kernel.its file). Here's how to create the image and inspect
-its contents:
-
-[on the host system]
-$ mkimage -f kernel.its kernel.itb
-DTC: dts->dtb  on file "kernel.its"
-$
-$ mkimage -l kernel.itb
-FIT description: Simple image with single Linux kernel
-Created:	 Tue Mar 11 17:26:15 2008
- Image 0 (kernel@1)
-  Description:	Vanilla Linux kernel
-  Type:		Kernel Image
-  Compression:	gzip compressed
-  Data Size:	943347 Bytes = 921.24 kB = 0.90 MB
-  Architecture: PowerPC
-  OS:		Linux
-  Load Address: 0x00000000
-  Entry Point:	0x00000000
-  Hash algo:	crc32
-  Hash value:	2ae2bb40
-  Hash algo:	sha1
-  Hash value:	3c200f34e2c226ddc789240cca0c59fc54a67cf4
- Default Configuration: 'config@1'
- Configuration 0 (config@1)
-  Description:	Boot Linux kernel
-  Kernel:	kernel@1
-
-
-The resulting image file kernel.itb can be now transferred to the target,
-inspected and booted (note that first three U-Boot commands below are shown
-for completeness -- they are part of the standard booting procedure and not
-specific to the new image format).
-
-[on the target system]
-=> print nfsargs
-nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
-=> print addip
-addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
-=> run nfsargs addip
-=> tftp 900000 /path/to/tftp/location/kernel.itb
-Using FEC device
-TFTP from server 192.168.1.1; our IP address is 192.168.160.5
-Filename '/path/to/tftp/location/kernel.itb'.
-Load address: 0x900000
-Loading: #################################################################
-done
-Bytes transferred = 944464 (e6950 hex)
-=> iminfo
-
-## Checking Image at 00900000 ...
-   FIT image found
-   FIT description: Simple image with single Linux kernel
-   Created:	    2008-03-11	16:26:15 UTC
-    Image 0 (kernel@1)
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000e0
-     Data Size:    943347 Bytes = 921.2 kB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2ae2bb40
-     Hash algo:    sha1
-     Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
-    Default Configuration: 'config@1'
-    Configuration 0 (config@1)
-     Description:  Boot Linux kernel
-     Kernel:	   kernel@1
-
-=> bootm
-## Booting kernel from FIT Image at 00900000 ...
-   Using 'config@1' configuration
-   Trying 'kernel@1' kernel subimage
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000e0
-     Data Size:    943347 Bytes = 921.2 kB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2ae2bb40
-     Hash algo:    sha1
-     Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
-   Verifying Hash Integrity ... crc32+ sha1+ OK
-   Uncompressing Kernel Image ... OK
-Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
-Linux version 2.4.25 (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 czw lip 5 17:56:18 CEST 2007
-On node 0 totalpages: 65536
-zone(0): 65536 pages.
-zone(1): 0 pages.
-zone(2): 0 pages.
-Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_6xx ip=192.168.160.5:192.168.1.1::255.255.0.0:lite5200b:eth0:off panic=1
-Calibrating delay loop... 307.20 BogoMIPS
-
-
-Example 2 -- new-style (FDT) kernel booting
--------------------------------------------
-
-Consider another simple scenario, where a PPC Linux kernel is to be booted
-new-style, i.e., with a FDT blob. In this case there are two prerequisite data
-files: vmlinux.bin.gz (Linux kernel) and target.dtb (FDT blob). The uImage can
-be produced using image source file doc/uImage.FIT/kernel_fdt.its like this
-(note again, that both prerequisite data files are assumed to be present in
-the current working directory -- image source file kernel_fdt.its can be
-modified to take the files from some other location if needed):
-
-[on the host system]
-$ mkimage -f kernel_fdt.its kernel_fdt.itb
-DTC: dts->dtb  on file "kernel_fdt.its"
-$
-$ mkimage -l kernel_fdt.itb
-FIT description: Simple image with single Linux kernel and FDT blob
-Created:	 Tue Mar 11 16:29:22 2008
- Image 0 (kernel@1)
-  Description:	Vanilla Linux kernel
-  Type:		Kernel Image
-  Compression:	gzip compressed
-  Data Size:	1092037 Bytes = 1066.44 kB = 1.04 MB
-  Architecture: PowerPC
-  OS:		Linux
-  Load Address: 0x00000000
-  Entry Point:	0x00000000
-  Hash algo:	crc32
-  Hash value:	2c0cc807
-  Hash algo:	sha1
-  Hash value:	264b59935470e42c418744f83935d44cdf59a3bb
- Image 1 (fdt@1)
-  Description:	Flattened Device Tree blob
-  Type:		Flat Device Tree
-  Compression:	uncompressed
-  Data Size:	16384 Bytes = 16.00 kB = 0.02 MB
-  Architecture: PowerPC
-  Hash algo:	crc32
-  Hash value:	0d655d71
-  Hash algo:	sha1
-  Hash value:	25ab4e15cd4b8a5144610394560d9c318ce52def
- Default Configuration: 'conf@1'
- Configuration 0 (conf@1)
-  Description:	Boot Linux kernel with FDT blob
-  Kernel:	kernel@1
-  FDT:		fdt@1
-
-
-The resulting image file kernel_fdt.itb can be now transferred to the target,
-inspected and booted:
-
-[on the target system]
-=> tftp 900000 /path/to/tftp/location/kernel_fdt.itb
-Using FEC device
-TFTP from server 192.168.1.1; our IP address is 192.168.160.5
-Filename '/path/to/tftp/location/kernel_fdt.itb'.
-Load address: 0x900000
-Loading: #################################################################
-	 ###########
-done
-Bytes transferred = 1109776 (10ef10 hex)
-=> iminfo
-
-## Checking Image at 00900000 ...
-   FIT image found
-   FIT description: Simple image with single Linux kernel and FDT blob
-   Created:	    2008-03-11	15:29:22 UTC
-    Image 0 (kernel@1)
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000ec
-     Data Size:    1092037 Bytes =  1 MB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2c0cc807
-     Hash algo:    sha1
-     Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
-    Image 1 (fdt@1)
-     Description:  Flattened Device Tree blob
-     Type:	   Flat Device Tree
-     Compression:  uncompressed
-     Data Start:   0x00a0abdc
-     Data Size:    16384 Bytes = 16 kB
-     Architecture: PowerPC
-     Hash algo:    crc32
-     Hash value:   0d655d71
-     Hash algo:    sha1
-     Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
-    Default Configuration: 'conf@1'
-    Configuration 0 (conf@1)
-     Description:  Boot Linux kernel with FDT blob
-     Kernel:	   kernel@1
-     FDT:	   fdt@1
-=> bootm
-## Booting kernel from FIT Image at 00900000 ...
-   Using 'conf@1' configuration
-   Trying 'kernel@1' kernel subimage
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000ec
-     Data Size:    1092037 Bytes =  1 MB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2c0cc807
-     Hash algo:    sha1
-     Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
-   Verifying Hash Integrity ... crc32+ sha1+ OK
-   Uncompressing Kernel Image ... OK
-## Flattened Device Tree from FIT Image at 00900000
-   Using 'conf@1' configuration
-   Trying 'fdt@1' FDT blob subimage
-     Description:  Flattened Device Tree blob
-     Type:	   Flat Device Tree
-     Compression:  uncompressed
-     Data Start:   0x00a0abdc
-     Data Size:    16384 Bytes = 16 kB
-     Architecture: PowerPC
-     Hash algo:    crc32
-     Hash value:   0d655d71
-     Hash algo:    sha1
-     Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
-   Verifying Hash Integrity ... crc32+ sha1+ OK
-   Booting using the fdt blob at 0xa0abdc
-   Loading Device Tree to 007fc000, end 007fffff ... OK
-[    0.000000] Using lite5200 machine description
-[    0.000000] Linux version 2.6.24-rc6-gaebecdfc (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sat Jan 12 15:38:48 CET 2008
-
-
-Example 3 -- advanced booting
------------------------------
-
-Refer to doc/uImage.FIT/multi.its for an image source file that allows more
-sophisticated booting scenarios (multiple kernels, ramdisks and fdt blobs).
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/kernel.its b/qemu/roms/u-boot/doc/uImage.FIT/kernel.its
deleted file mode 100644
index ef3ab8f72..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/kernel.its
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Simple U-boot uImage source file containing a single kernel
- */
-
-/dts-v1/;
-
-/ {
-	description = "Simple image with single Linux kernel";
-	#address-cells = <1>;
-
-	images {
-		kernel@1 {
-			description = "Vanilla Linux kernel";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "crc32";
-			};
-			hash@2 {
-				algo = "sha1";
-			};
-		};
-	};
-
-	configurations {
-		default = "config@1";
-		config@1 {
-			description = "Boot Linux kernel";
-			kernel = "kernel@1";
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its b/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its
deleted file mode 100644
index 7e940d2af..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Simple U-boot uImage source file containing a single kernel and FDT blob
- */
-
-/dts-v1/;
-
-/ {
-	description = "Simple image with single Linux kernel and FDT blob";
-	#address-cells = <1>;
-
-	images {
-		kernel@1 {
-			description = "Vanilla Linux kernel";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "crc32";
-			};
-			hash@2 {
-				algo = "sha1";
-			};
-		};
-		fdt@1 {
-			description = "Flattened Device Tree blob";
-			data = /incbin/("./target.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "none";
-			hash@1 {
-				algo = "crc32";
-			};
-			hash@2 {
-				algo = "sha1";
-			};
-		};
-	};
-
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			description = "Boot Linux kernel with FDT blob";
-			kernel = "kernel@1";
-			fdt = "fdt@1";
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/multi.its b/qemu/roms/u-boot/doc/uImage.FIT/multi.its
deleted file mode 100644
index 881b74952..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/multi.its
+++ /dev/null
@@ -1,133 +0,0 @@
-/*
- * U-boot uImage source file with multiple kernels, ramdisks and FDT blobs
- */
-
-/dts-v1/;
-
-/ {
-	description = "Various kernels, ramdisks and FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel@1 {
-			description = "vanilla-2.6.23";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "md5";
-			};
-			hash@2 {
-				algo = "sha1";
-			};
-		};
-
-		kernel@2 {
-			description = "2.6.23-denx";
-			data = /incbin/("./2.6.23-denx.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-
-		kernel@3 {
-			description = "2.4.25-denx";
-			data = /incbin/("./2.4.25-denx.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "md5";
-			};
-		};
-
-		ramdisk@1 {
-			description = "eldk-4.2-ramdisk";
-			data = /incbin/("./eldk-4.2-ramdisk");
-			type = "ramdisk";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-
-		ramdisk@2 {
-			description = "eldk-3.1-ramdisk";
-			data = /incbin/("./eldk-3.1-ramdisk");
-			type = "ramdisk";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash@1 {
-				algo = "crc32";
-			};
-		};
-
-		fdt@1 {
-			description = "tqm5200-fdt";
-			data = /incbin/("./tqm5200.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "none";
-			hash@1 {
-				algo = "crc32";
-			};
-		};
-
-		fdt@2 {
-			description = "tqm5200s-fdt";
-			data = /incbin/("./tqm5200s.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "none";
-			load = <00700000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-
-	};
-
-	configurations {
-		default = "config@1";
-
-		config@1 {
-			description = "tqm5200 vanilla-2.6.23 configuration";
-			kernel = "kernel@1";
-			ramdisk = "ramdisk@1";
-			fdt = "fdt@1";
-		};
-
-		config@2 {
-			description = "tqm5200s denx-2.6.23 configuration";
-			kernel = "kernel@2";
-			ramdisk = "ramdisk@1";
-			fdt = "fdt@2";
-		};
-
-		config@3 {
-			description = "tqm5200s denx-2.4.25 configuration";
-			kernel = "kernel@3";
-			ramdisk = "ramdisk@2";
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its b/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its
deleted file mode 100644
index 3c17f040d..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its
+++ /dev/null
@@ -1,45 +0,0 @@
-/dts-v1/;
-
-/ {
-	description = "Chrome OS kernel image with one or more FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel@1 {
-			data = /incbin/("test-kernel.bin");
-			type = "kernel_noload";
-			arch = "sandbox";
-			os = "linux";
-			compression = "lzo";
-			load = <0x4>;
-			entry = <0x8>;
-			kernel-version = <1>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-		fdt@1 {
-			description = "snow";
-			data = /incbin/("sandbox-kernel.dtb");
-			type = "flat_dt";
-			arch = "sandbox";
-			compression = "none";
-			fdt-version = <1>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-	};
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			kernel = "kernel@1";
-			fdt = "fdt@1";
-			signature@1 {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-				sign-images = "fdt", "kernel";
-			};
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its b/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its
deleted file mode 100644
index f69326a39..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its
+++ /dev/null
@@ -1,42 +0,0 @@
-/dts-v1/;
-
-/ {
-	description = "Chrome OS kernel image with one or more FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel@1 {
-			data = /incbin/("test-kernel.bin");
-			type = "kernel_noload";
-			arch = "sandbox";
-			os = "linux";
-			compression = "none";
-			load = <0x4>;
-			entry = <0x8>;
-			kernel-version = <1>;
-			signature@1 {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-			};
-		};
-		fdt@1 {
-			description = "snow";
-			data = /incbin/("sandbox-kernel.dtb");
-			type = "flat_dt";
-			arch = "sandbox";
-			compression = "none";
-			fdt-version = <1>;
-			signature@1 {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-			};
-		};
-	};
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			kernel = "kernel@1";
-			fdt = "fdt@1";
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/signature.txt b/qemu/roms/u-boot/doc/uImage.FIT/signature.txt
deleted file mode 100644
index 950203770..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/signature.txt
+++ /dev/null
@@ -1,400 +0,0 @@
-U-Boot FIT Signature Verification
-=================================
-
-Introduction
-------------
-FIT supports hashing of images so that these hashes can be checked on
-loading. This protects against corruption of the image. However it does not
-prevent the substitution of one image for another.
-
-The signature feature allows the hash to be signed with a private key such
-that it can be verified using a public key later. Provided that the private
-key is kept secret and the public key is stored in a non-volatile place,
-any image can be verified in this way.
-
-See verified-boot.txt for more general information on verified boot.
-
-
-Concepts
---------
-Some familiarity with public key cryptography is assumed in this section.
-
-The procedure for signing is as follows:
-
-   - hash an image in the FIT
-   - sign the hash with a private key to produce a signature
-   - store the resulting signature in the FIT
-
-The procedure for verification is:
-
-   - read the FIT
-   - obtain the public key
-   - extract the signature from the FIT
-   - hash the image from the FIT
-   - verify (with the public key) that the extracted signature matches the
-       hash
-
-The signing is generally performed by mkimage, as part of making a firmware
-image for the device. The verification is normally done in U-Boot on the
-device.
-
-
-Algorithms
-----------
-In principle any suitable algorithm can be used to sign and verify a hash.
-At present only one class of algorithms is supported: SHA1 hashing with RSA.
-This works by hashing the image to produce a 20-byte hash.
-
-While it is acceptable to bring in large cryptographic libraries such as
-openssl on the host side (e.g. mkimage), it is not desirable for U-Boot.
-For the run-time verification side, it is important to keep code and data
-size as small as possible.
-
-For this reason the RSA image verification uses pre-processed public keys
-which can be used with a very small amount of code - just some extraction
-of data from the FDT and exponentiation mod n. Code size impact is a little
-under 5KB on Tegra Seaboard, for example.
-
-It is relatively straightforward to add new algorithms if required. If
-another RSA variant is needed, then it can be added to the table in
-image-sig.c. If another algorithm is needed (such as DSA) then it can be
-placed alongside rsa.c, and its functions added to the table in image-sig.c
-also.
-
-
-Creating an RSA key and certificate
------------------------------------
-To create a new public key, size 2048 bits:
-
-$ openssl genrsa -F4 -out keys/dev.key 2048
-
-To create a certificate for this:
-
-$ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
-
-If you like you can look at the public key also:
-
-$ openssl rsa -in keys/dev.key -pubout
-
-
-Device Tree Bindings
---------------------
-The following properties are required in the FIT's signature node(s) to
-allow thes signer to operate. These should be added to the .its file.
-Signature nodes sit at the same level as hash nodes and are called
-signature@1, signature@2, etc.
-
-- algo: Algorithm name (e.g. "sha1,rs2048")
-
-- key-name-hint: Name of key to use for signing. The keys will normally be in
-a single directory (parameter -k to mkimage). For a given key <name>, its
-private key is stored in <name>.key and the certificate is stored in
-<name>.crt.
-
-When the image is signed, the following properties are added (mandatory):
-
-- value: The signature data (e.g. 256 bytes for 2048-bit RSA)
-
-When the image is signed, the following properties are optional:
-
-- timestamp: Time when image was signed (standard Unix time_t format)
-
-- signer-name: Name of the signer (e.g. "mkimage")
-
-- signer-version: Version string of the signer (e.g. "2013.01")
-
-- comment: Additional information about the signer or image
-
-For config bindings (see Signed Configurations below), the following
-additional properties are optional:
-
-- sign-images: A list of images to sign, each being a property of the conf
-node that contains then. The default is "kernel,fdt" which means that these
-two images will be looked up in the config and signed if present.
-
-For config bindings, these properties are added by the signer:
-
-- hashed-nodes: A list of nodes which were hashed by the signer. Each is
-	a string - the full path to node. A typical value might be:
-
-	hashed-nodes = "/", "/configurations/conf@1", "/images/kernel@1",
-		"/images/kernel@1/hash@1", "/images/fdt@1",
-		"/images/fdt@1/hash@1";
-
-- hashed-strings: The start and size of the string region of the FIT that
-	was hashed
-
-Example: See sign-images.its for an example image tree source file and
-sign-configs.its for config signing.
-
-
-Public Key Storage
-------------------
-In order to verify an image that has been signed with a public key we need to
-have a trusted public key. This cannot be stored in the signed image, since
-it would be easy to alter. For this implementation we choose to store the
-public key in U-Boot's control FDT (using CONFIG_OF_CONTROL).
-
-Public keys should be stored as sub-nodes in a /signature node. Required
-properties are:
-
-- algo: Algorithm name (e.g. "sha1,rs2048")
-
-Optional properties are:
-
-- key-name-hint: Name of key used for signing. This is only a hint since it
-is possible for the name to be changed. Verification can proceed by checking
-all available signing keys until one matches.
-
-- required: If present this indicates that the key must be verified for the
-image / configuration to be considered valid. Only required keys are
-normally verified by the FIT image booting algorithm. Valid values are
-"image" to force verification of all images, and "conf" to force verfication
-of the selected configuration (which then relies on hashes in the images to
-verify those).
-
-Each signing algorithm has its own additional properties.
-
-For RSA the following are mandatory:
-
-- rsa,num-bits: Number of key bits (e.g. 2048)
-- rsa,modulus: Modulus (N) as a big-endian multi-word integer
-- rsa,r-squared: (2^num-bits)^2 as a big-endian multi-word integer
-- rsa,n0-inverse: -1 / modulus[0] mod 2^32
-
-
-Signed Configurations
----------------------
-While signing images is useful, it does not provide complete protection
-against several types of attack. For example, it it possible to create a
-FIT with the same signed images, but with the configuration changed such
-that a different one is selected (mix and match attack). It is also possible
-to substitute a signed image from an older FIT version into a newer FIT
-(roll-back attack).
-
-As an example, consider this FIT:
-
-/ {
-	images {
-		kernel@1 {
-			data = <data for kernel1>
-			signature@1 {
-				algo = "sha1,rsa2048";
-				value = <...kernel signature 1...>
-			};
-		};
-		kernel@2 {
-			data = <data for kernel2>
-			signature@1 {
-				algo = "sha1,rsa2048";
-				value = <...kernel signature 2...>
-			};
-		};
-		fdt@1 {
-			data = <data for fdt1>;
-			signature@1 {
-				algo = "sha1,rsa2048";
-				vaue = <...fdt signature 1...>
-			};
-		};
-		fdt@2 {
-			data = <data for fdt2>;
-			signature@1 {
-				algo = "sha1,rsa2048";
-				vaue = <...fdt signature 2...>
-			};
-		};
-	};
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			kernel = "kernel@1";
-			fdt = "fdt@1";
-		};
-		conf@1 {
-			kernel = "kernel@2";
-			fdt = "fdt@2";
-		};
-	};
-};
-
-Since both kernels are signed it is easy for an attacker to add a new
-configuration 3 with kernel 1 and fdt 2:
-
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			kernel = "kernel@1";
-			fdt = "fdt@1";
-		};
-		conf@1 {
-			kernel = "kernel@2";
-			fdt = "fdt@2";
-		};
-		conf@3 {
-			kernel = "kernel@1";
-			fdt = "fdt@2";
-		};
-	};
-
-With signed images, nothing protects against this. Whether it gains an
-advantage for the attacker is debatable, but it is not secure.
-
-To solved this problem, we support signed configurations. In this case it
-is the configurations that are signed, not the image. Each image has its
-own hash, and we include the hash in the configuration signature.
-
-So the above example is adjusted to look like this:
-
-/ {
-	images {
-		kernel@1 {
-			data = <data for kernel1>
-			hash@1 {
-				algo = "sha1";
-				value = <...kernel hash 1...>
-			};
-		};
-		kernel@2 {
-			data = <data for kernel2>
-			hash@1 {
-				algo = "sha1";
-				value = <...kernel hash 2...>
-			};
-		};
-		fdt@1 {
-			data = <data for fdt1>;
-			hash@1 {
-				algo = "sha1";
-				value = <...fdt hash 1...>
-			};
-		};
-		fdt@2 {
-			data = <data for fdt2>;
-			hash@1 {
-				algo = "sha1";
-				value = <...fdt hash 2...>
-			};
-		};
-	};
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			kernel = "kernel@1";
-			fdt = "fdt@1";
-			signature@1 {
-				algo = "sha1,rsa2048";
-				value = <...conf 1 signature...>;
-			};
-		};
-		conf@2 {
-			kernel = "kernel@2";
-			fdt = "fdt@2";
-			signature@1 {
-				algo = "sha1,rsa2048";
-				value = <...conf 1 signature...>;
-			};
-		};
-	};
-};
-
-
-You can see that we have added hashes for all images (since they are no
-longer signed), and a signature to each configuration. In the above example,
-mkimage will sign configurations/conf@1, the kernel and fdt that are
-pointed to by the configuration (/images/kernel@1, /images/kernel@1/hash@1,
-/images/fdt@1, /images/fdt@1/hash@1) and the root structure of the image
-(so that it isn't possible to add or remove root nodes). The signature is
-written into /configurations/conf@1/signature@1/value. It can easily be
-verified later even if the FIT has been signed with other keys in the
-meantime.
-
-
-Verification
-------------
-FITs are verified when loaded. After the configuration is selected a list
-of required images is produced. If there are 'required' public keys, then
-each image must be verified against those keys. This means that every image
-that might be used by the target needs to be signed with 'required' keys.
-
-This happens automatically as part of a bootm command when FITs are used.
-
-
-Enabling FIT Verification
--------------------------
-In addition to the options to enable FIT itself, the following CONFIGs must
-be enabled:
-
-CONFIG_FIT_SIGNATURE - enable signing and verfication in FITs
-CONFIG_RSA - enable RSA algorithm for signing
-
-
-Testing
--------
-An easy way to test signing and verfication is to use the test script
-provided in test/vboot/vboot_test.sh. This uses sandbox (a special version
-of U-Boot which runs under Linux) to show the operation of a 'bootm'
-command loading and verifying images.
-
-A sample run is show below:
-
-$ make O=sandbox sandbox_config
-$ make O=sandbox
-$ O=sandbox ./test/vboot/vboot_test.sh
-Simple Verified Boot Test
-=========================
-
-Please see doc/uImage.FIT/verified-boot.txt for more information
-
-/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
-Build keys
-do sha1 test
-Build FIT with signed images
-Test Verified Boot Run: unsigned signatures:: OK
-Sign images
-Test Verified Boot Run: signed images: OK
-Build FIT with signed configuration
-Test Verified Boot Run: unsigned config: OK
-Sign images
-Test Verified Boot Run: signed config: OK
-check signed config on the host
-OK
-Test Verified Boot Run: signed config: OK
-Test Verified Boot Run: signed config with bad hash: OK
-do sha256 test
-Build FIT with signed images
-Test Verified Boot Run: unsigned signatures:: OK
-Sign images
-Test Verified Boot Run: signed images: OK
-Build FIT with signed configuration
-Test Verified Boot Run: unsigned config: OK
-Sign images
-Test Verified Boot Run: signed config: OK
-check signed config on the host
-OK
-Test Verified Boot Run: signed config: OK
-Test Verified Boot Run: signed config with bad hash: OK
-
-Test passed
-
-Future Work
------------
-- Roll-back protection using a TPM is done using the tpm command. This can
-be scripted, but we might consider a default way of doing this, built into
-bootm.
-
-
-Possible Future Work
---------------------
-- Add support for other RSA/SHA variants, such as rsa4096,sha512.
-- Other algorithms besides RSA
-- More sandbox tests for failure modes
-- Passwords for keys/certificates
-- Perhaps implement OAEP
-- Enhance bootm to permit scripted signature verification (so that a script
-can verify an image but not actually boot it)
-
-
-Simon Glass
-sjg@chromium.org
-1-1-13
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt b/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt
deleted file mode 100644
index 9ed6f65e5..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt
+++ /dev/null
@@ -1,261 +0,0 @@
-U-boot new uImage source file format (bindings definition)
-==========================================================
-
-Author: Marian Balakowicz <m8@semihalf.com>
-
-1) Introduction
----------------
-
-Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
-booting method which requires that hardware description is available to the
-kernel in the form of Flattened Device Tree.
-
-Booting with a Flattened Device Tree is much more flexible and is intended to
-replace direct passing of 'struct bd_info' which was used to boot pre-FDT
-kernels.
-
-However, U-boot needs to support both techniques to provide backward
-compatibility for platforms which are not FDT ready. Number of elements
-playing role in the booting process has increased and now includes the FDT
-blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
-in the system memory and passed to bootm as a arguments. Some of them may be
-missing: FDT is not present for legacy platforms, ramdisk is always optional.
-Additionally, old uImage format has been extended to support multi sub-images
-but the support is limited by simple format of the legacy uImage structure.
-Single binary header 'struct image_header' is not flexible enough to cover all
-possible scenarios.
-
-All those factors combined clearly show that there is a need for new, more
-flexible, multi component uImage format.
-
-
-2) New uImage format assumptions
---------------------------------
-
-a) Implementation
-
-Libfdt has been selected for the new uImage format implementation as (1) it
-provides needed functionality, (2) is actively maintained and developed and
-(3) increases code reuse as it is already part of the U-boot source tree.
-
-b) Terminology
-
-This document defines new uImage structure by providing FDT bindings for new
-uImage internals. Bindings are defined from U-boot perspective, i.e. describe
-final form of the uImage at the moment when it reaches U-boot. User
-perspective may be simpler, as some of the properties (like timestamps and
-hashes) will need to be filled in automatically by the U-boot mkimage tool.
-
-To avoid confusion with the kernel FDT the following naming convention is
-proposed for the new uImage format related terms:
-
-FIT	- Flattened uImage Tree
-
-FIT is formally a flattened device tree (in the libfdt meaning), which
-conforms to bindings defined in this document.
-
-.its	- image tree source
-.itb	- image tree blob
-
-c) Image building procedure
-
-The following picture shows how the new uImage is prepared. Input consists of
-image source file (.its) and a set of data files. Image is created with the
-help of standard U-boot mkimage tool which in turn uses dtc (device tree
-compiler) to produce image tree blob (.itb).  Resulting .itb file is the
-actual binary of a new uImage.
-
-
-tqm5200.its
-+
-vmlinux.bin.gz	   mkimage + dtc	       xfer to target
-eldk-4.2-ramdisk  --------------> tqm5200.itb --------------> bootm
-tqm5200.dtb			     /|\
-...				      |
-				 'new uImage'
-
-	- create .its file, automatically filled-in properties are omitted
-	- call mkimage tool on a .its file
-	- mkimage calls dtc to create .itb image and assures that
-	  missing properties are added
-	- .itb (new uImage) is uploaded onto the target and used therein
-
-
-d) Unique identifiers
-
-To identify FIT sub-nodes representing images, hashes, configurations (which
-are defined in the following sections), the "unit name" of the given sub-node
-is used as it's identifier as it assures uniqueness without additional
-checking required.
-
-
-3) Root node properties
------------------------
-
-Root node of the uImage Tree should have the following layout:
-
-/ o image-tree
-    |- description = "image description"
-    |- timestamp = <12399321>
-    |- #address-cells = <1>
-    |
-    o images
-    | |
-    | o img@1 {...}
-    | o img@2 {...}
-    | ...
-    |
-    o configurations
-      |- default = "cfg@1"
-      |
-      o cfg@1 {...}
-      o cfg@2 {...}
-      ...
-
-
-  Optional property:
-  - description : Textual description of the uImage
-
-  Mandatory property:
-  - timestamp : Last image modification time being counted in seconds since
-    1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
-
-  Conditionally mandatory property:
-  - #address-cells : Number of 32bit cells required to represent entry and
-    load addresses supplied within sub-image nodes. May be omitted when no
-    entry or load addresses are used.
-
-  Mandatory node:
-  - images : This node contains a set of sub-nodes, each of them representing
-    single component sub-image (like kernel, ramdisk, etc.). At least one
-    sub-image is required.
-
-  Optional node:
-  - configurations : Contains a set of available configuration nodes and
-    defines a default configuration.
-
-
-4) '/images' node
------------------
-
-This node is a container node for component sub-image nodes. Each sub-node of
-the '/images' node should have the following layout:
-
- o image@1
-   |- description = "component sub-image description"
-   |- data = /incbin/("path/to/data/file.bin")
-   |- type = "sub-image type name"
-   |- arch = "ARCH name"
-   |- os = "OS name"
-   |- compression = "compression name"
-   |- load = <00000000>
-   |- entry = <00000000>
-   |
-   o hash@1 {...}
-   o hash@2 {...}
-   ...
-
-  Mandatory properties:
-  - description : Textual description of the component sub-image
-  - type : Name of component sub-image type, supported types are:
-    "standalone", "kernel", "ramdisk", "firmware", "script", "filesystem",
-    "flat_dt".
-  - data : Path to the external file which contains this node's binary data.
-  - compression : Compression used by included data. Supported compressions
-    are "gzip" and "bzip2". If no compression is used compression property
-    should be set to "none".
-
-  Conditionally mandatory property:
-  - os : OS name, mandatory for type="kernel", valid OS names are: "openbsd",
-    "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", "solaris", "irix",
-    "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx", "u_boot",
-    "rtems", "unity", "integrity".
-  - arch : Architecture name, mandatory for types: "standalone", "kernel",
-    "firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
-    "arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
-    "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200".
-  - entry : entry point address, address size is determined by
-    '#address-cells' property of the root node. Mandatory for for types:
-    "standalone" and "kernel".
-  - load : load address, address size is determined by '#address-cells'
-    property of the root node. Mandatory for types: "standalone" and "kernel".
-
-  Optional nodes:
-  - hash@1 : Each hash sub-node represents separate hash or checksum
-    calculated for node's data according to specified algorithm.
-
-
-5) Hash nodes
--------------
-
-o hash@1
-  |- algo = "hash or checksum algorithm name"
-  |- value = [hash or checksum value]
-
-  Mandatory properties:
-  - algo : Algorithm name, supported are "crc32", "md5" and "sha1".
-  - value : Actual checksum or hash value, correspondingly 4, 16 or 20 bytes
-    long.
-
-
-6) '/configurations' node
--------------------------
-
-The 'configurations' node is optional. If present, it allows to create a
-convenient, labeled boot configurations, which combine together kernel images
-with their ramdisks and fdt blobs.
-
-The 'configurations' node has has the following structure:
-
-o configurations
-  |- default = "default configuration sub-node unit name"
-  |
-  o config@1 {...}
-  o config@2 {...}
-  ...
-
-
-  Optional property:
-  - default : Selects one of the configuration sub-nodes as a default
-    configuration.
-
-  Mandatory nodes:
-  - configuration-sub-node-unit-name : At least one of the configuration
-    sub-nodes is required.
-
-
-7) Configuration nodes
-----------------------
-
-Each configuration has the following structure:
-
-o config@1
-  |- description = "configuration description"
-  |- kernel = "kernel sub-node unit name"
-  |- ramdisk = "ramdisk sub-node unit name"
-  |- fdt = "fdt sub-node unit-name"
-
-
-  Mandatory properties:
-  - description : Textual configuration description.
-  - kernel : Unit name of the corresponding kernel image (image sub-node of a
-    "kernel" type).
-
-  Optional properties:
-  - ramdisk : Unit name of the corresponding ramdisk image (component image
-    node of a "ramdisk" type).
-  - fdt : Unit name of the corresponding fdt blob (component image node of a
-    "fdt type").
-
-The FDT blob is required to properly boot FDT based kernel, so the minimal
-configuration for 2.6 FDT kernel is (kernel, fdt) pair.
-
-Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
-'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
-not* be specified in a configuration node.
-
-
-8) Examples
------------
-
-Please see doc/uImage.FIT/*.its for actual image source files.
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/update3.its b/qemu/roms/u-boot/doc/uImage.FIT/update3.its
deleted file mode 100644
index a6eaef691..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/update3.its
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Example Automatic software update file.
- */
-
-/dts-v1/;
-
-/ {
-	description = "Automatic software updates: kernel, ramdisk, FDT";
-	#address-cells = <1>;
-
-	images {
-		update@1 {
-			description = "Linux kernel binary";
-			data = /incbin/("./vmlinux.bin.gz");
-			compression = "none";
-			type = "firmware";
-			load = <FF700000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-		update@2 {
-			description = "Ramdisk image";
-			data = /incbin/("./ramdisk_image.gz");
-			compression = "none";
-			type = "firmware";
-			load = <FF8E0000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-
-		update@3 {
-			description = "FDT blob";
-			data = /incbin/("./blob.fdt");
-			compression = "none";
-			type = "firmware";
-			load = <FFAC0000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its b/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its
deleted file mode 100644
index 846723e2d..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Automatic software update for U-Boot
- * Make sure the flashing addresses ('load' prop) is correct for your board!
- */
-
-/dts-v1/;
-
-/ {
-	description = "Automatic U-Boot update";
-	#address-cells = <1>;
-
-	images {
-		update@1 {
-			description = "U-Boot binary";
-			data = /incbin/("./u-boot.bin");
-			compression = "none";
-			type = "firmware";
-			load = <FFFC0000>;
-			hash@1 {
-				algo = "sha1";
-			};
-		};
-	};
-};
diff --git a/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt b/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt
deleted file mode 100644
index 3c83fbc2c..000000000
--- a/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-U-Boot Verified Boot
-====================
-
-Introduction
-------------
-Verified boot here means the verification of all software loaded into a
-machine during the boot process to ensure that it is authorised and correct
-for that machine.
-
-Verified boot extends from the moment of system reset to as far as you wish
-into the boot process. An example might be loading U-Boot from read-only
-memory, then loading a signed kernel, then using the kernel's dm-verity
-driver to mount a signed root filesystem.
-
-A key point is that it is possible to field-upgrade the software on machines
-which use verified boot. Since the machine will only run software that has
-been correctly signed, it is safe to read software from an updatable medium.
-It is also possible to add a secondary signed firmware image, in read-write
-memory, so that firmware can easily be upgraded in a secure manner.
-
-
-Signing
--------
-Verified boot uses cryptographic algorithms to 'sign' software images.
-Images are signed using a private key known only to the signer, but can
-be verified using a public key. As its name suggests the public key can be
-made available without risk to the verification process. The private and
-public keys are mathematically related. For more information on how this
-works look up "public key cryptography" and "RSA" (a particular algorithm).
-
-The signing and verification process looks something like this:
-
-
-      Signing                                      Verification
-      =======                                      ============
-
- +--------------+                   *
- | RSA key pair |                   *             +---------------+
- | .key  .crt   |                   *             | Public key in |
- +--------------+       +------> public key ----->| trusted place |
-       |                |           *             +---------------+
-       |                |           *                    |
-       v                |           *                    v
-   +---------+          |           *              +--------------+
-   |         |----------+           *              |              |
-   | signer  |                      *              |    U-Boot    |
-   |         |----------+           *              |  signature   |--> yes/no
-   +---------+          |           *              | verification |
-      ^                 |           *              |              |
-      |                 |           *              +--------------+
-      |                 |           *                    ^
- +----------+           |           *                    |
- | Software |           +----> signed image -------------+
- |  image   |                       *
- +----------+                       *
-
-
-The signature algorithm relies only on the public key to do its work. Using
-this key it checks the signature that it finds in the image. If it verifies
-then we know that the image is OK.
-
-The public key from the signer allows us to verify and therefore trust
-software from updatable memory.
-
-It is critical that the public key be secure and cannot be tampered with.
-It can be stored in read-only memory, or perhaps protected by other on-chip
-crypto provided by some modern SOCs. If the public key can ben changed, then
-the verification is worthless.
-
-
-Chaining Images
----------------
-The above method works for a signer providing images to a run-time U-Boot.
-It is also possible to extend this scheme to a second level, like this:
-
-1. Master private key is used by the signer to sign a first-stage image.
-2. Master public key is placed in read-only memory.
-2. Secondary private key is created and used to sign second-stage images.
-3. Secondary public key is placed in first stage images
-4. We use the master public key to verify the first-stage image. We then
-use the secondary public key in the first-stage image to verify the second-
-state image.
-5. This chaining process can go on indefinitely. It is recommended to use a
-different key at each stage, so that a compromise in one place will not
-affect the whole change.
-
-
-Flattened Image Tree (FIT)
---------------------------
-The FIT format is alreay widely used in U-Boot. It is a flattened device
-tree (FDT) in a particular format, with images contained within. FITs
-include hashes to verify images, so it is relatively straightforward to
-add signatures as well.
-
-The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in
-a standard place. Then when a FIT it loaded it can be verified using that
-public key. Multiple keys and multiple signatures are supported.
-
-See signature.txt for more information.
-
-
-Simon Glass
-sjg@chromium.org
-1-1-13