The Qemu version present in readme.txt files was needed when
the Buildroot's Qemu defconfig was tested manually using the
qemu-system-<arch> binary already present on the host.
This information is now incorrect since we are using host-qemu
package, currently at 4.2.0 version, to do a runtime test since
0c79350638.
For m68k-q800, we can use the upstream qemu since 4.2.0 release
[1].
So, remove this line from the readme.txt.
[1] https://www.qemu.org/2019/12/13/qemu-4-2-0/
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Linux version are changed to the new LTS kernel 5.4.35 for all qemu
defconfigs, except for riscv and csky. Thoses defconfigs are left
unchanged because they require either a custom Linux repository
or a specific kernel header version causing some difficulties when
upgrading to 5.4.35.
Update the nios2-10m50 linux.fragment to update the .dtb build directory
due to a change in kernel 4.20 [1]:
nios2: build .dtb files in dts directory
Align nios2 with other architectures which build the dtb files in the
same directory as the dts files. This is also in line with most other
build targets which are located in the same directory as the source.
This move will help enable the 'dtbs' target which builds all the dtbs
regardless of kernel config.
This transition could break some scripts if they expect dtb files in
the old location.
For x86 and x86_64 kernel, add the CONFIG_PCI symbol due a change in kernel
5.0 [2]. The option was previously enabled by default (default y).
PCI: consolidate PCI config entry in drivers/pci
There is no good reason to duplicate the PCI menu in every architecture.
Instead provide a selectable HAVE_PCI symbol that indicates availability
of PCI support, and a FORCE_PCI symbol to for PCI on and the handle the
rest in drivers/pci.
Update the kernel of ppc-mac99 defconfig added in Buildroot 2019.08.
This version bump was tested on gitlab [4] using the newly introduced
boot-qemu-image.py script [5].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=118864869805123bf82d666062542440a0fda5dd
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb01d42a77785ff96b6e66a2a2e7027fc6d78e4a
[3] a8fac3fcfc
[4] https://gitlab.com/kubu93/buildroot/pipelines/139819874
[5] 0c79350638
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit add the name of the Qemu defconfig file after each
qemu command line in order to retrieve it easily.
Since a readme.txt can be shared between several Qemu defconfig, we
need at least one qemu command line in readme.txt for each defconfig.
For now, ignore the qemu_arm_vexpress_tz_defconfig since it fail to build
due to python script issue [1]. Anyway the arm vexpress boot is tested
with qemu_arm_vexpress_defconfig.
[1] http://lists.busybox.net/pipermail/buildroot/2020-February/273738.html
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The current Buildroot defconfigs for qemu_x86 and qemu_x86_64
instantiate a console on tty1, which appears on QEMU's
graphical window. Add a console on the serial port (ttyS0) to
be used later for gitlab testing.
This change is need since the script used for gitlab testing
needs to use a serial output with pexpect.
This change is similar to the one made for raspberrypi [1] to
handle HDMI and serial console:
This requires three changes:
1. have two 'console=' entries in the kernel command line: tty1,
then ttyS0;
2. change BR2_TARGET_GENERIC_GETTY_PORT to "console", so it starts
a getty on the last console= passed to the kernel, ttyS0;
3. add a new getty on tty1 to the generated inittab.
Step 2 is actually obtained by removing BR2_TARGET_GENERIC_GETTY_PORT
entirely from the defconfigs, since "console" is the default value.
Step 3 requires a post-build script since the Buildroot makefiles can
configure only one console.
Note: instead of simply adding a new getty on ttyS0 (which would
work) this patch actually changes BR2_TARGET_GENERIC_GETTY_PORT to
instantiate a console on UART, then adds back tty1 via
post-build.sh. This is done only to avoid the "GENERIC_SERIAL" comment
where we instantiate a console on QEMU graphical window, then
instantiate a really-serial console on another line.
The result is these two inittab lines:
console::respawn:/sbin/getty -L console 0 vt100 # GENERIC_SERIAL
tty1::respawn:/sbin/getty -L tty1 0 vt100 # QEMU graphical window
[1] 20878a1017
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On my machine, it happens once in a while that the virtualised machine
boots too fast for the rootfs to be available at the time the kernel
tries to mount it.
For example, board/qemu/arm-vexpress/readme.txt suggested changing
"-smp 1" up to "-smp 4". But doing so here causes a kernel panic:
VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
1f00 131072 mtdblock0
(driver?)
1f01 32768 mtdblock1
(driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
So, add the oh-so-useful 'rootwait' option to all kernel command lines
for qemu defconfigs.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Mark Corbin <mark.corbin@embecosm.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
All linux configs are renamed to a version neutral filename
to avoid further renaming on kernel bumps.
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.16.7 2.12.0 YES OK
arm_versatile 4.16.7 2.12.0 YES OK
arm_versatile_nommu 4.16.7 2.12.0 YES OK (3)
arm_vexpress 4.16.7 2.12.0 YES OK
m68k_mcf5208 4.16.7 2.12.0 YES OK
m68k_q800 4.16.7 q800-v2.11.0 NO (2) OK
microblazebe 4.16.7 2.12.0 YES OK
microblazeel 4.16.7 2.12.0 YES OK
mips32r2el_malta 4.16.7 2.12.0 YES OK
mips32r2_malta 4.16.7 2.12.0 YES OK
mips32r6el_malta 4.16.7 2.12.0 YES OK
mips32r6_malta 4.16.7 2.12.0 YES OK
mips64el_malta 4.16.7 2.12.0 YES OK
mips64_malta 4.16.7 2.12.0 YES OK
mips64r6el_malta 4.16.7 2.12.0 YES OK
mips64r6_malta 4.16.7 2.12.0 YES OK
nios2-10m50 4.16.7 2.12.0 NO OK
or1k 4.16.7 2.12.0 NO OK
ppc_g3beige 4.16.7 2.12.0 YES OK
ppc_mpc8544ds 4.16.7 2.12.0 YES OK
ppc_virtex_ml507 4.16.7 2.12.0 NO OK
ppc64_pseries 4.16.7 2.12.0 YES OK
ppc64le_pseries 4.16.7 2.12.0 YES OK
ppc64_e5500 4.16.7 2.12.0 YES OK
sh4 4.16.7 2.12.0 YES OK
sh4eb 4.16.7 2.12.0 NO (1) OK
sparc_ss10 4.16.7 2.12.0 YES OK
sparc64_sun4u 4.16.7 2.12.0 YES OK
x86 4.16.7 2.12.0 YES OK
x86_64 4.16.7 2.12.0 YES OK
xtensa_lx60 4.16.7 2.12.0 YES OK
xtensa_lx60_nommu 4.16.7 2.12.0 YES OK
(1) - Probably an endian issue with 8139 emulation/driver
(2) - There's a network interface, but enabling it in qemu fails
(3) - Kernel patch required, switched to devicetree usage
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The ORC unwinder requires libelf to be available on the host, so use
the frame pointer unwinder instead. Using the frame pointer unwinder
is probably good enough in our default Qemu configurations.
Wireless support ends up enabling CONFIG_SYSTEM_TRUSTED_KEYRING, which
requires openssl to be available on the host, so disable wireless
support, which isn't needed in Qemu.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This helps the toolchains.free-electrons.com build logic re-use
directly the Qemu command lines from this readme.txt file, by having a
-append option similar to the ones used in other readme.txt files.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Xtensa patches no longer required, the make target name changed
to Image. The Qemu binary for OpenRisc was renamed upstream.
I removed the x86->x86_64 symlink, independent files preferred.
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.11.3 2.9.0 YES OK
arm_versatile 4.11.3 2.9.0 YES OK
arm_versatile_nommu 4.4.70 2.9.0 YES OK
arm_vexpress 4.11.3 2.9.0 YES OK
m68k_mcf5208 4.11.3 2.9.0 YES OK
m68k_q800 4.11.3 q800-v2.4.0 NO (2) OK
microblazebe 4.11.3 2.9.0 YES OK
microblazeel 4.11.3 2.9.0 YES OK
mips32r2el_malta 4.11.3 2.9.0 YES OK
mips32r2_malta 4.11.3 2.9.0 YES OK
mips32r6el_malta 4.11.3 2.9.0 YES OK
mips32r6_malta 4.11.3 2.9.0 YES OK
mips64el_malta 4.11.3 2.9.0 YES OK
mips64_malta 4.11.3 2.9.0 YES OK
mips64r6el_malta 4.11.3 2.9.0 YES OK
mips64r6_malta 4.11.3 2.9.0 YES OK
nios2-10m50 4.11.3 2.9.0 NO OK
or1k 4.11.3 2.9.0 NO OK (5)
ppc_g3beige 4.11.3 2.9.0 YES OK
ppc_mpc8544ds 4.11.3 2.9.0 YES OK
ppc_virtex_ml507 4.9.6 2.9.0 NO OK (3)
ppc64_pseries 4.11.3 2.9.0 YES OK
sh4 4.9.6 2.9.0 YES OK (4)
sh4eb 4.9.6 2.9.0 NO (1) OK (4)
sparc_ss10 4.11.3 2.9.0 YES OK
sparc64_sun4u 4.11.3 2.9.0 YES OK
sparc_sun4u 4.11.3 2.9.0 YES OK
x86 4.11.3 2.9.0 YES OK
x86_64 4.11.3 2.9.0 YES OK
xtensa_lx60 4.11.3 2.9.0 YES OK
xtensa_lx60_nommu 4.11.3 2.9.0 YES OK
(1) - Probably an endian issue with 8139 emulation/driver
(2) - There's a network interface, but enabling it in qemu fails
(3) - Kernel oops with 4.11.3 on boot
(4) - System is extremely slow with 4.11.3, needs further investigation
(5) - Qemu binary got renamed to qemu-system-or1k
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also bump the pc samples since they're tied to the (base) qemu config.
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.9.6 2.6.0 YES OK (3)
arm_versatile 4.9.6 2.5.0 YES OK
arm_versatile_nommu 4.4.45 2.5.0 YES OK
arm_vexpress 4.9.6 2.5.0 YES OK
m68k_mcf5208 4.8.17 2.5.0 YES OK (6)
m68k_q800 4.9.6 q800-v2.4.0 NO (2) OK
microblazebe 4.9.6 2.5.0 YES OK
microblazeel 4.9.6 2.5.0 YES OK
mips32r2el_malta 4.9.6 2.5.0 YES OK
mips32r2_malta 4.9.6 2.5.0 YES OK
mips32r6el_malta 4.9.6 2.6.0 YES OK (3)
mips32r6_malta 4.9.6 2.6.0 YES OK (3)
mips64el_malta 4.9.6 2.5.0 YES OK
mips64_malta 4.8.17 2.5.0 YES OK (6)
mips64r6el_malta 4.9.6 2.7.0 YES OK (3)(4)
mips64r6_malta 4.9.6 2.7.0 YES OK (3)(4)
nios2-10m50 4.9.6 2.9.0 NO OK
or1k 4.9.6 2.5.0 NO OK
ppc_g3beige 4.9.6 2.5.0 YES OK
ppc_mpc8544ds 4.9.6 2.5.0 YES OK
ppc_virtex_ml507 4.9.6 2.5.0 NO OK
ppc64_pseries 4.9.6 2.5.0 YES OK
sh4 4.9.6 2.5.0 YES OK
sh4eb 4.9.6 2.5.0 NO (1) OK
sparc_ss10 4.9.6 2.5.0 YES OK
sparc64_sun4u 4.9.6 2.5.0 YES OK
sparc_sun4u 4.9.6 2.5.0 YES OK
x86 4.9.6 2.5.0 YES OK
x86_64 4.9.6 2.5.0 YES OK
xtensa_lx60 4.8.17 2.6.0 YES OK (6)
xtensa_lx60_nommu 4.8.17 2.6.0 YES OK (5)
(1) - Probably an endian issue with 8139 emulation/driver
(2) - There's a network interface, but enabling it in qemu fails
(3) - Known to fail with qemu versions lower than 2.6.0
(4) - Might work with 2.6.0, but the cpu definition changed in 2.7.0
(5) - Kept back on 4.8.x series since 4.9.x fails to build
(6) - Kept back on 4.8.x series since 4.9.x fails to boot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop m68k-mcf5208 kernel patch since it's upstream.
Also bump the pc samples since they're tied to the (base) qemu config.
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.8.1 2.6.0 YES OK (3)
arm_versatile 4.8.1 2.5.0 YES OK
arm_vexpress 4.8.1 2.5.0 YES OK
m68k_mcf5208 4.8.1 2.5.0 YES OK
m68k_q800 4.8.1 q800-v2.4.0 NO (2) OK
microblazebe 4.8.1 2.5.0 YES OK
microblazeel 4.8.1 2.5.0 YES OK
mips32r2el_malta 4.8.1 2.5.0 YES OK
mips32r2_malta 4.8.1 2.5.0 YES OK
mips32r6el_malta 4.8.1 2.6.0 YES OK (3)
mips32r6_malta 4.8.1 2.6.0 YES OK (3)
mips64el_malta 4.8.1 2.5.0 YES OK
mips64_malta 4.8.1 2.5.0 YES OK
mips64r6el_malta 4.8.1 2.7.0 YES OK (3)(4)
mips64r6_malta 4.8.1 2.7.0 YES OK (3)(4)
ppc_g3beige 4.8.1 2.5.0 YES OK
ppc_mpc8544ds 4.8.1 2.5.0 YES OK
ppc_virtex_ml507 4.8.1 2.5.0 NO OK
ppc64_pseries 4.8.1 2.5.0 YES OK
sh4 4.8.1 2.5.0 YES OK
sh4eb 4.8.1 2.5.0 NO (1) OK
sparc_ss10 4.8.1 2.5.0 YES OK
sparc64_sun4u 4.8.1 2.5.0 YES OK
sparc_sun4u 4.8.1 2.5.0 YES OK
x86 4.8.1 2.5.0 YES OK
x86_64 4.8.1 2.5.0 YES OK
xtensa_lx60 4.8.1 2.6.0 YES OK
xtensa_lx60_nommu 4.8.1 2.6.0 YES OK
(1) - Probably an endian issue with 8139 emulation/driver
(2) - There's a network interface, but enabling it in qemu fails
(3) - Known to fail with qemu versions lower than 2.6.0
(4) - Might work with 2.6.0, but the cpu definition changed in 2.7.0
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also bump the pc samples since they're tied to the (base) qemu config.
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.7 2.6.0 YES OK (3)
arm_versatile 4.7 2.5.0 YES OK
arm_vexpress 4.7 2.5.0 YES OK
m68k_mcf5208 4.7 2.5.0 YES OK
m68k_q800 4.7 q800-v2.4.0 NO (2) OK
microblazebe 4.7 2.5.0 YES OK
microblazeel 4.7 2.5.0 YES OK
mips32r2el_malta 4.7 2.5.0 YES OK
mips32r2_malta 4.7 2.5.0 YES OK
mips32r6el_malta 4.7 2.6.0 YES OK (3)
mips32r6_malta 4.7 2.6.0 YES OK (3)
mips64el_malta 4.7 2.5.0 YES OK
mips64_malta 4.7 2.5.0 YES OK
mips64r6el_malta 4.7 2.6.0 YES OK (3)
mips64r6_malta 4.7 2.6.0 YES OK (3)
ppc_g3beige 4.7 2.5.0 YES OK
ppc_mpc8544ds 4.7 2.5.0 YES OK
ppc_virtex_ml507 4.7 2.5.0 NO OK
ppc64_pseries 4.7 2.5.0 YES OK
sh4 4.7 2.5.0 YES OK
sh4eb 4.7 2.5.0 NO (1) OK
sparc_ss10 4.7 2.5.0 YES OK
sparc64_sun4u 4.7 2.5.0 YES OK
sparc_sun4u 4.7 2.5.0 YES OK
x86 4.7 2.5.0 YES OK
x86_64 4.7 2.5.0 YES OK
xtensa_lx60 4.7 2.6.0 YES OK
xtensa_lx60_nommu 4.7 2.6.0 YES OK
(1) - Probably an endian issue with 8139 emulation/driver
(2) - There's a network interface, but enabling it in qemu fails
(3) - Known to fail with qemu versions lower than 2.6.0
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Also bump the pc samples since they're tied to the (base) qemu config.
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.5.6 2.5.0 YES OK (4)
arm_versatile 4.6.1 2.5.0 YES OK
arm_vexpress 4.6.1 2.5.0 YES OK
m68k_mcf5208 4.6.1 2.5.0 YES OK
m68k_q800 4.6.1 q800-v2.4.0 NO (3) OK
microblazebe 4.6.1 2.5.0 YES OK
microblazeel 4.6.1 2.5.0 YES OK
mips64el_malta 4.6.1 2.5.0 YES OK
mips64_malta 4.6.1 2.5.0 YES OK
mipsel_malta 4.6.1 2.5.0 YES OK
mips_malta 4.6.1 2.5.0 YES OK
ppc_g3beige 4.6.1 2.5.0 YES OK
ppc_mpc8544ds 4.6.1 2.5.0 YES OK
ppc_virtex_ml507 4.6.1 2.5.0 NO OK
ppc64_pseries 4.6.1 2.5.0 YES OK
sh4 4.6.1 2.5.0 YES OK
sh4eb 4.6.1 2.5.0 NO (1) OK
sparc_ss10 4.6.1 2.5.0 YES OK
sparc64_sun4u 4.6.1 2.5.0 YES OK
sparc_sun4u 4.6.1 2.5.0 YES OK
x86 4.6.1 2.5.0 YES OK
x86_64 4.6.1 2.5.0 YES OK
xtensa_lx60 4.6.1 2.6.0 YES OK (2)
xtensa_lx60_nommu 4.6.1 2.6.0 YES OK (2)
(1) - Probably an endian issue with 8139 emulation/driver
(2) - Linux 4.5/4.6 doesn't work with older Qemu versions
(3) - There's a network interface, but enabling it in qemu fails
(4) - Console looks dead in 4.6
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Switch the invocation command to use virtio-blk and virtio-net for
better performance.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It has better performance for block and net.
Enable virgl (DRM_VIRTIO_GPU) support for 3D acceleration.
And also DRM_BOCHS for better stdvga acceleration.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's useful for demo configs which have more features, like
automatically loaded (module) drivers.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm_versatile kernel defconfig updated to deal with multi-platform ARM
support and driver changes.
mips(el) 32-bits is back in working order for 4.5
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.5 2.3.0 YES OK
arm_versatile 4.5 2.3.0 YES OK
arm_vexpress 4.5 2.3.0 YES OK
microblazebe 4.5 2.3.0 YES OK
microblazeel 4.5 2.3.0 YES OK
mips64el_malta 4.5 2.3.0 YES OK
mips64_malta 4.5 2.3.0 YES OK
mipsel_malta 4.5 2.3.0 YES OK
mips_malta 4.5 2.3.0 YES OK
ppc_g3beige 4.5 2.3.0 YES OK
ppc_mpc8544ds 4.5 2.3.0 YES OK
ppc_virtex_ml507 4.5 2.3.0 NO OK
ppc64_pseries 4.5 2.3.0 YES OK
sh4 4.5 2.3.0 YES OK
sh4eb 4.5 2.3.0 NO (1) OK
sparc_ss10 4.5 2.3.0 YES OK
sparc64_sun4u 4.5 2.3.0 YES OK
sparc_sun4u 4.5 2.3.0 YES OK
x86 4.5 2.3.0 YES OK
x86_64 4.5 2.3.0 YES OK
xtensa_lx60 4.4.5 2.3.0 YES (2) OK
(1) - Probably an endian issue with 8139 emulation/driver
(2) - xtensa ethernet broken in 4.5 so stick to 4.4.x
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We're not trying to be minimal here, and qemu can bridge/emulate certain
usb devices, so enable the different controllers and at least usb
storage.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Keep arm_nuri on 3.10.x for the usual reasons.
Keep mips & mipsel (32 bits) on 4.3.x because 4.4.x fails to boot
properly (kernel stuck after the CPU cache info).
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.4.1 2.3.0 YES OK
arm_nuri 3.10.96 2.3.0 YES(1) OK most times(2)
arm_versatile 4.4.1 2.3.0 YES OK
arm_vexpress 4.4.1 2.3.0 YES OK
microblazebe 4.4.1 2.3.0 YES OK
microblazeel 4.4.1 2.3.0 YES OK
mips64el_malta 4.4.1 2.3.0 YES OK
mips64_malta 4.4.1 2.3.0 YES OK
mipsel_malta 4.3.5 2.3.0 YES OK (4)
mips_malta 4.3.5 2.3.0 YES OK (4)
ppc_g3beige 4.4.1 2.3.0 YES OK
ppc_mpc8544ds 4.4.1 2.3.0 YES OK
ppc_virtex_ml507 4.4.1 2.3.0 NO OK
ppc64_pseries 4.4.1 2.3.0 YES OK
sh4 4.4.1 2.3.0 YES OK
sh4eb 4.4.1 2.3.0 NO(3) OK
sparc_ss10 4.4.1 2.3.0 YES OK
sparc64_sun4u 4.4.1 2.3.0 YES OK
sparc_sun4u 4.4.1 2.3.0 YES OK
x86 4.4.1 2.3.0 YES OK
x86_64 4.4.1 2.3.0 YES OK
xtensa_lx60 4.4.1 2.3.0 YES OK
(1) - Supposed to work but broken, probably Qemu emulation issue
(2) - In like 1/3 starts it fails to work properly
(3) - Probably an endian issue with 8139 emulation/driver
(4) - Kernel stuck at cpu cache details from 4.4 - 4.4.1
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is the 21st century, so enable SMP for them.
[Peter: add note to readme.txt about how emulate a SMP system in QEMU]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Specify that the drive image file format is raw to avoid warnings and
restrictions.
Also switch to -drive syntax for all configs.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ppc-mpc8544ds: switch to custom kernel config since the new 4.3-shipped
mpc85xx_basic_defconfig doesn't work with Qemu.
Incidentally while cleaning it up it now seems to work fine with newer
qemu versions.
sparc64_sun4u: ditch ne2k driver since it's useless, and add the e1000
driver which works fine.
x86: stick to 4.2.x kernels since 4.3 doesn't work right with uclibc
(any variant) based toolchains.
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.3 2.3.0 YES OK
arm_nuri 3.10.93 2.3.0 NO(1) OK(2)
arm_versatile 4.3 2.3.0 YES OK
arm_vexpress 4.3 2.3.0 YES OK
microblazebe 4.3 2.3.0 YES OK
microblazeel 4.3 2.3.0 YES OK
mips64el_malta 4.3 2.3.0 YES OK
mips64_malta 4.3 2.3.0 YES OK
mipsel_malta 4.3 2.3.0 YES OK
mips_malta 4.3 2.3.0 YES OK
ppc_g3beige 4.3 2.3.0 YES OK
ppc_mpc8544ds 4.3 2.3.0 YES OK
ppc_virtex_ml507 4.3 2.3.0 NO OK
ppc64_pseries 4.3 2.3.0 YES OK
sh4 4.3 2.3.0 YES OK
sh4eb 4.3 2.3.0 NO(1) OK
sparc_ss10 4.3 2.3.0 YES OK
sparc64_sun4u 4.3 2.3.0 YES OK
sparc_sun4u 4.3 2.3.0 YES OK
x86 4.2.6 2.3.0 YES OK(3)
x86_64 4.3 2.3.0 YES OK
xtensa_lx60 4.3 2.3.0 YES OK
(1) - Supposed to work but broken, probably Qemu emulation issue
(2) - In like 1/3 runs it fails to start properly
(3) - linux 4.3.0 doesn't like uclibc-based toolchains (net issues)
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Enable the generic hda (sound) codec, necessary for qemu audio to work.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Allows for nicer framebuffer emulation under Qemu with the QXL xorg
driver.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Update most of the configs to the latest kernel version (4.1) except for
arm-nuri which is stuck.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Switch to kernel 4.0.
Enable evdev for extra X testing.
Drop bloat/redundant options.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
qemu_arm_vexpress_defconfig is broken for 3.19 so keep it with 3.18.x
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Enable TMPFS support for our custom qemu kernel configs, it's generally
used and can lead to failures/confusion.
Moreover enable ACL & XATTR TMPFS support for SystemD.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update to Linux Kernel 3.16.3.
Enable Ext4 by default.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The alsa utils packages require a kernel with IPC support to run. The
kernel config for the x86 and x86_64 qemu build includes sound support
using the hda driver but without the IPC support the alsa utils won't work.
This patch adds IPC support to the x86 and x86_64 kernel to allow alsa
utils to run and brings the kernel config inline with kernel configs for
other qemu boards.
Signed-off-by: Martin Bark <martin@barkynet.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Tweak the configs to deal with b155f5a5ab
fallout.
And bump to the latest kernel versions.
As of this commit the microblaze qemu targets seem broken, probably
because of commit 14e527eb66 or some qemu
limitation.
SPARC seems to have issues as well, the kernel seems to go down with an
unhandled exception with qemu 1.7.0
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 2c859079cd (configs/qemu: bump relevant config version) renamed
a number of linux configuration files, but forgot to update the defconfigs.
Tests shows that atleast arm versatile doesn't boot with 3.11, so rename
the linux configuration files back rather than adjusting the defconfigs.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
arm_nuri needs some DT fixups to switch to the 3.11.x series since it's
now default for that kernel defconfig.
[Peter: adjust comment in sparc defconfig to match]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While at it add the missing network interfaces to configurations that
support it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Problematic configurations not bumped:
arm-versatilepb - IRQ failure for symbios scsi
sh4-r2d - Qemu still doesn't emulate advanced features from the UART
sparc-ss10 - Illegal instruction
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
