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>

1 files changed, 0 insertions, 95 deletions

diff --git a/qemu/roms/u-boot/doc/README.update b/qemu/roms/u-boot/doc/README.update
deleted file mode 100644
index a7f4d9ebe..000000000
--- a/qemu/roms/u-boot/doc/README.update
+++ /dev/null
@@ -1,95 +0,0 @@
-Automatic software update from a TFTP server
-============================================
-
-Overview
---------
-
-This feature allows to automatically store software updates present on a TFTP
-server in NOR Flash. In more detail: a TFTP transfer of a file given in
-environment variable 'updatefile' from server 'serverip' is attempted during
-boot. The update file should be a FIT file, and can contain one or more
-updates. Each update in the update file has an address in NOR Flash where it
-should be placed, updates are also protected with a SHA-1 checksum. If the
-TFTP transfer is successful, the hash of each update is verified, and if the
-verification is positive, the update is stored in Flash.
-
-The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro:
-
-#define CONFIG_UPDATE_TFTP		1
-
-
-Note that when enabling auto-update, Flash support must be turned on.  Also,
-one must enable FIT and LIBFDT support:
-
-#define CONFIG_FIT		1
-#define CONFIG_OF_LIBFDT	1
-
-The auto-update feature uses the following configuration knobs:
-
-- CONFIG_UPDATE_LOAD_ADDR
-
-  Normally, TFTP transfer of the update file is done to the address specified
-  in environment variable 'loadaddr'. If this variable is not present, the
-  transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000
-  by default).
-
-- CONFIG_UPDATE_TFTP_CNT_MAX
-  CONFIG_UPDATE_TFTP_MSEC_MAX
-
-  These knobs control the timeouts during initial connection to the TFTP
-  server. Since a transfer is attempted during each boot, it is undesirable to
-  have a long delay when a TFTP server is not present.
-  CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for
-  the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX
-  gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must
-  be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be
-  positive and is 100 by default.
-
-Since the update file is in FIT format, it is created from an *.its file using
-the mkimage tool. dtc tool with support for binary includes, e.g. in version
-1.2.0 or later, must also be available on the system where the update file is
-to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT
-images.
-
-This mechanism can be also triggered by the commmand "fitupd".
-If an optional, non-zero address is provided as argument, the TFTP transfer
-is skipped and the image at this address is used.
-The fitupd command is enabled by CONFIG_CMD_FITUPD.
-
-
-Example .its files
-------------------
-
-- doc/uImage.FIT/update_uboot.its
-
-  A simple example that can be used to create an update file for automatically
-  replacing U-Boot image on a system.
-
-  Assuming that an U-Boot image u-boot.bin is present in the current working
-  directory, and that the address given in the 'load' property in the
-  'update_uboot.its' file is where the U-Boot is stored in Flash, the
-  following command will create the actual update file 'update_uboot.itb':
-
-  mkimage -f update_uboot.its update_uboot.itb
-
-  Place 'update_uboot.itb' on a TFTP server, for example as
-  '/tftpboot/update_uboot.itb', and set the 'updatefile' variable
-  appropriately, for example in the U-Boot prompt:
-
-  setenv updatefile /tftpboot/update_uboot.itb
-  saveenv
-
-  Now, when the system boots up and the update TFTP server specified in the
-  'serverip' environment variable is accessible, the new U-Boot image will be
-  automatically stored in Flash.
-
-  NOTE: do make sure that the 'u-boot.bin' image used to create the update
-  file is a good, working image. Also make sure that the address in Flash
-  where the update will be placed is correct. Making mistake here and
-  attempting the auto-update can render the system unusable.
-
-- doc/uImage.FIT/update3.its
-
-  An example containing three updates. It can be used to update Linux kernel,
-  ramdisk and FDT blob stored in Flash. The procedure for preparing the update
-  file is similar to the example above.