This script automates the booting of QEMU using an nfsroot exported
by our userspace NFS tools. The rootfs should be created using
poky-extract-sdk.
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
This script automates the exporting of a root filesystem (created
with the poky-extract-sdk utility) using pseudo and the native
userspace NFS server. That filesystem can then be booted using
nfsroot with either QEMU or the target hardware using one of our
kernels.
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
This script automates the creation of a rootfs area using pseudo so
it can be used by a QEMU nfsroot boot.
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Various poky scripts make use of binaries from the native sysroot.
This helper script can be used to reduce code duplication, and sets
up some environment variables you can use to identify and obtain
the correct filesystem path to the native sysroot.
It works for both in-tree Poky setups as well as toolchain
installations.
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
TUNSETGROUP is needed in order to preconfigure a set of tap devices
that can be used by non-root users. The requirement is that the qemu
users be members of whatever group the tap devices are assigned to.
Include tunctl in the qemu-helper package, and add a -native version.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
You need to first set up the build directory by sourcing the poky build script,
after that builds can be run in that directory so long as bitbake is in $PATH
removing the need to source the init script for each build.
i.e:
$ . poky-init-build-env ~/my-build
$ bitbake some-image
<<later, in a different shell>>
$ cd ~/my-build
$ export PATH=/path/to/bitbake/bin:$PATH
$ bitbake an-image
This patch also removes use of OEROOT in recipes, etc.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
In order to force 0.12.4 to allow a powerpc system boot, we need
a patch to qemu, and a new powerpc (not ppc) ROM.
This configuration supports non-graphical booting only, since the
ROM does not have support to pass a graphics device via the
device tree yet.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
VMware SVGA presents to the guest with the depth of the host surface it renders
to, and rejects to work if the two sides are mismatched. One problem is that
current VMware VGA may calculate a wrong host depth, and then memcpy from virtual
framebuffer to host surface may trigger segmentation fault. For example, when
launching Qemu in a VNC connection, VMware SVGA thinks depth as '32', however the
actual depth of VNC is '16'. The fault also happens when the host depth is not
32 bit.
Qemu <4b5db3749c5fdba93e1ac0e8748c9a9a1064319f> tempts to fix a similar issue, by
changing from hard-coded 24bit depth to instead query the surface allocator
(e.g. sdl). However it doesn't really work, because the point where query
is invoked is earlier than the point where sdl is initialized. At query time,
qemu uses a default surface allocator which, again, provides another hard-coded
depth value - 32bit. So it happens to make VMware SVGA working on some hosts,
but still fails in others.
To solve this issue, this commit introduces a postcall interface to display
surface, which is walked after surface allocators are actually initialized.
At that point it's then safe to query host depth and present to the guest.
Signed-off-by Kevin Tian <kevin.tian@intel.com>
Due to different stack contents in sdl_display_init on Ubuntu vs other distros,
an uninitialized structure is causing a crash. Zeroing the structure makes the
behavior uniform across distros, avoiding the Ubuntu crash, but doesn't fix the
underlying bugs, notably:
the return value of SDL_GetWMInfo needs to be checked, as it's currently
failing silently
the underlying reason for the failure of SDL_GetWMInfo needs to be found -
there is a GetWMINfo method in the internal SDL structure which is NULL, and
the reason for this needs to be found.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Fedora 13 switched the default behaviour of the linker to no longer
indirectly link to required libraries (i.e. dependencies of a library
already linked to). Therefore we need to explicitly pass the depended on
libraries into the linker for building to work on Fedora 13.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Renamed the recipe to 0.12.4.
Moved the patches directory to qemu-0.12.4 - when it was named
qemu-0.12, bitbake silently ignored the patches, and only failed when
it came time to apply them.
Added a FILESDIR to the git recipe and changed its PV to 0.12.4 so it
can use the same patches as the normal recipe for now.
Removed the series file - it wasn't needed.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
qemu-native was failing to link on my 64bit Fedora 13 machine with this error:
| /usr/bin/ld: libqemu.a(helper_opengl.o): undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
| /usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line
| /lib64/libdl.so.2: could not read symbols: Invalid operation
So I did as the linker told me and added -ldl to the linker flags
Signed-off-by: Joshua Lock <josh@linux.intel.com>
There's no need to carry around two copies of the same patches for qemu-git and
qemu-0.12 so drop the qemu-git directory and update the git recipe to use the
qemu-0.12 directory for patches.
Move common code from the two recipes to an inc file.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
fweh
qemu-native requires a libGL and the SDL development headers to build with our
GL "emulation". This patch adds a check before configure for the native package
to ensure that the sdl.pc file and GL so files exist and bombs out otherwise.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
