Use config_<machine> to split the code into separate functions, so that
different machines won't affect each other, and they will have a better
structure.
(From OE-Core rev: 6098a72e8d21f6321636e727703ca7c29d9af142)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* remove akita and spitz related code
They are not supported by runqemu anymore:
$ runqemu spitz
Error: unable to classify arg [spitz]
So remove related code.
* Remove checking of 256M for qemuarm, qemu can check it, for example:
$ runqemu qemuarm qemuparams="-m 1024"
[snip]
qemu: Too much memory for this machine: 1024 MB, maximum 256 MB
[snip]
(From OE-Core rev: 36fb785bf8cd2f387c91d52f597602a5dbc3948b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 69a1fca4374797dea56035ce56a17441a2ca9280)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* So that we can add more image support easliy.
* I think that wic should be vm images.
(From OE-Core rev: 82d0014a0e1526ffa1ff7c8ea3903aeae31bada4)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Make it can boot scsi and virtio block drive such as root=/dev/sdX and
/dev/vdX.
* Drop VM from help info, id doesn't work, and the script can check
whether it is a vm disk or not.
* Make it can be run by:
$ runqemu tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.vmdk
or:
$ runqemu qemux86-64 vmdk
[YOCTO #9170]
(From OE-Core rev: 88c081b10902ec52928be78ad320c474bb918e01)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have an issue with PAT handling on older processes with limited PAT bits,
see the patch description for the full problem. This replaces the runqemu
workaround with a kernel patch until we can get the kernel trees sorted
out and discuss a proper fix with upstream. It should be safe everywhere
so is applied unconditionally.
(From OE-Core rev: e00f0794a535c8e68ae1c87c8b01dd65645d570b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Wic images should be boot as is, without pointing qemu to the kernel
binary. Current code doesn't use kernel, but sets KERNEL variable and
shows kernel path in the console output. This can confuse users.
Changed runqemu and runqemu-internal code to avoid setting KERNEL
variable and show kernel path.
(From OE-Core rev: 474caa7ed5ff05caa5d49d270b283882fa616ed1)
(From OE-Core rev: 35e776e00cce25f2c9c45500612fb66022ec4739)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quemu should be able to run wic images this way:
runqemu <machine> <image recipe> wic
Tested with 'runqemu qemux86-64 wic-image-minimal wic'
(From OE-Core rev: 8716be799949cb8bde7fa49cbea61312a3a93bb7)
(From OE-Core rev: dd42931bf99b8bbd4ad452b3941d957f41b81796)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the upgrade of qemux86 to 4.4.1 we're seeing PAT issues when
starting the X server. We need to fix the problem but the failing
sanity tests mask out other issues and we need a workaround.
Merge this for now until we can figure out the full issue. This is
better than changing the kernel defconfig or reverting to old
kernel versions.
(From OE-Core rev: 2749ba318bf322cb5014689532372473004e92b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When booting weston-core-image with latest wayland/weston/libinput
mouse/touchpad would not work on qemux86, this fixes the issue
(From OE-Core rev: 4abf18a25ccb1a062a3775be1a70eaf6c155349c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable virtio usage for default in runqemu also get rid
of duplicate configuration from now all qemu machines uses
virtio.
[YOCTO #8427]
(From OE-Core rev: 0611321c9d6663493b37c33dea51e05511db4fbe)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KVM can be used without vhost so add a new option to runqemu for
use kvm with vhost.
Example,
runqemu qemux86 core-image-minimal kvm # kvm without vhost
runqemu qemux86 core-image-minimal kvm-vhost # kvm with vhost
[YOCTO #7443]
(From OE-Core rev: 7f5f8f87a4180a2b05188047c6a05da5571f94e2)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We are experiencing occasional segfaults in scsi sym53c8xx driver
on qemuarm boot. There are some old discussions into the mailing
lists [1] about the scsi problem and seems to be isn't fixed.
We use virtio blk/net devices into qemuarm64 also are supported
into qemuarm so change to use it because virtio devices are the best
choice.
[YOCTO #8060]
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060#c10
(From OE-Core rev: bbfb3cd06e0ff5661ef3732ebfffa74b94400cd9)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since inittab for qemu images now always tries to start getty on a
second serial device, make sure that device exists.
Otherwise the following message will be spammed:
INIT: Id "S1" respawning too fast: disabled for 5 minutes
[YOCTO #8374]
(From OE-Core rev: 988369afed85281f3ed9b2f3eeb30f5408498bb9)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setup the qemumicroblaze machine to use the device tree provided by QEMU
instead of the device tree located in the images directory. Additionally
setup the default memory size to match the QEMU device tree.
(From OE-Core rev: 5830519bc10fa1195789d5b6a1b1bbbef4b940be)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch brings the qemu networking setup for qemuzynq and
qemumicroblaze into feature parity with the other qemu machines.
Specifically enabling TAP interface attachcment and kernel command line
IP configuration.
(From OE-Core rev: 49bdfab6ba1d92d8f48ce9c63d796a7cedf4f247)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it possible to boot images with multiple partitions (the
ones ending in .hddimg or .hdddirect) in several ways:
runqemu qemux86 core-image-minimal hddimg
runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg
VM=tmp-glibc/deploy/images/qemux86/iot-os-image-qemux86.hddimg FSTYPE=hddimg runqemu
Same for hdddirect.
This is useful for testing initramfs scripts, secure boot (when
switching to UEFI), or boot loaders like syslinux. For testing the
content of the rootfs, the ext4 image is better because that approach
is faster (no need to create another large image during build, rootfs
can be read directly instead of reading boot.img through loop device).
When booting a live image, the kernel, initramfs (if any) and kernel
parameters are taken from the image by the virtual machine's BIOS, so any
additional kernel parameters given to runqemu are ignored. This can be
avoided (already without this change) in a slightly hacky runqemu setup:
ROOTFS=tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg \
FSTYPE=ext4 \
KERNEL=tmp/deploy/images/qemux86/bzImage-initramfs-qemux86.bin \
MACHINE=qemux86 \
runqemu serial kvm nographic 'bootparams=root=/dev/ram0'
The additional bzImage-initramfs-qemux86.bin kernel here was created
by adding this to local.conf:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"
In the code, the new FSTYPE=hddimg resp. hdddirect behaves almost
exactly like the older vmdk FSTYPE. New types were chosen because it
seemed cleaner than using FSTYPE=vmdk when the actual image pointed to
by VM is not in that format. The downside is that several checks for
FSTYPE=vmdk had to be duplicated for FSTYPE=hddimg.
The VM variable now gets interpreted as "virtual machine disk image"
instead of "vmdk image".
(From OE-Core rev: 37741c539f5d3021e59828b49e968cd42b89a368)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If $TCPSERIAL_PORTNUM is empty string causes an error because
expands the expresion to,
$TCPSERIAL_PORTNUM == "" -> == ""
(From OE-Core rev: 7bbe24f19e6005eccefd404b3a6d5d9443dd5b36)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If this is not the case, sometimes the additional tcpserial will be
enumerated as ttyS0, which is not what we want. Because then it would be
the console, and qemurunner would not log things properly.
(From OE-Core rev: c71309616a3247cfab969b74d8642ff0bf9b6500)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The option was added so that the qemurunner could start a second tcp
serial port without adding machine conditional logic to qemurunner.
The issue that made this necessary was that when "virt" is passed to
qemu-system-aarch64, the normal mechanism for specifying a tcp serial
port does not work. This is because the hardware for the "virt" machine
is hardcoded in the device tree blob and the addition devices must be
virtio devices.
So runqemu can specify virtio for qemuarm64 whereas it seems all other
qemu machines work with the "-serial tcp*" option.
(From OE-Core rev: 849d65d55e4df5fa443b2cb7b4cee23913fc9d5a)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ip list can return devices in the form tapX@NONE. If it does so,
ensure we handle that case correctly. Newer distros appear to do
this in some cases.
[YOCTO #8129]
(From OE-Core rev: 6459dde380febce24d2c355d441d9cb3b14409b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In theory the code reduces the tap device number to an integer. This
patch adds error checking to ensure that does happen and that the script
exits if something unexpected happens.
(From OE-Core rev: 4238f3b6e320969aaf539e6afb1cb2bfd61bb28b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Starting with qemu 2.4, a disk needs be attached via a specified
interface, even if that interface is none. In case of qemuarm64
machine, the board is virtual, so a none interface it works
correctly.
(From OE-Core rev: 7151dc110ef87518034fdcd7d85cbebdc76013ab)
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemu guesses via probing the format of root FS, but
gives a warning and restricts write operations on block 0.
Fix it by setting correctly the format as raw for more
machines and non-KVM machines.
In some cases, replaced the way machine disk is set for qemu.
Fix for [YOCTO #7918]
(From OE-Core rev: 6f7144ebe2da4c72ef58280e034b2cc75331a471)
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use "-nographic" option only if "serial" option is not
specified. Otherwise we get below error when
'runqemu <kernel_image> <rootfs_image> serial' is executed,
(snip)
QEMU 2.2.0 monitor - type 'help' for more information
(qemu) qemu-system-aarch64: -serial stdio: cannot use stdio by multiple
character devices
-- CUT --
(From OE-Core rev: 8b0527951ab71c4a4dc4d1238cd9e9e60a6eb5ee)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add console=ttyAMA0,115200 as one of the boot parameters
for qemuarm, in order to print bootlog messages on the
console.
(From OE-Core rev: 2d2db8f517ea719f097c957559175a07ecee82ad)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemu guesses via probing the format of root FS, but
gives a warning and restricts write operations on block 0.
So fix it by setting correctly the format as raw.
(From OE-Core rev: 1da6bd7fce9c193c7940a7294baa370fd8b66e76)
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
poky-tiny generates cpio.gz images, add support for these so we can boot
them using runqemu.
(From OE-Core rev: fdd2e0c1baa80106d26236cb734e0d9a98e3fdac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the change to ext4 filesystems for qemu, we get boot warnings from where
it tried to mount the ext4 fileystem as ext2 and ext3 first.
Avoid these by specifying the rootfs type directly on the kernel commandline
for ext* images.
(From OE-Core rev: ad9f54a5014f2d997165d0cfd6ad7c05e62f315b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If tap0 interface has been created by other users on the system, we would
get error messages when using runqemu. Error messages are like below.
Acquiring lockfile for tap0...
touch: cannot touch ‘/tmp/qemu-tap-locks/tap0.lock’: Permission denied
/buildarea2/chenqi/poky/scripts/runqemu-internal: line 139: /tmp/qemu-tap-locks/tap0.lock: Permission denied
flock: 8: Bad file descriptor
The system can still boot up because runqemu would try to create a new tap
interface. So the error message above is harmless, yet somewhat annoying.
This patch fixes the above problem. With this patch, the output would be as
follows.
Acquiring lockfile for tap0...
Acquiring lockfile for /tmp/qemu-tap-locks/tap0.lock failed
Setting up tap interface under sudo
Acquiring lockfile for tap1...
Running qemu-system-arm...
(From OE-Core rev: 039c57257c4180b0688fc2ec1b03948276009b04)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Increase memory to 512M for qemuarm64. The original size 126M can't make
task testimage pass, neither 256M.
[YOCTO #7102]
(From OE-Core rev: 93979b2d025cf318fd0d867ed730721c7594d33b)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This brings qemuarm64 into feature parity with the other qemu machines
and enables the automated testing on the autobuilder.
(From OE-Core rev: 31e259f2f2a83c26b8a62b6d7dbca010c6db16bf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update scripts runqemu and runqemu-internal to support to boot
qemuarm64.
(From OE-Core rev: 2f020b53bdb8c262e432bc4df35101fa990c460c)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need this kernel command parameter so that when we start a ramfs
image, we can actually get some output. Although we can make this
happen by specifying the 'bootparams' for the 'runqemu' command, it's
better to make this the default behaviour.
(From OE-Core rev: 3d202594bb92fe75cd70f81345e64c2179b52c32)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support the sitauation where a user could have another VM running
which uses tap devices. To prevent runqemu from trying to use the
same tap device, runqemu will skip using a tap device if it finds
a filename tapX.skip within its lock directory.
This fixes [YOCTO #5815]
(From OE-Core rev: 2e490f3b08176b20fe41c64cf17ecf3b5af61f39)
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that the tune for qemux86-64 changed to core2-64 we need to
tell the emulator to use a proper CPU model. With the default setting
of qemu64 we'll get things like:
root@qemux86-64:~# smart --help
traps: python[758] trap invalid opcode ip:7f2af01f6be7 sp:7fff49466ef0 error:0 in strop.so[7f2af01f5000+6000]
Illegal instruction
If the tune for qemux86 changes, that needs to be updated too.
(From OE-Core rev: e6ade33a6f52434e884dd97549b8ac731347d9ad)
Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default slirp address for the NFS server is 10.0.2.2. If not
using a tap interface this address must be used or the target system
cannot connect properly. Also the ip=... kernel arguments need to be
set to dhcp when using slirp or the root NFS will not get setup
properly.
The call to cleanup() results in a routine which is not defined when
setting up the NFS because it is called before acquire() for the
locking of the tap interfaces, the solution being to simply not call
cleanup() that early.
When using slirp, kvm should not execute the vhost net checks because
the vhost net will not be configure or used.
(From OE-Core rev: 1ea04d87525f26c2cd32ba29c0f14c6226f60729)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This new version correctly handles the 64bit ext3 / ext4 issues we
were seeing with the older unfs-server which did not handle 64bit file
systems correctly, producing the duplicate cookies.
[YOCTO #5639]
(From OE-Core rev: 2a59d55f712bbd79b1edf3ccb90ccabf609c9f0d)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
At the moment, the user cannot to set -vga other then vmware
(because "vmware" is set by default); and the first argument
in qemuparams has higher precedence.
(From OE-Core rev: 54a43397c48c974570e3eade55163eb766994a55)
Signed-off-by: Valentin Popa <valentin.popa@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following commit, 6ccd4d6, increased the RAM size for qemu machines
to 256MB due to some smart sanity tests failing on autobuilder because
more memory was needed.
Unfortunately this leads to various, potentially dangerous, issues like
the one observed during sudoku-savant project compilation:
collect: relinking
collect2: error: '_ZNK6sudoku5ClearINS_6SquareEEclERS1_' was assigned to
'board.rpo', but was not defined during recompilation, or vice versa
board.o:(.rodata+0x8): undefined reference to
`sudoku::Clear<sudoku::Square>::operator()(sudoku::Square&) const'
board.o:(.rodata+0x20): undefined reference to
`sudoku::Clear<sudoku::Sequence>::operator()(sudoku::Sequence&) const'
board.o:(.rodata+0x34): undefined reference to `typeinfo for
sudoku::Action<sudoku::Sequence>'
...AND THE LIST CONTINUES...
collect2: error: ld returned 1 exit status
make: *** [sudoku-savant] Error 1
After some tests, I found that the maximum amount of memory needed for
sudoku to compile properly is 146MB(!?!).
My attempts to create a simpler test case (using templates), in order to
replicate and isolate the issue failed. All the tests compiled just
fine.
So, my guess is that this problem is certainly memory related but the
cause might be hidden in any of the following: qemu versatile hw model,
in the kernel or, highly unlikely but not impossible, the toolchain
itself. The reason I don't really think the cause is in the toolchain is
the fact that the compilation completes just fine for 128MB on qemuarm but
also on other qemu machines (with 256MB of memory).
Since this issue might need lots of time to have a proper fix, I'll revert back
to using 128MB for qemuarm for the time being.
[YOCTO #5133]
(From OE-Core rev: 06605bd6ddd4d6a788e1a107dcf15dde1027c094)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set memory size to 256M for qemuarm, qemux86, qemux86-64, qemumips,
qemumips64, and qemuppc.
This allows the smart automated tests to run on machines with a GUI
environment (such as Sato) running at the same time, for which 128M is
too limiting. Setting this in runqemu allows users manually using
runqemu to avoid the same out-of-memory issues under similar conditions
using smart, on-target compilation or other uses.
Fixes [YOCTO #5045].
(From OE-Core rev: fe5dfdece98692f8fa731c8d11c907a272266ea5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should provide the user more information if a preconfigured tap
is used. This is because the user might have manually set up the tap
interface to be used by other qemu binaries.
So at a minimum, we should let the user know how to make runqemu skip
that tap interface.
[YOCTO #5047]
(From OE-Core rev: ec08d92641cc51c567cc3745937b1839d3faa095)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu-ifup and runqemu-ifdown should be pairs. If we're using a
preconfigured tap interface, the runqemu-ifdown should not be invoked
to bring it down.
(From OE-Core rev: f60f215f74b5fe5a43943c9d3ccdbe0fa06b7828)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The QEMUOPTIONS for ISOFS was not complete, leading to failures when
trying to start X in live images.
This patch fixes this problem.
[YOCTO #4103]
[YOCTO #4884]
(From OE-Core rev: 08947869917dc5a9dfff05b0ee19279f60cf6d2b)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add support to boot the 'qemumicroblaze' machine in
qemu-system-microblazeel
* Use the specific machine model for a MicroBlaze system 'petalogix-ml605'
* Use the DTB generated from the kernel build as the DTB for boot
* Force use of initrd rootfs (either in ext or cpio formats)
(From OE-Core rev: 2c164a5dfc877d180ef58d46c063573621297929)
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add support to boot the 'qemuzynq' machine in qemu-system-arm
* Use the specific machine model for Zynq 'xilinx-zynq-a9'
* Use the DTB generated from the kernel build as the DTB for boot
* Force use of initrd rootfs (either in ext or cpio formats)
(From OE-Core rev: 1e4b1d95e1f47654e928f38cd091ffe272689844)
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
stty manual says :
"sane - Resets all modes to reasonable values for interactive terminal use."
But reasonable isn't the most viable solution, because we want to keep the
original stty settings before running runqemu. Saving the stty settings and
setting them at the end of the runqemu script solves the terminal
settings differences after the script ran.
[Yocto #4512]
(From OE-Core rev: 93e0ae68d2c1827370f4f9e95c2f0b7f98ba2cb8)
Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com>
[Added filename info in commit subject - sgw]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu script now takes argument "slirp" in order to
run networking on the qemu machine, without root privileges.
changed the runqemu-internal script in order not to activate
the tap devices if the option is set.
[YOCTO #1474]
(From OE-Core rev: fa7fd7b1cbcfbd01af1949d2ea09b880a0ae0175)
Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Robert Yang
Richard Purdie
Ed Bartosh
Khem Raj
Aníbal Limón
Randy Witt
Nathan Rossi
Patrick Ohly
Cristian Iorga
Jagadeesh Krishnanjanappa
Chen Qi
Kai Kang
Scott Garman
Stefan Stanacar
Jason Wessel
Saul Wold
Valentin Popa
Laurentiu Palcu
Paul Eggleton
Nathan Rossi
Andrei Dinu