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>

2 files changed, 0 insertions, 144 deletions

diff --git a/qemu/roms/u-boot/doc/SPL/README.am335x-network b/qemu/roms/u-boot/doc/SPL/README.am335x-network
deleted file mode 100644
index 9b63791ad..000000000
--- a/qemu/roms/u-boot/doc/SPL/README.am335x-network
+++ /dev/null
@@ -1,92 +0,0 @@
-USING AM335x NETBOOT FEATURE
-
- Some boards (like TI AM335x based ones) have quite big on-chip RAM and
-have support for booting via network in ROM. The following describes
-how to setup network booting and then optionally use this support to flash
-NAND and bricked (empty) board with only a network cable.
-
- I. Building the required images
-  1. You have to enable generic SPL configuration options (see
-doc/README.SPL) as well as CONFIG_SPL_NET_SUPPORT,
-CONFIG_ETH_SUPPORT, CONFIG_SPL_LIBGENERIC_SUPPORT and
-CONFIG_SPL_LIBCOMMON_SUPPORT in your board configuration file to build
-SPL with support for booting over the network. Also you have to enable
-the driver for the NIC used and CONFIG_SPL_BOARD_INIT option if your
-board needs some board-specific initialization (TI AM335x EVM does).
-If you want SPL to use some Vendor Class Identifier (VCI) you can set
-one with CONFIG_SPL_NET_VCI_STRING option. am335x_evm configuration
-comes with support for network booting preconfigured.
- 2. Define CONFIG_BOOTCOMMAND for your board to load and run debrick
-script after boot:
-#define CONFIG_BOOTCOMMAND					\
-	"setenv autoload no; "					\
-	"bootp; "						\
-	"if tftp 80000000 debrick.scr; then "			\
-		"source 80000000; "				\
-	"fi"
-(Or create additional board configuration with such option).
- 3. Build U-Boot as usual
-  $ make <your_board_name>
-    You will need u-boot.img and spl/u-boot.bin images to perform
-network boot. Copy them to u-boot-restore.img and
-u-boot-spl-restore.bin respectively to distinguish this version
-(with automatic restore running) from the main one.
-
- II. Host configuration.
-  1. Setup DHCP server (recommended server is ISC DHCPd).
-   - Install DHCP server and setup it to listen on the interface you
-chose to connect to the board (usually configured in
-/etc/default/dhcpd or /etc/default/isc-dhcp-server). Make sure there
-are no other active DHCP servers in the same network segment.
-   - Edit your dhcpd.conf and subnet declaration matching the address
-on the interface. Specify the range of assigned addresses and bootfile
-to use. IMPORTANT! Both RBL and SPL use the image filename provided
-in the BOOTP reply but obviously they need different images (RBL needs
-raw SPL image -- u-boot-spl-restore.bin while SPL needs main U-Boot
-image -- u-boot-restore.img). So you have to configure DHCP server to
-provide different image filenames to RBL and SPL (and possibly another
-one to main U-Boot). This can be done by checking Vendor Class
-Identifier (VCI) set by BOOTP client (RBL sets VCI to "DM814x ROM v1.0"
-and you can set VCI used by SPL with CONFIG_SPL_NET_VCI_STRING option,
-see above).
-   - If you plan to use TFTP server on another machine you have to set
-server-name option to point to it.
-   - Here is sample configuration for ISC DHCPd, assuming the interface
-used to connect to the board is eth0, and it has address 192.168.8.1:
-
-subnet 192.168.8.0 netmask 255.255.255.0 {
-  range dynamic-bootp 192.168.8.100 192.168.8.199;
-
-  if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" {
-    filename "u-boot-spl-restore.bin";
-  } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
-    filename "u-boot-restore.img";
-  } else {
-    filename "uImage";
-  }
-}
-
-  2. Setup TFTP server.
-     Install TFTP server and put image files to it's root directory
-(likely /tftpboot or /var/lib/tftpboot or /srv/tftp). You will need
-u-boot.img and spl/u-boot-spl-bin files from U-Boot build directory.
-
- III. Reflashing (debricking) the board.
-  1. Write debrick script. You will need to write a script that will
-be executed after network boot to perform actual rescue actions. You
-can use usual U-Boot commands from this script: tftp to load additional
-files, nand erase/nand write to erase/write the NAND flash.
-
-  2. Create script image from your script. From U-Boot build directory:
-
-$ ./tools/mkimage -A arm -O U-Boot -C none -T script -d <your script> debrick.scr
-
-This will create debrick.scr file with your script inside.
-
-  3. Copy debrick.scr to TFTP root directory. You also need to copy
-there all the files your script tries to load via TFTP. Example script
-loads u-boot.img and MLO. You have to create these files doing regular
-(not restore_flash) build and copy them to tftpboot directory.
-
-  4. Boot the board from the network, U-Boot will load debrick script
-and run it after boot.
diff --git a/qemu/roms/u-boot/doc/SPL/README.omap3 b/qemu/roms/u-boot/doc/SPL/README.omap3
deleted file mode 100644
index c77ca4300..000000000
--- a/qemu/roms/u-boot/doc/SPL/README.omap3
+++ /dev/null
@@ -1,52 +0,0 @@
-Overview of SPL on OMAP3 devices
-================================
-
-Introduction
-------------
-
-This document provides an overview of how SPL functions on OMAP3 (and related
-such as am35x and am37x) processors.
-
-Methodology
------------
-
-On these platforms the ROM supports trying a sequence of boot devices.  Once
-one has been used successfully to load SPL this information is stored in memory
-and the location stored in a register.  We will read this to determine where to
-read U-Boot from in turn.
-
-Memory Map
-----------
-
-This is an example of a typical setup.  See top-level README for documentation
-of which CONFIG variables control these values.  For a given board and the
-amount of DRAM available to it different values may need to be used.
-Note that the size of the SPL text rodata and data is enforced with a CONFIG
-option and growing over that size results in a link error.  The SPL stack
-starts at the top of SRAM (which is configurable) and grows downward.  The
-space between the top of SRAM and the enforced upper bound on the size of the
-SPL text, data and rodata is considered the safe stack area.  Details on
-confirming this behavior are shown below.
-
-A portion of the system memory map looks as follows:
-SRAM: 0x40200000 - 0x4020FFFF
-DDR1: 0x80000000 - 0xBFFFFFFF
-
-Option 1 (SPL only):
-0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
-0x4020E000 - 0x4020FFFC: Area for the SPL stack.
-0x80000000 - 0x8007FFFF: Area for the SPL BSS.
-0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot
-0x80208000 - 0x80307FFF: malloc() pool available to SPL.
-
-Option 2 (SPL or X-Loader):
-0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
-0x4020E000 - 0x4020FFFC: Area for the SPL stack.
-0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
-0x87000000 - 0x8707FFFF: Area for the SPL BSS.
-0x87080000 - 0x870FFFFF: malloc() pool available to SPL.
-
-For the areas that reside within DDR1 they must not be used prior to s_init()
-completing.  Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL
-uses while running.  This is why we have two versions of the memory map that
-only vary in where the BSS and malloc pool reside.