Age | Commit message (Collapse) | Author |
|
* this is goog enough (still ugly) to build core-image-base with all components except
the kernel (and kernel dependencies) with 32bit multilib config (i586 DEFAULTTUNE) and
kernel with new 64bit DEFAULTTUNE core2-64 as shown in WORKDIR distribution:
all-oe-linux:
autoconf-archive run-postinsts update-rc.d
core2-64-oe-linux:
defaultpkgname glibc glibc-initial glibc-locale libgcc-initial linux-libc-headers qemuwrapper-cross
i586-oemllib32-linux:
lib32-alsa-lib lib32-gcc-runtime lib32-libgpg-error lib32-libxml2 lib32-renderproto
lib32-alsa-state lib32-gdbm lib32-libical lib32-libxrender lib32-rpcbind
lib32-alsa-utils lib32-glib-2.0 lib32-libice lib32-linux-libc-headers lib32-shadow
lib32-attr lib32-glibc lib32-libidn lib32-mobile-broadband-provider-info lib32-shadow-sysroot
lib32-avahi lib32-glibc-initial lib32-libnl lib32-modutils-initscripts lib32-shared-mime-info
lib32-base-passwd lib32-glibc-locale lib32-libnss-mdns lib32-ncurses lib32-sqlite3
lib32-bash lib32-gmp lib32-libogg lib32-neard lib32-sysvinit
lib32-bash-completion lib32-gnutls lib32-libpcre lib32-netbase lib32-tcp-wrappers
lib32-bluez5 lib32-gobject-introspection lib32-libpng lib32-nettle lib32-util-linux
lib32-busybox lib32-icu lib32-libpthread-stubs lib32-ofono lib32-util-macros
lib32-bzip2 lib32-initscripts lib32-libsamplerate0 lib32-openssl lib32-wireless-tools
lib32-cairo lib32-inputproto lib32-libsm lib32-opkg-utils lib32-wpa-supplicant
lib32-cryptodev-linux lib32-iw lib32-libsndfile1 lib32-pciutils lib32-xcb-proto
lib32-dbus lib32-kbproto lib32-libtirpc lib32-pixman lib32-xextproto
lib32-dbus-glib lib32-kmod lib32-libtool-cross lib32-psplash lib32-xproto
lib32-e2fsprogs lib32-libcap lib32-libunistring lib32-python3 lib32-xtrans
lib32-eudev lib32-libcheck lib32-libvorbis lib32-python3-dbus lib32-xz
lib32-expat lib32-libdaemon lib32-libx11 lib32-python3-pycairo lib32-zlib
lib32-flac lib32-libffi lib32-libxau lib32-python3-pygobject
lib32-fontconfig lib32-libgcc lib32-libxcb lib32-python3-setuptools
lib32-freetype lib32-libgcc-initial lib32-libxdmcp lib32-quota
lib32-gawk lib32-libgcrypt lib32-libxext lib32-readline
qemux86-oe-linux:
core-image-base depmodwrapper-cross linux-yocto
qemux86-oemllib32-linux:
lib32-base-files lib32-packagegroup-base lib32-shadow-securetty lib32-v86d
lib32-init-ifupdown lib32-packagegroup-core-boot lib32-sysvinit-inittab
x86_64-linux:
alsa-lib-native e2fsprogs-native kmod-native makedevs-native python3-setuptools-native
attr-native elfutils-native ldconfig-native mklibs-native qemu-helper-native
autoconf-archive-native expat-native lib32-binutils-cross-i686 mpfr-native qemu-native
autoconf-native file-native lib32-gcc-cross-i686 ncurses-native quilt-native
automake-native flex-native lib32-gcc-cross-initial-i686 ninja-native re2c-native
bc-native gcc-cross-initial-x86_64 libarchive-native nspr-native readline-native
binutils-cross-x86_64 gcc-cross-x86_64 libffi-native nss-native rpm-native
binutils-native gdbm-native libmpc-native openssl-native shadow-native
bison-native gettext-minimal-native libpcre-native opkg-native shared-mime-info-native
bzip2-native gettext-native libpng-native opkg-utils-native sqlite3-native
cmake-native glib-2.0-native libsolv-native pbzip2-native texinfo-dummy-native
cross-localedef-native gmp-native libtool-native perl-native unifdef-native
cryptodev-linux-native gnu-config-native libxml2-native pigz-native unzip-native
curl-native gobject-introspection-native libxml-parser-perl-native pixman-native update-rc.d-native
db-native gperf-native libxslt-native pkgconfig-native util-linux-native
dbus-glib-native gtk-doc-native lzo-native popt-native util-macros-native
dbus-native icu-native lzop-native prelink-native xproto-native
dtc-native intltool-native m4-native pseudo-native xz-native
dwarfsrcfiles-native kern-tools-native makedepend-native python3-native zlib-native
* there are still some issues though:
* update-rc.d.bbclass adds dependency on 64bit update-rc.d and initscripts
to allarch recipes (where multilib class_extend doesn't apply)
* glibc-locale is 64bit, because virtual/ providers aren't correctly expanded
to have MLPREFIX, changed bash to do that
and still there is
RDEPENDS=" lib32-packagegroup-core-boot lib32-packagegroup-base-extended run-postinsts lib32-psplash locale-base-en-us locale-base-en-gb"
in bitbake -e core-image-base, bitbake -e lib32-core-image-base was failing, because
nothing provides locale-base-* packages, fixed by adding MLPREFIX to PACKAGES_DYNAMIC
* kernel and kernel modules are built as 32bit: causing package_qa failure:
ERROR: linux-yocto-4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0 do_package_qa: QA Issue: Architecture did not match (x86, expected x86-64) on /work/qemux86-oe-linux/linux-yocto/4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0/packages-split/kernel-module-ip6-tunnel-4.15.3-yocto-standard/lib/modules/4.15.3-yocto-standard/kernel/net/ipv6/ip6_tunnel.ko [arch]
....
ERROR: QA Issue: Architecture did not match (x86, expected x86-64) on /work/qemux86-oe-linux/linux-yocto/4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0/packages-split/kernel-vmlinux/boot/vmlinux-4.15.3-yocto-standard [arch]
the parameters look OK:
KERNEL_CC="x86_64-oe-linux-gcc -fuse-ld=bfd -fdebug-prefix-map=/jenkins/mjansa/build-nodistro-master/BUILD/work/qemux86-oe-linux/linux-yocto/4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0=/usr/src/debug/linux-yocto/4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0 -fdebug-prefix-map=/jenkins/mjansa/build-nodistro-master/BUILD/work/qemux86-oe-linux/linux-yocto/4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0/recipe-sysroot-native= -fdebug-prefix-map=/jenkins/mjansa/build-nodistro-master/BUILD/work/qemux86-oe-linux/linux-yocto/4.15.3+gitAUTOINC+030f397472_a6a3a6a73d-r0/recipe-sysroot= -fdebug-prefix-map=/jenkins/mjansa/build-nodistro-master/BUILD/work-shared/qemux86/kernel-source=/usr/src/kernel"
KERNEL_LD="x86_64-oe-linux-ld.bfd "
KERNEL_EXTRA_ARGS=""
but I need to set KMACHINE in order to actually generate .config from qemux86-64
to select 64bit config options
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
|
I am not sure if this has ever worked, but uvesafb is a really
outdated (VBE from the 1990s), awkward (needs v86d) and limited
(no support for high resolutions) way to do it.
The specific reason 640x480-32 was introduced (ages ago) was
to force 32 bit mode with vmware driver, as 16bit had rendering issues.
The modern, supported option is video=... kernel parameter documented here:
https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID
https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst
which can be passed directly to runqemu and doesn't require special
kernel modules.
Sato under X will continue to use 640x480 as that is hardcoded into
xorg.conf under qemu.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is the qemu default since qemu 2.2, is generally supported better,
and is recommended by upstream. It also has already been in use for arm/risc
and ovmf.
Additional information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
'-vga virtio' emulated hardware remains in use when virgl is enabled via a runqemu override.
Also, adjust the error whitelist, as there is a number of new messages
coming from the drivers that are not actual errors.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Configrations:
MACHINE: qemux86-64
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
Reproduce steps:
bitbake lib32-core-image-minimal
runqemu qemux86-64 nographic lib32-core-image-minimal
Errors:
qemu cannot bootup since:
Booting from ROM...
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.
QEMU: Terminated
For lib32 image, override has x86, so the qemubin set to qemu-system-i386,
fix by move QB_SYSTEM_NAME to corresponding conf, don't use the override
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This matches what the qemux86_64 is currently using, and
will allow testing the instructions added in the meantime;
particularly various SSE extensions are now enabled.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Allows the qemux86 machine to be tuned all the way up to an i7 if
desired by overriding DEFAULTTUNE. The default if unspecified is left at
i586.
This can be useful for enabling advanced processor features like SSE if
desired or required by various packages.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Beautify the machine config files by making the names and descriptions
more uniform and verbose
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
configuration
If you try to build a system with multiple BSPs, one of which is qemux86
or qemux86-64, the gstreamer package will change. This will trigger
anything using gstream to also be rebuilt.
For a package based system, the PR values will also be incremented each
time. The end result will be an ever growing set of PR values as well as
being unable to tell which configured version of the multimedia components
are really being deployed.
These therefore belong in the machine configuration.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add U-Boot machine configuration for the qemux86 and qemux86-64
to allow building U-Boot on those targets. This in turn allows
the auto-updater to update the U-Boot recipe.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Ross Burton <ross.burton@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When runqemu is invoked with an image type (wic, hddimg etc) as a parameter,
the kernel value and command line parameters from qemuboot.conf
are ignored and not passed to qemu cmdline.
As an example, when using:
$ runqemu wic kvm
It results in no network interface and video mode warnings when qemu is up because
the -kernel and -append options were not passed.
Change qemu conf to use qemux86-directdisk.wks that supplies the kernel parameters
that are appended to the bootloader configuration when generating qemu wic
images instead of relying on qemuboot.conf.
Fixes [YOCTO #12224]
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
After commit e8b1c653946ef921b65d47e52aea0dc530ef4286, we started seeing
errors like the following during boot on genericx86 machines:
uvesafb: failed to execute /sbin/v86d
uvesafb: probe of uvesafb.0 failed with error -22
uvesafb: vbe_init() failed with -22
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
These were caused because the uvesa module was being loaded during boot,
when it is only meant to be loaded on qemu according to:
6af89812e8a9931ffed63768ed85367519bf7aef
Since genericx86-common.inc includes qemuboot-x86, the module also tries
to be loaded on genericx86 machines, this patch removes the instruction from
qemuboot-x86 and adds it in specific to both qemux86 machines confs so
it is correctly loaded only on those.
[YOCTO #11879]
(From OE-Core rev: 261f9c382121c73b72556a151fdd4c7938b32a92)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
lspci and some other software require "pci" in MACHINE_FEATURES and PCI
is valid in the qemux86* context.
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Changed dependency task for syslinux from do_build to
do_populate_sysroot as do_build dependency caused conflicts in
populating image recipe sysroot using conflicting recipes. This
makes do_image_wic task to fail with FileExistsError trying to
copy the same file from two conflicting recipes.
This should also speed up image creation a bit as do_populate_sysroot
task is faster than do_build.
[YOCTO #11295]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A follow-up of a fix introduced in
1b32c6ed025745cb06b7c28ca0fe9e416ce7abfa (selftest: wic: fix test_qemu).
Wic test_qemu fails on qemux86 due to a direct assignment of WKS_FILE in machine
configuration. Using default assignment allows WKS_FILE to be overwritten in
test setup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Use weak assignment for SERIAL_CONSOLES in qemu configuration files so that
the value could serve as a default value and could be easily overridden in
configuration files like local.conf.
When using the default value for SERIAL_CONSOLES in qemux86-64,we would have
annoying messages on console complaining about respawning getty on ttyS1.
Although the value is set by purpose, at least we need to provide an easy way
to override it.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Set directdisk.wks as default wks to use for qemux86 machines.
Set requried dependeincies to build directdisk image.
This should simplify building wic images for qemux86* machines.
It should be enough to add wic to the list of IMAGE_FSTYPES to get
the images built.
[YOCTO #10637, YOCTO #8719]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Don't install legacy X input drivers for any machines by default,
RRECOMMEND xf86-input-libinput instead.
This is the setup suggested by upstream: install only libinput by
default, but let niche legacy drivers sort higher in configuration
so they get chosen if installed. So the order is:
evdev < libinput < (synaptics|vmmouse|...)
This also removes vmmouse X driver from the qemu config. If a VMware
virtual mouse device really needs to be supported, we should enable
CONFIG_MOUSE_PS2_VMMOUSE in kernel instead: that is directly supported
by the libinput X driver.
Fixes [YOCTO #10195].
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Add qemuboot-x86.inc to reduce duplicated code, the x86/x86_64 bsps
which can be boot by runqemu can require qemuboot-x86.inc.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
musl doesn't like lazy loading that xorg uses, therefore
load the needed modules explicitly
[YOCTO #10169]
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
* The Xorg server needs to load the GLX extension in order to
enable proper OpenGL support.
* Before this patch, glxinfo aborted with:
root@qemux86:~# glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
* After this patch, it works as expected:
root@qemux86:~# glxinfo | grep " render"
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
qemu can freeze and stop responding if the socket buffer connected to a tcp
serial connection fills up. This happens of course when the reader of
the serial data doesn't actually read it.
This happened in the qemurunner code, because after checking for the
"login:" sentinel, data was never again read from the serial connection.
This patch solves the potential freeze by adding a thread to continuously
read the data from the console and log it. So it also will give a full log
of the console, rather than just up to the login prompt.
To simplify this patch, another serial port was also added to use for the
sole purpose of watching for the sentinel as well as being the interactive
serial port. This will also prevent the possibility of lots of debug
data on the console preventing the sentinel value from being seen due to
interleaved text.
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware,
and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86 image,
the image can be made to launch an X server on when cirrus and std are chosen,
in addition to just vmware. (The build of QEMU in OE-Core appears to have QXL
disabled, meaning a driver for it is unnecessary.)
The runqemu script now allows the choice of emulated VGA adapter to be
specified manually, so it's important that qemux86 supports any configuration
the user might choose without requiring the image to be rebuilt.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The base_contains is kept as a compatibility method and we ought to
not use it in OE-Core so we can remove it from base metadata in
future.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled,
mesa-driver-swrast has to be conditional in the QEMU machine defintions too.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Because the qemu.inc is now included before the XSERVER assignment, the
xf86-video-vmware and xf86-video-vmmouse are not built and the X for
qemux86 and qemux86-64 does not start.
[YOCTO #4124]
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
OVERRIDES reads from left to right, least to most specific. We were
appending to MACHINEOVERRIDES when we should have been prepending so
the ordering of qemuall verses qemuxxx was incorrect, as was the x86
override and several of the arm overrides. This patch is a batch cleanup
of the various issues to correct the order from least to most specific.
The include order does matter and we needed to tweak some of that in this
patch too.
[YOCTO #4090]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Rename mesa-dri recipes to just mesa. Also, replace all references to
mesa-dri in all recipes/configs.
The reason for this renaming (quote from bugzilla):
"mesa-dri is a artefact of mesa-xlib existing, which doesn't anymore.
mesa-dri should be renamed to mesa."
[YOCTO #3385]
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
nptl and thereby tls are not optional anymore
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Wihtout it, you have both mesa-dri and mesa-xlib as providers. Let's
prefer the accelerated version.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
qemu.inc does a straight assign to MACHINE_FEATURES so overwriting the
preceding append to MACHINE_FEATURES, so the MACHINE_FEATURES append
needs to be moved after the include.
This situation came about as a result of commit 71a4bf386:
qemumachines: Enable xserver-xorg as default xserver
For qemux86 and qemux86-64 include qemu.inc after defining XSERVER
which missed this side-effect (and maybe others).
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
|
|
For qemux86 and qemux86-64 include qemu.inc after defining XSERVER
XSERVER variable is also weakly defined in task-core-x11.bb
which means we can not use ??= otherwise when building any qemu image
that uses task-core-x11.bb will get the wrong definition
So we define the XSERVER common set for qemu in qemu.inc
and as we know x86 and x86-64 qemu overrides the default
we include qemu.inc after that definition which means that
qemux86 and qemux86-64 get their own definitions and other
qemus get the definitions from qemu.inc. other non-qemu machine
will get their defintion from task which points to kdrive
as of now.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Still need mesa-xlib for emulation of GLX interface on qemuarm/mips/ppc, where
mesa-dri doesn't work for pure qemu emulator.
[YOCTO #2066] fixed.
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Machines shouldn't be poking around PREFERRED_PROVIDERS which aren't
machine specific or at least machine safe. Kernels are machine specific
and the xserver is selectable. libx11 and mesa are now really a distro choice
and machine configurations shouldn't be poking around them as it just leads
to corruption, conflicts and confusion.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* xserver-xorg is closer to upstream naming and
that's how it's named in OE-classic and meta-oe? It would make meta-oe
transition easier and better to do it now then convert meta-oe to
xserver-xf86 and then rename it back later.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
|
There is currently consideradble confusion over how the tune files operate
and how these interact with the rest of the build system. This update/overhaul
changes things so the tune files are primarily resonsible for setting:
TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value that
represents the architecture we're targetting.
TUNE_PKGARCH - The value that represents the tune confuration that this set
of tune parameters results in.
This allows the significant improvement that the core can now always determine
the target architecture value, even when TARGET_ARCH needs to be reset to
something different and likewise, there is one package architecture variable
the core can reference allowing simplification of the BASE_PACKAGE_ARCH, PACKAGE_ARCH
and FEED_ARCH variables.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
and drop specific distro config
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This gets us closer to making including tune-<arch>.inc "just work".
Moving the TARGET_ARCH definitions is something for a follup patch.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The different kernel recipes encapsulate functionality groups for machines,
therefore it makes sense to have all the QEMU machines using the same kernel
recipe.
Switch the QEMU machines to default to the "linux" recipes for their kernel
and bump the latest recipe from linux-2.6.32 to 2.6.33.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
|
|
Change the virtual/xserver preferred provider in qemu.inc to a soft assign and
set preferred provider in qemux86 before the require so that the value is retained.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
|
|
mesa-dri as the GL provider and drop synaptics input driver
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@3916 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@3530 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@3458 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
machines
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@2599 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@2388 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@1903 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@1132 311d38ba-8fff-0310-9ca6-ca027cbcb966
|