* [Buildroot] [PATCH 2/3] configs/qemu: update for host-qemu-system
2014-05-03 20:20 [Buildroot] [PATCH 1/3] qemu-system: new package Gustavo Zacarias
@ 2014-05-03 20:20 ` Gustavo Zacarias
2014-05-03 20:20 ` [Buildroot] [PATCH 3/3] configs/qemu: bump relevant kernel/header versions Gustavo Zacarias
2014-10-12 15:17 ` [Buildroot] [PATCH 1/3] qemu-system: new package Thomas Petazzoni
2 siblings, 0 replies; 19+ messages in thread
From: Gustavo Zacarias @ 2014-05-03 20:20 UTC (permalink / raw)
To: buildroot
Add the invocation parameter for use with host-qemu-system.
Narrow down the Qemu version like it's done for kernel headers since we
can't guarantee that a host-qemu-system version bump won't break the
configs.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
configs/qemu_arm_nuri_defconfig | 5 +++++
configs/qemu_arm_versatile_defconfig | 5 +++++
configs/qemu_arm_vexpress_defconfig | 5 +++++
configs/qemu_microblazebe_mmu_defconfig | 5 +++++
configs/qemu_microblazeel_mmu_defconfig | 5 +++++
configs/qemu_mips64_malta_defconfig | 5 +++++
configs/qemu_mips64el_malta_defconfig | 5 +++++
configs/qemu_mips_malta_defconfig | 5 +++++
configs/qemu_mipsel_malta_defconfig | 5 +++++
configs/qemu_ppc_g3beige_defconfig | 5 +++++
configs/qemu_ppc_mpc8544ds_defconfig | 5 +++++
configs/qemu_ppc_virtex_ml507_defconfig | 5 +++++
configs/qemu_sh4_r2d_defconfig | 5 +++++
configs/qemu_sparc_ss10_defconfig | 5 +++++
configs/qemu_x86_64_defconfig | 5 +++++
configs/qemu_x86_defconfig | 5 +++++
16 files changed, 80 insertions(+)
diff --git a/configs/qemu_arm_nuri_defconfig b/configs/qemu_arm_nuri_defconfig
index 40dcb37..0222459 100644
--- a/configs/qemu_arm_nuri_defconfig
+++ b/configs/qemu_arm_nuri_defconfig
@@ -25,3 +25,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.10.32"
BR2_LINUX_KERNEL_DEFCONFIG="exynos4"
BR2_LINUX_KERNEL_ZIMAGE=y
+
+# Qemu-system
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M nuri -kernel output/images/zImage -append 'console=ttySAC1,115200' -smp 2 -serial null -serial stdio -display curses"
diff --git a/configs/qemu_arm_versatile_defconfig b/configs/qemu_arm_versatile_defconfig
index 1348bab..0accccd 100644
--- a/configs/qemu_arm_versatile_defconfig
+++ b/configs/qemu_arm_versatile_defconfig
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-3.13.config"
BR2_LINUX_KERNEL_ZIMAGE=y
+
+# Qemu-system
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M versatilepb -kernel output/images/zImage -drive file=output/images/rootfs.ext2,if=scsi -append 'root=/dev/sda console=ttyAMA0,115200' -serial stdio -net nic,model=smc91c111 -net user -display none"
diff --git a/configs/qemu_arm_vexpress_defconfig b/configs/qemu_arm_vexpress_defconfig
index e35a44a..facb3f6 100644
--- a/configs/qemu_arm_vexpress_defconfig
+++ b/configs/qemu_arm_vexpress_defconfig
@@ -24,3 +24,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
BR2_LINUX_KERNEL_ZIMAGE=y
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M vexpress-a9 -kernel output/images/zImage -drive file=output/images/rootfs.ext2,if=sd -append 'console=ttyAMA0,115200 root=/dev/mmcblk0' -serial stdio -net nic,model=lan9118 -net user -display none"
diff --git a/configs/qemu_microblazebe_mmu_defconfig b/configs/qemu_microblazebe_mmu_defconfig
index b3ec32f..0698178 100644
--- a/configs/qemu_microblazebe_mmu_defconfig
+++ b/configs/qemu_microblazebe_mmu_defconfig
@@ -17,3 +17,8 @@ BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/microblazebe-mmu/linux-3.14.config"
BR2_LINUX_KERNEL_LINUX_BIN=y
BR2_LINUX_KERNEL_PATCH="board/qemu/microblazebe-mmu/xilinx-xemaclite.patch"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio -display none"
diff --git a/configs/qemu_microblazeel_mmu_defconfig b/configs/qemu_microblazeel_mmu_defconfig
index a009893..a0383e5 100644
--- a/configs/qemu_microblazeel_mmu_defconfig
+++ b/configs/qemu_microblazeel_mmu_defconfig
@@ -17,3 +17,8 @@ BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/microblazeel-mmu/linux-3.14.config"
BR2_LINUX_KERNEL_LINUX_BIN=y
BR2_LINUX_KERNEL_PATCH="board/qemu/microblazeel-mmu/xilinx-xemaclite.patch"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio -display none"
diff --git a/configs/qemu_mips64_malta_defconfig b/configs/qemu_mips64_malta_defconfig
index 97937d1..6759a0d 100644
--- a/configs/qemu_mips64_malta_defconfig
+++ b/configs/qemu_mips64_malta_defconfig
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -display none"
diff --git a/configs/qemu_mips64el_malta_defconfig b/configs/qemu_mips64el_malta_defconfig
index 4adf204..e3497de 100644
--- a/configs/qemu_mips64el_malta_defconfig
+++ b/configs/qemu_mips64el_malta_defconfig
@@ -25,3 +25,8 @@ BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -display none"
diff --git a/configs/qemu_mips_malta_defconfig b/configs/qemu_mips_malta_defconfig
index 3c1532c..b788312 100644
--- a/configs/qemu_mips_malta_defconfig
+++ b/configs/qemu_mips_malta_defconfig
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -net nic,model=pcnet -net user -display none"
diff --git a/configs/qemu_mipsel_malta_defconfig b/configs/qemu_mipsel_malta_defconfig
index b673f0b..8642de8 100644
--- a/configs/qemu_mipsel_malta_defconfig
+++ b/configs/qemu_mipsel_malta_defconfig
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -net nic,model=pcnet -net user -display none"
diff --git a/configs/qemu_ppc_g3beige_defconfig b/configs/qemu_ppc_g3beige_defconfig
index 1668e72..ef2cf49 100644
--- a/configs/qemu_ppc_g3beige_defconfig
+++ b/configs/qemu_ppc_g3beige_defconfig
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M g3beige -kernel output/images/vmlinux -hda output/images/rootfs.ext2 -append 'console=ttyS0 root=/dev/hda' -serial stdio -net nic,model=rtl8139 -net user -display none"
diff --git a/configs/qemu_ppc_mpc8544ds_defconfig b/configs/qemu_ppc_mpc8544ds_defconfig
index 6d7f24d..18b7862 100644
--- a/configs/qemu_ppc_mpc8544ds_defconfig
+++ b/configs/qemu_ppc_mpc8544ds_defconfig
@@ -21,3 +21,8 @@ BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M mpc8544ds -kernel output/images/vmlinux -serial stdio -net nic,model=e1000 -net user -display none"
diff --git a/configs/qemu_ppc_virtex_ml507_defconfig b/configs/qemu_ppc_virtex_ml507_defconfig
index cd2f647..f5f1d04 100644
--- a/configs/qemu_ppc_virtex_ml507_defconfig
+++ b/configs/qemu_ppc_virtex_ml507_defconfig
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_DEFCONFIG="44x/virtex5"
BR2_LINUX_KERNEL_VMLINUX=y
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="virtex440-ml507"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M virtex-ml507 -kernel output/images/vmlinux -m 256 -append 'console=ttyS0' -display none -nographic -dtb output/images/virtex440-ml507.dtb"
diff --git a/configs/qemu_sh4_r2d_defconfig b/configs/qemu_sh4_r2d_defconfig
index b27d9ec..fd70d69 100644
--- a/configs/qemu_sh4_r2d_defconfig
+++ b/configs/qemu_sh4_r2d_defconfig
@@ -26,3 +26,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.2.55"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/sh4-r2d/linux-3.2.config"
BR2_LINUX_KERNEL_ZIMAGE=y
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M r2d -kernel output/images/zImage -drive file=output/images/rootfs.ext2,if=ide -append 'root=/dev/sda console=ttySC1,115200 noiotrap' -serial null -serial stdio -net nic,model=rtl8139 -net user -display none"
diff --git a/configs/qemu_sparc_ss10_defconfig b/configs/qemu_sparc_ss10_defconfig
index 3b56d98..15893bd 100644
--- a/configs/qemu_sparc_ss10_defconfig
+++ b/configs/qemu_sparc_ss10_defconfig
@@ -17,3 +17,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.12.5"
BR2_LINUX_KERNEL_DEFCONFIG="sparc32"
BR2_LINUX_KERNEL_ZIMAGE=y
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M SS-10 -kernel output/images/zImage -drive file=output/images/rootfs.ext2 -append 'root=/dev/sda console=ttyS0,115200' -serial stdio -net nic,model=lance -net user -display none"
diff --git a/configs/qemu_x86_64_defconfig b/configs/qemu_x86_64_defconfig
index 827d362..95e6a00 100644
--- a/configs/qemu_x86_64_defconfig
+++ b/configs/qemu_x86_64_defconfig
@@ -20,3 +20,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-3.13.config"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=ide -append 'root=/dev/sda' -net nic,model=rtl8139 -net user -display curses"
diff --git a/configs/qemu_x86_defconfig b/configs/qemu_x86_defconfig
index a5040c8..3fa1432 100644
--- a/configs/qemu_x86_defconfig
+++ b/configs/qemu_x86_defconfig
@@ -21,3 +21,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.13.config"
+
+# Qemu
+BR2_PACKAGE_HOST_QEMU_SYSTEM=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0"
+BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=ide -append 'root=/dev/sda' -net nic,model=rtl8139 -net user -display curses"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 3/3] configs/qemu: bump relevant kernel/header versions
2014-05-03 20:20 [Buildroot] [PATCH 1/3] qemu-system: new package Gustavo Zacarias
2014-05-03 20:20 ` [Buildroot] [PATCH 2/3] configs/qemu: update for host-qemu-system Gustavo Zacarias
@ 2014-05-03 20:20 ` Gustavo Zacarias
2014-10-12 15:17 ` [Buildroot] [PATCH 1/3] qemu-system: new package Thomas Petazzoni
2 siblings, 0 replies; 19+ messages in thread
From: Gustavo Zacarias @ 2014-05-03 20:20 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
board/qemu/arm-nuri/readme.txt | 2 +-
.../arm-versatile/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/arm-versatile/readme.txt | 2 +-
board/qemu/arm-vexpress/readme.txt | 2 +-
board/qemu/microblazebe-mmu/readme.txt | 2 +-
board/qemu/microblazeel-mmu/readme.txt | 2 +-
board/qemu/mips-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mips-malta/readme.txt | 2 +-
.../qemu/mips64-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mips64-malta/readme.txt | 2 +-
.../mips64el-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mips64el-malta/readme.txt | 2 +-
.../qemu/mipsel-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mipsel-malta/readme.txt | 2 +-
.../powerpc-g3beige/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/powerpc-g3beige/readme.txt | 2 +-
board/qemu/powerpc-mpc8544ds/readme.txt | 2 +-
board/qemu/powerpc-virtex-ml507/readme.txt | 2 +-
board/qemu/sh4-r2d/readme.txt | 2 +-
board/qemu/sparc-ss10/readme.txt | 2 +-
board/qemu/x86/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/x86/readme.txt | 2 +-
board/qemu/x86_64/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/x86_64/readme.txt | 2 +-
configs/qemu_arm_nuri_defconfig | 4 ++--
configs/qemu_arm_versatile_defconfig | 10 +++++-----
configs/qemu_arm_vexpress_defconfig | 8 ++++----
configs/qemu_mips64_malta_defconfig | 10 +++++-----
configs/qemu_mips64el_malta_defconfig | 10 +++++-----
configs/qemu_mips_malta_defconfig | 10 +++++-----
configs/qemu_mipsel_malta_defconfig | 10 +++++-----
configs/qemu_ppc_g3beige_defconfig | 10 +++++-----
configs/qemu_ppc_mpc8544ds_defconfig | 8 ++++----
configs/qemu_ppc_virtex_ml507_defconfig | 8 ++++----
configs/qemu_sh4_r2d_defconfig | 4 ++--
configs/qemu_sparc_ss10_defconfig | 8 ++++----
configs/qemu_x86_64_defconfig | 10 +++++-----
configs/qemu_x86_defconfig | 10 +++++-----
38 files changed, 76 insertions(+), 76 deletions(-)
rename board/qemu/arm-versatile/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mips-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mips64-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mips64el-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mipsel-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/powerpc-g3beige/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/x86/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/x86_64/{linux-3.13.config => linux-3.14.config} (100%)
diff --git a/board/qemu/arm-nuri/readme.txt b/board/qemu/arm-nuri/readme.txt
index 0cf8d0b..6f8e5da 100644
--- a/board/qemu/arm-nuri/readme.txt
+++ b/board/qemu/arm-nuri/readme.txt
@@ -7,4 +7,4 @@ graphical window is the framebuffer.
Startup time is slow because of the SMP CPU emulation so be patient.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/arm-versatile/linux-3.13.config b/board/qemu/arm-versatile/linux-3.14.config
similarity index 100%
rename from board/qemu/arm-versatile/linux-3.13.config
rename to board/qemu/arm-versatile/linux-3.14.config
diff --git a/board/qemu/arm-versatile/readme.txt b/board/qemu/arm-versatile/readme.txt
index 2c02e26..5fe75b8 100644
--- a/board/qemu/arm-versatile/readme.txt
+++ b/board/qemu/arm-versatile/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/arm-vexpress/readme.txt b/board/qemu/arm-vexpress/readme.txt
index 50dd563..e3e50b1 100644
--- a/board/qemu/arm-vexpress/readme.txt
+++ b/board/qemu/arm-vexpress/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/microblazebe-mmu/readme.txt b/board/qemu/microblazebe-mmu/readme.txt
index 3c7e10c..0c4a4f0 100644
--- a/board/qemu/microblazebe-mmu/readme.txt
+++ b/board/qemu/microblazebe-mmu/readme.txt
@@ -4,4 +4,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/microblazeel-mmu/readme.txt b/board/qemu/microblazeel-mmu/readme.txt
index d402d13..27e218c 100644
--- a/board/qemu/microblazeel-mmu/readme.txt
+++ b/board/qemu/microblazeel-mmu/readme.txt
@@ -4,4 +4,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/mips-malta/linux-3.13.config b/board/qemu/mips-malta/linux-3.14.config
similarity index 100%
rename from board/qemu/mips-malta/linux-3.13.config
rename to board/qemu/mips-malta/linux-3.14.config
diff --git a/board/qemu/mips-malta/readme.txt b/board/qemu/mips-malta/readme.txt
index 719a624..da20770 100644
--- a/board/qemu/mips-malta/readme.txt
+++ b/board/qemu/mips-malta/readme.txt
@@ -6,4 +6,4 @@ The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer. No keyboard support has been
enabled.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/mips64-malta/linux-3.13.config b/board/qemu/mips64-malta/linux-3.14.config
similarity index 100%
rename from board/qemu/mips64-malta/linux-3.13.config
rename to board/qemu/mips64-malta/linux-3.14.config
diff --git a/board/qemu/mips64-malta/readme.txt b/board/qemu/mips64-malta/readme.txt
index 3ce3c62..967ea76 100644
--- a/board/qemu/mips64-malta/readme.txt
+++ b/board/qemu/mips64-malta/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/mips64el-malta/linux-3.13.config b/board/qemu/mips64el-malta/linux-3.14.config
similarity index 100%
rename from board/qemu/mips64el-malta/linux-3.13.config
rename to board/qemu/mips64el-malta/linux-3.14.config
diff --git a/board/qemu/mips64el-malta/readme.txt b/board/qemu/mips64el-malta/readme.txt
index 48bae37..3c75bed 100644
--- a/board/qemu/mips64el-malta/readme.txt
+++ b/board/qemu/mips64el-malta/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/mipsel-malta/linux-3.13.config b/board/qemu/mipsel-malta/linux-3.14.config
similarity index 100%
rename from board/qemu/mipsel-malta/linux-3.13.config
rename to board/qemu/mipsel-malta/linux-3.14.config
diff --git a/board/qemu/mipsel-malta/readme.txt b/board/qemu/mipsel-malta/readme.txt
index dd290c4..fce8780 100644
--- a/board/qemu/mipsel-malta/readme.txt
+++ b/board/qemu/mipsel-malta/readme.txt
@@ -6,4 +6,4 @@ The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer. No keyboard support has been
enabled.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/powerpc-g3beige/linux-3.13.config b/board/qemu/powerpc-g3beige/linux-3.14.config
similarity index 100%
rename from board/qemu/powerpc-g3beige/linux-3.13.config
rename to board/qemu/powerpc-g3beige/linux-3.14.config
diff --git a/board/qemu/powerpc-g3beige/readme.txt b/board/qemu/powerpc-g3beige/readme.txt
index 2711350..5c64880 100644
--- a/board/qemu/powerpc-g3beige/readme.txt
+++ b/board/qemu/powerpc-g3beige/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu. The
graphical window is the framebuffer.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/powerpc-mpc8544ds/readme.txt b/board/qemu/powerpc-mpc8544ds/readme.txt
index 27b3bee..8632c80 100644
--- a/board/qemu/powerpc-mpc8544ds/readme.txt
+++ b/board/qemu/powerpc-mpc8544ds/readme.txt
@@ -4,4 +4,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/powerpc-virtex-ml507/readme.txt b/board/qemu/powerpc-virtex-ml507/readme.txt
index 0547987..dd2a914 100644
--- a/board/qemu/powerpc-virtex-ml507/readme.txt
+++ b/board/qemu/powerpc-virtex-ml507/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/sh4-r2d/readme.txt b/board/qemu/sh4-r2d/readme.txt
index 73dce14..5d770b4 100644
--- a/board/qemu/sh4-r2d/readme.txt
+++ b/board/qemu/sh4-r2d/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu.
The graphical window is the framebuffer.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/sparc-ss10/readme.txt b/board/qemu/sparc-ss10/readme.txt
index a126a55..4b675c8 100644
--- a/board/qemu/sparc-ss10/readme.txt
+++ b/board/qemu/sparc-ss10/readme.txt
@@ -5,4 +5,4 @@ Run the emulation with:
The login prompt will appear in the terminal that started Qemu.
The graphical window is the framebuffer.
-Tested with QEMU 1.6.1
+Tested with QEMU 2.0.0
diff --git a/board/qemu/x86/linux-3.13.config b/board/qemu/x86/linux-3.14.config
similarity index 100%
rename from board/qemu/x86/linux-3.13.config
rename to board/qemu/x86/linux-3.14.config
diff --git a/board/qemu/x86/readme.txt b/board/qemu/x86/readme.txt
index c821255..9ee2e37 100644
--- a/board/qemu/x86/readme.txt
+++ b/board/qemu/x86/readme.txt
@@ -4,4 +4,4 @@ Run the emulation with:
The login prompt will appear in the graphical window.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/board/qemu/x86_64/linux-3.13.config b/board/qemu/x86_64/linux-3.14.config
similarity index 100%
rename from board/qemu/x86_64/linux-3.13.config
rename to board/qemu/x86_64/linux-3.14.config
diff --git a/board/qemu/x86_64/readme.txt b/board/qemu/x86_64/readme.txt
index f350d36..eec91f1 100644
--- a/board/qemu/x86_64/readme.txt
+++ b/board/qemu/x86_64/readme.txt
@@ -4,4 +4,4 @@ Run the emulation with:
The login prompt will appear in the graphical window.
-Tested with QEMU 1.7.0
+Tested with QEMU 2.0.0
diff --git a/configs/qemu_arm_nuri_defconfig b/configs/qemu_arm_nuri_defconfig
index 0222459..cd2931a 100644
--- a/configs/qemu_arm_nuri_defconfig
+++ b/configs/qemu_arm_nuri_defconfig
@@ -16,13 +16,13 @@ BR2_TARGET_ROOTFS_INITRAMFS=y
# Lock to 3.10 headers to avoid breaking with newer kernels
# Stuck at 3.10.x because there's no Nuri DTS
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.10.32"
+BR2_DEFAULT_KERNEL_VERSION="3.10.38"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_10=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.10.32"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.10.38"
BR2_LINUX_KERNEL_DEFCONFIG="exynos4"
BR2_LINUX_KERNEL_ZIMAGE=y
diff --git a/configs/qemu_arm_versatile_defconfig b/configs/qemu_arm_versatile_defconfig
index 0accccd..29fb995 100644
--- a/configs/qemu_arm_versatile_defconfig
+++ b/configs/qemu_arm_versatile_defconfig
@@ -10,17 +10,17 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-3.14.config"
BR2_LINUX_KERNEL_ZIMAGE=y
# Qemu-system
diff --git a/configs/qemu_arm_vexpress_defconfig b/configs/qemu_arm_vexpress_defconfig
index facb3f6..8d9d81a 100644
--- a/configs/qemu_arm_vexpress_defconfig
+++ b/configs/qemu_arm_vexpress_defconfig
@@ -13,15 +13,15 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
BR2_LINUX_KERNEL_ZIMAGE=y
diff --git a/configs/qemu_mips64_malta_defconfig b/configs/qemu_mips64_malta_defconfig
index 6759a0d..424e7b1 100644
--- a/configs/qemu_mips64_malta_defconfig
+++ b/configs/qemu_mips64_malta_defconfig
@@ -6,17 +6,17 @@ BR2_MIPS_NABI64=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64-malta/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64-malta/linux-3.14.config"
BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
diff --git a/configs/qemu_mips64el_malta_defconfig b/configs/qemu_mips64el_malta_defconfig
index e3497de..ca09edf 100644
--- a/configs/qemu_mips64el_malta_defconfig
+++ b/configs/qemu_mips64el_malta_defconfig
@@ -9,17 +9,17 @@ BR2_TOOLCHAIN_BUILDROOT_EGLIBC=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64el-malta/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64el-malta/linux-3.14.config"
BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
diff --git a/configs/qemu_mips_malta_defconfig b/configs/qemu_mips_malta_defconfig
index b788312..5442595 100644
--- a/configs/qemu_mips_malta_defconfig
+++ b/configs/qemu_mips_malta_defconfig
@@ -6,17 +6,17 @@ BR2_mips_32r2=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips-malta/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips-malta/linux-3.14.config"
BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
diff --git a/configs/qemu_mipsel_malta_defconfig b/configs/qemu_mipsel_malta_defconfig
index 8642de8..e49cdbb 100644
--- a/configs/qemu_mipsel_malta_defconfig
+++ b/configs/qemu_mipsel_malta_defconfig
@@ -6,17 +6,17 @@ BR2_mips_32r2=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-3.14.config"
BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
diff --git a/configs/qemu_ppc_g3beige_defconfig b/configs/qemu_ppc_g3beige_defconfig
index ef2cf49..c49e156 100644
--- a/configs/qemu_ppc_g3beige_defconfig
+++ b/configs/qemu_ppc_g3beige_defconfig
@@ -6,17 +6,17 @@ BR2_powerpc_750=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/powerpc-g3beige/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/powerpc-g3beige/linux-3.14.config"
BR2_LINUX_KERNEL_VMLINUX=y
# Serial port config
diff --git a/configs/qemu_ppc_mpc8544ds_defconfig b/configs/qemu_ppc_mpc8544ds_defconfig
index 18b7862..f8d82ba 100644
--- a/configs/qemu_ppc_mpc8544ds_defconfig
+++ b/configs/qemu_ppc_mpc8544ds_defconfig
@@ -6,15 +6,15 @@ BR2_powerpc_8548=y
# BR2_TARGET_ROOTFS_TAR is not set
BR2_TARGET_ROOTFS_INITRAMFS=y
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_DEFCONFIG="mpc85xx"
BR2_LINUX_KERNEL_VMLINUX=y
diff --git a/configs/qemu_ppc_virtex_ml507_defconfig b/configs/qemu_ppc_virtex_ml507_defconfig
index f5f1d04..25c8903 100644
--- a/configs/qemu_ppc_virtex_ml507_defconfig
+++ b/configs/qemu_ppc_virtex_ml507_defconfig
@@ -6,10 +6,10 @@ BR2_powerpc_440=y
# BR2_TARGET_ROOTFS_TAR is not set
BR2_TARGET_ROOTFS_INITRAMFS=y
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Use soft float
BR2_SOFT_FLOAT=y
@@ -17,7 +17,7 @@ BR2_SOFT_FLOAT=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_DEFCONFIG="44x/virtex5"
BR2_LINUX_KERNEL_VMLINUX=y
BR2_LINUX_KERNEL_DTS_SUPPORT=y
diff --git a/configs/qemu_sh4_r2d_defconfig b/configs/qemu_sh4_r2d_defconfig
index fd70d69..2cce4db 100644
--- a/configs/qemu_sh4_r2d_defconfig
+++ b/configs/qemu_sh4_r2d_defconfig
@@ -12,7 +12,7 @@ BR2_TARGET_ROOTFS_EXT2=y
# Lock to 3.2 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.2.55"
+BR2_DEFAULT_KERNEL_VERSION="3.2.58"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_2=y
# The kernel wants to use the -m4-nofpu option to make sure that it
@@ -22,7 +22,7 @@ BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-multilib-list=m4,m4-nofpu"
# Linux kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.2.55"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.2.58"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/sh4-r2d/linux-3.2.config"
BR2_LINUX_KERNEL_ZIMAGE=y
diff --git a/configs/qemu_sparc_ss10_defconfig b/configs/qemu_sparc_ss10_defconfig
index 15893bd..0e66110 100644
--- a/configs/qemu_sparc_ss10_defconfig
+++ b/configs/qemu_sparc_ss10_defconfig
@@ -6,15 +6,15 @@ BR2_sparc_v8=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.12 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.12.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Linux kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.12.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_DEFCONFIG="sparc32"
BR2_LINUX_KERNEL_ZIMAGE=y
diff --git a/configs/qemu_x86_64_defconfig b/configs/qemu_x86_64_defconfig
index 95e6a00..131d0c7 100644
--- a/configs/qemu_x86_64_defconfig
+++ b/configs/qemu_x86_64_defconfig
@@ -9,17 +9,17 @@ BR2_TARGET_GENERIC_GETTY_PORT="tty1"
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-3.14.config"
# Qemu
BR2_PACKAGE_HOST_QEMU_SYSTEM=y
diff --git a/configs/qemu_x86_defconfig b/configs/qemu_x86_defconfig
index 3fa1432..b2ab4e2 100644
--- a/configs/qemu_x86_defconfig
+++ b/configs/qemu_x86_defconfig
@@ -10,17 +10,17 @@ BR2_TARGET_GENERIC_GETTY_PORT="tty1"
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
-# Lock to 3.13 headers to avoid breaking with newer kernels
+# Lock to 3.14 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.13.5"
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y
+BR2_DEFAULT_KERNEL_VERSION="3.14.2"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
-BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.13.config"
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.14.config"
# Qemu
BR2_PACKAGE_HOST_QEMU_SYSTEM=y
--
1.8.3.2
^ permalink raw reply related [flat|nested] 19+ messages in thread* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-05-03 20:20 [Buildroot] [PATCH 1/3] qemu-system: new package Gustavo Zacarias
2014-05-03 20:20 ` [Buildroot] [PATCH 2/3] configs/qemu: update for host-qemu-system Gustavo Zacarias
2014-05-03 20:20 ` [Buildroot] [PATCH 3/3] configs/qemu: bump relevant kernel/header versions Gustavo Zacarias
@ 2014-10-12 15:17 ` Thomas Petazzoni
2014-10-12 19:03 ` Gustavo Zacarias
2 siblings, 1 reply; 19+ messages in thread
From: Thomas Petazzoni @ 2014-10-12 15:17 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Sat, 3 May 2014 17:20:13 -0300, Gustavo Zacarias wrote:
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
> package/Config.in.host | 1 +
> package/qemu-system/Config.in.host | 30 ++++++++++++++++++
> package/qemu-system/qemu-system.mk | 64 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 95 insertions(+)
> create mode 100644 package/qemu-system/Config.in.host
> create mode 100644 package/qemu-system/qemu-system.mk
We discussed this patch series during the Buildroot meeting. PATCH 3/3
is Superseded, as you have updated the Qemu defconfigs many time since
then.
Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be
part of the qemu package itself, and not a separate qemu-system. Since
I know you are not interested in doing this work, Yann E. Morin has
said he was interested in doing this, once his current patch series
adding support for qemu-system on the target has been merged.
Consequently, I will mark your patches as 'Changes Requested' in
patchwork. Of course, if in the mean time you change your mind and
decide to implement host qemu-system as part of the qemu package, we'd
be happy to receive your patches! :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-12 15:17 ` [Buildroot] [PATCH 1/3] qemu-system: new package Thomas Petazzoni
@ 2014-10-12 19:03 ` Gustavo Zacarias
2014-10-15 17:01 ` Arnout Vandecappelle
0 siblings, 1 reply; 19+ messages in thread
From: Gustavo Zacarias @ 2014-10-12 19:03 UTC (permalink / raw)
To: buildroot
On 10/12/2014 12:17 PM, Thomas Petazzoni wrote:
> We discussed this patch series during the Buildroot meeting. PATCH 3/3
> is Superseded, as you have updated the Qemu defconfigs many time since
> then.
>
> Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be
> part of the qemu package itself, and not a separate qemu-system. Since
> I know you are not interested in doing this work, Yann E. Morin has
> said he was interested in doing this, once his current patch series
> adding support for qemu-system on the target has been merged.
>
> Consequently, I will mark your patches as 'Changes Requested' in
> patchwork. Of course, if in the mean time you change your mind and
> decide to implement host qemu-system as part of the qemu package, we'd
> be happy to receive your patches! :-)
I don't agree on the reasoning:
You can't use different versions for host and non-host packages in a
clean way: that alone and the fact that no single qemu version can cover
all of the emulations would make the single package pointless.
It's all fine and nice to strive to get qemu fixed but it's an
unrealistic objective, new architectures and variants together with old
emulations that seldomly are used/tested will continue to make this a
moving target.
Time and time again this has proven to be the case so leaving a fixed
version for the package will make it pointless, we can just tell people
to use some random distro version and get the same result which would
render the host package with no sense to be.
And changing the package version for the target because the host version
needs some special care plays into the changing results arena.
Granted it's not a common use-case to have both, but it's doing it
regarless.
You want all emulations to work, not just some depending on weather,
wind and pollen count.
So on my side i'm not planning to do anything with this decision.
Regards.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-12 19:03 ` Gustavo Zacarias
@ 2014-10-15 17:01 ` Arnout Vandecappelle
2014-10-16 13:53 ` Gustavo Zacarias
0 siblings, 1 reply; 19+ messages in thread
From: Arnout Vandecappelle @ 2014-10-15 17:01 UTC (permalink / raw)
To: buildroot
On 12/10/14 21:03, Gustavo Zacarias wrote:
> On 10/12/2014 12:17 PM, Thomas Petazzoni wrote:
>
>> We discussed this patch series during the Buildroot meeting. PATCH 3/3
>> is Superseded, as you have updated the Qemu defconfigs many time since
>> then.
>>
>> Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be
>> part of the qemu package itself, and not a separate qemu-system. Since
>> I know you are not interested in doing this work, Yann E. Morin has
>> said he was interested in doing this, once his current patch series
>> adding support for qemu-system on the target has been merged.
>>
>> Consequently, I will mark your patches as 'Changes Requested' in
>> patchwork. Of course, if in the mean time you change your mind and
>> decide to implement host qemu-system as part of the qemu package, we'd
>> be happy to receive your patches! :-)
>
> I don't agree on the reasoning:
> You can't use different versions for host and non-host packages in a
> clean way:
Can you explain why not?
You cannot use different versions for qemu-user and qemu-system in a clean way
if they're not different packages. But host and target versions don't need to be
the same. At least, I see code in pkg-generic.mk to handle that.
And I do think we want to keep qemu-user and qemu-system at the same version,
right? Or does it happen that you need different versions for these as well?
The real question is how to make the version depend on the values in
BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.
Regards,
Arnout
> that alone and the fact that no single qemu version can cover
> all of the emulations would make the single package pointless.
> It's all fine and nice to strive to get qemu fixed but it's an
> unrealistic objective, new architectures and variants together with old
> emulations that seldomly are used/tested will continue to make this a
> moving target.
> Time and time again this has proven to be the case so leaving a fixed
> version for the package will make it pointless, we can just tell people
> to use some random distro version and get the same result which would
> render the host package with no sense to be.
> And changing the package version for the target because the host version
> needs some special care plays into the changing results arena.
> Granted it's not a common use-case to have both, but it's doing it
> regarless.
> You want all emulations to work, not just some depending on weather,
> wind and pollen count.
> So on my side i'm not planning to do anything with this decision.
> Regards.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-15 17:01 ` Arnout Vandecappelle
@ 2014-10-16 13:53 ` Gustavo Zacarias
2014-10-17 22:47 ` Arnout Vandecappelle
0 siblings, 1 reply; 19+ messages in thread
From: Gustavo Zacarias @ 2014-10-16 13:53 UTC (permalink / raw)
To: buildroot
On 10/15/2014 02:01 PM, Arnout Vandecappelle wrote:
> Can you explain why not?
>
> You cannot use different versions for qemu-user and qemu-system in a clean way
> if they're not different packages. But host and target versions don't need to be
> the same. At least, I see code in pkg-generic.mk to handle that.
Well, not really, for example try modifying package/e2fsprogs.mk:
HOST_E2FSPROGS_VERSION = 1.42.13
And build both, see what happens.
Even try a make source with that.
> And I do think we want to keep qemu-user and qemu-system at the same version,
> right? Or does it happen that you need different versions for these as well?
>
> The real question is how to make the version depend on the values in
> BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.
No, that's a wrong assumption.
For example qemu_mpc8544ds_defconfig doesn't work with the latest 2.1.2
qemu, however other qemu ppc sample defconfigs do (in fact no 2.1.x
version).
And the qemu config should dictate what's the best version for each -
not necessarily the latest, you can't make host-qemu-user depend on that
since it's a platform decision, not an arch one.
If you want to stick with "the one that works for everything" you
potentially miss the opportunity for new arch and/or platform support.
So even if target != host version is fixed/possible you'll still clash
on host-qemu (user) vs. host-qemu (system) versions since you might want
to do the perl module dance (original purpose of host-qemu) vs. platform
emulation.
It's nice to keep everything in one package, but it's not feasible to do
so in a coherent way for this case in particular.
If you can't get the leash out of the qemu version there's no point in
building so for the emulation, sometimes you'll ship every single qemu
config working, sometimes you wont - and that's my quarrel, everyone is
perfect-this perfect-that but all of the sudden this would be acceptable?
Like i said it would be the same as $RANDOM distro qemu.
Regards.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-16 13:53 ` Gustavo Zacarias
@ 2014-10-17 22:47 ` Arnout Vandecappelle
2014-10-18 1:14 ` Gustavo Zacarias
0 siblings, 1 reply; 19+ messages in thread
From: Arnout Vandecappelle @ 2014-10-17 22:47 UTC (permalink / raw)
To: buildroot
On 16/10/14 15:53, Gustavo Zacarias wrote:
> On 10/15/2014 02:01 PM, Arnout Vandecappelle wrote:
>
>> Can you explain why not?
>>
>> You cannot use different versions for qemu-user and qemu-system in a clean way
>> if they're not different packages. But host and target versions don't need to be
>> the same. At least, I see code in pkg-generic.mk to handle that.
>
> Well, not really, for example try modifying package/e2fsprogs.mk:
> HOST_E2FSPROGS_VERSION = 1.42.13
>
> And build both, see what happens.
> Even try a make source with that.
Yeah, OK, you have to set the HOST_FOO_SOURCE explicitly as well due to a
little shortcoming in the infrastructure, but I don't think that should be a
showstopper.
>
>> And I do think we want to keep qemu-user and qemu-system at the same version,
>> right? Or does it happen that you need different versions for these as well?
>>
>> The real question is how to make the version depend on the values in
>> BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.
>
> No, that's a wrong assumption.
> For example qemu_mpc8544ds_defconfig doesn't work with the latest 2.1.2
> qemu, however other qemu ppc sample defconfigs do (in fact no 2.1.x
> version).
Yes, you're right, the host-qemu version should be dictated by a config option,
not derived automatically.
> And the qemu config should dictate what's the best version for each -
> not necessarily the latest, you can't make host-qemu-user depend on that
> since it's a platform decision, not an arch one.
> If you want to stick with "the one that works for everything" you
AFAIK nobody claims that there should be one version that works for everything
- possibly there should even be some version config option for the target qemu.
The only problem we see is to have a separate qemu-system and qemu-user package.
> potentially miss the opportunity for new arch and/or platform support.
> So even if target != host version is fixed/possible you'll still clash
> on host-qemu (user) vs. host-qemu (system) versions since you might want
> to do the perl module dance (original purpose of host-qemu) vs. platform
> emulation.
This one I don't understand. If you need version 2.0.2 for host-qemu-system,
then surely you also need this version for host-qemu-user? So what is the point
of treating them as separate packages? Isn't it much easier to build qemu-user
and qemu-system in one shot (like how it's done for the target qemu)?
Regards,
Arnout
> It's nice to keep everything in one package, but it's not feasible to do
> so in a coherent way for this case in particular.
> If you can't get the leash out of the qemu version there's no point in
> building so for the emulation, sometimes you'll ship every single qemu
> config working, sometimes you wont - and that's my quarrel, everyone is
> perfect-this perfect-that but all of the sudden this would be acceptable?
> Like i said it would be the same as $RANDOM distro qemu.
> Regards.
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-17 22:47 ` Arnout Vandecappelle
@ 2014-10-18 1:14 ` Gustavo Zacarias
2014-10-19 20:27 ` Arnout Vandecappelle
0 siblings, 1 reply; 19+ messages in thread
From: Gustavo Zacarias @ 2014-10-18 1:14 UTC (permalink / raw)
To: buildroot
On 10/17/2014 07:47 PM, Arnout Vandecappelle wrote:
>> potentially miss the opportunity for new arch and/or platform support.
>> So even if target != host version is fixed/possible you'll still clash
>> on host-qemu (user) vs. host-qemu (system) versions since you might want
>> to do the perl module dance (original purpose of host-qemu) vs. platform
>> emulation.
>
> This one I don't understand. If you need version 2.0.2 for host-qemu-system,
> then surely you also need this version for host-qemu-user? So what is the point
> of treating them as separate packages? Isn't it much easier to build qemu-user
> and qemu-system in one shot (like how it's done for the target qemu)?
The only shared code in qemu for user vs. system is just basically CPU
emulation.
For system you've got all of the hardware (audio/ hw/ net/ directories
and so on) which isn't used by user at all.
For user it deals with what we can call "ABI" (userland, linux-user/ dir
in qemu) which isn't used by system at all, and has arch bits as well.
When there are system emulations broken with the latest version of qemu
it isn't necessarily a problem with the cpu emulation, the same can
happen to user emulation without affecting system.
So if you're like 100% sure user both will work right if system does for
X version go ahead, i don't think it's a safe assumption.
Just google around a bit:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
Regards.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-18 1:14 ` Gustavo Zacarias
@ 2014-10-19 20:27 ` Arnout Vandecappelle
2014-10-19 20:54 ` Thomas Petazzoni
0 siblings, 1 reply; 19+ messages in thread
From: Arnout Vandecappelle @ 2014-10-19 20:27 UTC (permalink / raw)
To: buildroot
On 18/10/14 03:14, Gustavo Zacarias wrote:
> On 10/17/2014 07:47 PM, Arnout Vandecappelle wrote:
>
>>> potentially miss the opportunity for new arch and/or platform support.
>>> So even if target != host version is fixed/possible you'll still clash
>>> on host-qemu (user) vs. host-qemu (system) versions since you might want
>>> to do the perl module dance (original purpose of host-qemu) vs. platform
>>> emulation.
>>
>> This one I don't understand. If you need version 2.0.2 for host-qemu-system,
>> then surely you also need this version for host-qemu-user? So what is the point
>> of treating them as separate packages? Isn't it much easier to build qemu-user
>> and qemu-system in one shot (like how it's done for the target qemu)?
>
> The only shared code in qemu for user vs. system is just basically CPU
> emulation.
> For system you've got all of the hardware (audio/ hw/ net/ directories
> and so on) which isn't used by user at all.
> For user it deals with what we can call "ABI" (userland, linux-user/ dir
> in qemu) which isn't used by system at all, and has arch bits as well.
> When there are system emulations broken with the latest version of qemu
> it isn't necessarily a problem with the cpu emulation, the same can
> happen to user emulation without affecting system.
> So if you're like 100% sure user both will work right if system does for
> X version go ahead, i don't think it's a safe assumption.
> Just google around a bit:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
So what I hear you say is that there really is a case for specifying the
qemu-user and qemu-system version separately, and that that's what this whole
discussion really is about. And I guess you may want to build at the same time a
host-qemu-user of one version and a host-qemu-system of another version, correct?
Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
nice to be able to factor that out somehow. However, it makes complete sense to
have them as separate packages first and merge them later.
So the question is: is the need for separate host-qemu-system and
host-qemu-user versions more important than the additional complexity of
specifying a nearly-identical .mk file twice?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-19 20:27 ` Arnout Vandecappelle
@ 2014-10-19 20:54 ` Thomas Petazzoni
2014-10-20 1:53 ` Gustavo Zacarias
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Petazzoni @ 2014-10-19 20:54 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Sun, 19 Oct 2014 22:27:11 +0200, Arnout Vandecappelle wrote:
> > The only shared code in qemu for user vs. system is just basically CPU
> > emulation.
> > For system you've got all of the hardware (audio/ hw/ net/ directories
> > and so on) which isn't used by user at all.
> > For user it deals with what we can call "ABI" (userland, linux-user/ dir
> > in qemu) which isn't used by system at all, and has arch bits as well.
> > When there are system emulations broken with the latest version of qemu
> > it isn't necessarily a problem with the cpu emulation, the same can
> > happen to user emulation without affecting system.
> > So if you're like 100% sure user both will work right if system does for
> > X version go ahead, i don't think it's a safe assumption.
> > Just google around a bit:
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
>
> So what I hear you say is that there really is a case for specifying the
> qemu-user and qemu-system version separately, and that that's what this whole
> discussion really is about. And I guess you may want to build at the same time a
> host-qemu-user of one version and a host-qemu-system of another version, correct?
>
> Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
> nice to be able to factor that out somehow. However, it makes complete sense to
> have them as separate packages first and merge them later.
>
> So the question is: is the need for separate host-qemu-system and
> host-qemu-user versions more important than the additional complexity of
> specifying a nearly-identical .mk file twice?
Despite Gustavo's explanation, I'm not sure to see what is the need to
have a different version for host-qemu-system and host-qemu-user.
If a given version of host-qemu-system works for a given
architecture/platform, then surely, host-qemu-user should work for the
same architecture. The opposite is obviously not true, but it doesn't
matter much: we can keep whatever version gets host-qemu-system working.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-19 20:54 ` Thomas Petazzoni
@ 2014-10-20 1:53 ` Gustavo Zacarias
2014-10-20 19:41 ` Arnout Vandecappelle
0 siblings, 1 reply; 19+ messages in thread
From: Gustavo Zacarias @ 2014-10-20 1:53 UTC (permalink / raw)
To: buildroot
On 10/19/2014 05:54 PM, Thomas Petazzoni wrote:
> On Sun, 19 Oct 2014 22:27:11 +0200, Arnout Vandecappelle wrote:
>
>> So what I hear you say is that there really is a case for specifying the
>> qemu-user and qemu-system version separately, and that that's what this whole
>> discussion really is about. And I guess you may want to build at the same time a
>> host-qemu-user of one version and a host-qemu-system of another version, correct?
>>
>> Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
>> nice to be able to factor that out somehow. However, it makes complete sense to
>> have them as separate packages first and merge them later.
>>
>> So the question is: is the need for separate host-qemu-system and
>> host-qemu-user versions more important than the additional complexity of
>> specifying a nearly-identical .mk file twice?
>
> Despite Gustavo's explanation, I'm not sure to see what is the need to
> have a different version for host-qemu-system and host-qemu-user.
>
> If a given version of host-qemu-system works for a given
> architecture/platform, then surely, host-qemu-user should work for the
> same architecture. The opposite is obviously not true, but it doesn't
> matter much: we can keep whatever version gets host-qemu-system working.
>
> Thomas
Arnout: yes, the package .mk could very much share everything that's
common among them yet still be a separate "package"
configuration/parameter-wise.
Thomas: you've got 3 scenarios, the cpu code is broken which won't
matter since both user/system will be broken for a given version, user
code broken which will matter to user only, hardware code broken which
will matter for system only.
Any of those can happen (even everything broken but it's basically the
same as the first option).
And if you're doing user-only for cross configure testing or whatnot
system won't be able to dictate which version you're using since it's a
config option outside of that scope.
To me it seems the decision was taken during the dev days with one-sided
arguments (against), but well life is like that sometimes.
The side effect is that it pushes my motivation to contribute to
buildroot to an all-time low (read that as you wish, in fact it may not
even matter).
Regards.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-20 1:53 ` Gustavo Zacarias
@ 2014-10-20 19:41 ` Arnout Vandecappelle
2014-10-20 21:16 ` Thomas Petazzoni
0 siblings, 1 reply; 19+ messages in thread
From: Arnout Vandecappelle @ 2014-10-20 19:41 UTC (permalink / raw)
To: buildroot
On 20/10/14 03:53, Gustavo Zacarias wrote:
[snip]
> To me it seems the decision was taken during the dev days with one-sided
> arguments (against), but well life is like that sometimes.
Well, there was nobody to provide counter-arguments. That's why I started the
discussion on the list.
It's very clear that version selection is needed. It's not so clear that a
separate version is really needed for host-qemu-system and host-qemu-user, because:
- there's a slightly larger chance that both system and user are broken;
- we currently anyway don't have version selection for user;
- we can change it later if required.
On the other hand, it's also possible to merge the qemu-system package now and
refactor it back into a single package later. It wouldn't even require legacy
handling because the config symbols already start with BR2_PACKAGE_QEMU.
So I'd propose to give Yann some time to produce a unified qemu package, but if
it doesn't come we can still merge your original patch.
> The side effect is that it pushes my motivation to contribute to
> buildroot to an all-time low (read that as you wish, in fact it may not
> even matter).
Since you're the #1 buildroot contributor and have been for some time now, it
really does matter!
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-20 19:41 ` Arnout Vandecappelle
@ 2014-10-20 21:16 ` Thomas Petazzoni
2014-10-20 22:45 ` Gustavo Zacarias
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Petazzoni @ 2014-10-20 21:16 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Mon, 20 Oct 2014 21:41:34 +0200, Arnout Vandecappelle wrote:
> Well, there was nobody to provide counter-arguments. That's why I started the
> discussion on the list.
>
> It's very clear that version selection is needed. It's not so clear that a
> separate version is really needed for host-qemu-system and host-qemu-user, because:
>
> - there's a slightly larger chance that both system and user are broken;
> - we currently anyway don't have version selection for user;
> - we can change it later if required.
>
> On the other hand, it's also possible to merge the qemu-system package now and
> refactor it back into a single package later. It wouldn't even require legacy
> handling because the config symbols already start with BR2_PACKAGE_QEMU.
>
> So I'd propose to give Yann some time to produce a unified qemu package, but if
> it doesn't come we can still merge your original patch.
I agree. Nothing is set in stone. At first sight, I don't really see a
reason to have a separate version for host-qemu-user and
host-qemu-system, so let's implement something that uses the same
version for both, and if reality proves that it was a bad choice, it
will also be time to change.
> > The side effect is that it pushes my motivation to contribute to
> > buildroot to an all-time low (read that as you wish, in fact it may not
> > even matter).
>
> Since you're the #1 buildroot contributor and have been for some time now, it
> really does matter!
Yes, it clearly matters. I'm a bit sad to see that this specific story
has affected your motivation. However, on this story, you had your own
idea, and basically rejected the comments that were made. That's not
really the best way to push things forward: maybe doing a concession
sometimes helps, and thanks to this concession, you might prove at a
later point that people were wrong and you were right from the
beginning :)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-20 21:16 ` Thomas Petazzoni
@ 2014-10-20 22:45 ` Gustavo Zacarias
2014-10-21 7:16 ` Thomas Petazzoni
0 siblings, 1 reply; 19+ messages in thread
From: Gustavo Zacarias @ 2014-10-20 22:45 UTC (permalink / raw)
To: buildroot
On 10/20/2014 06:16 PM, Thomas Petazzoni wrote:
>>> The side effect is that it pushes my motivation to contribute to
>>> buildroot to an all-time low (read that as you wish, in fact it may not
>>> even matter).
>>
>> Since you're the #1 buildroot contributor and have been for some time now, it
>> really does matter!
>
> Yes, it clearly matters. I'm a bit sad to see that this specific story
> has affected your motivation. However, on this story, you had your own
> idea, and basically rejected the comments that were made. That's not
> really the best way to push things forward: maybe doing a concession
> sometimes helps, and thanks to this concession, you might prove at a
> later point that people were wrong and you were right from the
> beginning :)
The same can be said the opposite way don't you think?
This patchset has been sitting for almost a year now with no action on
the counterproposal from anyone.
The likely outcome is that the feature will still be missing until the
next release cycle.
Either the feature is not interesting and/or wanted, or contributors
just lack time, with my time being wasted, waiting (possibly not very
patiently at times) for someone else to follow-up on the alternative.
I won't make a concession on this because i really don't believe it's
the proper course of action, it's that simple, deal with it.
It's not that i'm stubborn, i've changed opinion in many occasions, and
i'm not seeking to "rub it off" - if i wanted to do so i could just say
"hashes" which i've proposed years ago with the idea being very much
rejected at the time - i'm not interested in that.
It could be well thought-out from the start without the need to fix
issues that were foreseen later.
It's dissapointing to just sum up commits doing banal stuff even if
they're important, to then get the cold shoulder when what i feel are
interesting or progressive ideas get delayed and/or rejected.
My feeling is that i'm just wasting my time if i make any serious effort
to improve things, so basically i give up.
At this point i would have hoped that i've earned some trust with my
technical choices, but it feels like not.
That doesn't mean i want a blank check on decisions, don't get that
interpretation out of it.
In the end it's not the number of commits that count, that's not an
indication of who's #1, #3 or anything, it may be fun but that's it.
The momentum is what makes projects great.
And mine wrt buildroot has been neutralized, i'll just care about my
little ranch: no autobuild fixing except what i break, no improvements
except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no
opinions and so on.
Time will tell if i feel like getting back to that or i'll just dial
down the notch on general involvement permanently (there's a saying
which i think is quite universal "never say never").
Sometimes you win sometimes you lose, in both the project and personal
levels.
I hope i've articulated this mail correctly.
Regards.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-20 22:45 ` Gustavo Zacarias
@ 2014-10-21 7:16 ` Thomas Petazzoni
2014-10-21 18:20 ` Yann E. MORIN
2014-10-21 19:45 ` Arnout Vandecappelle
0 siblings, 2 replies; 19+ messages in thread
From: Thomas Petazzoni @ 2014-10-21 7:16 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Mon, 20 Oct 2014 19:45:06 -0300, Gustavo Zacarias wrote:
> > Yes, it clearly matters. I'm a bit sad to see that this specific story
> > has affected your motivation. However, on this story, you had your own
> > idea, and basically rejected the comments that were made. That's not
> > really the best way to push things forward: maybe doing a concession
> > sometimes helps, and thanks to this concession, you might prove at a
> > later point that people were wrong and you were right from the
> > beginning :)
>
> The same can be said the opposite way don't you think?
True in some way. But in another way, doing the concession on what gets
merged means reducing the "quality" of what we merge. Is this really
what we want? If something doesn't comply with the Buildroot coding
style and/or principles, should we merge it just because it has been
sitting there since one year?
> This patchset has been sitting for almost a year now with no action on
> the counterproposal from anyone.
> The likely outcome is that the feature will still be missing until the
> next release cycle.
I agree this isn't nice. But again, if there is a pending patch that
doesn't satisfy a majority of developers, should we merge it simply
because it has been pending for a long time? I'm sure you would agree
that we should not merge such a patch, even if that means leaving the
feature out of the tree for a while.
> I won't make a concession on this because i really don't believe it's
> the proper course of action, it's that simple, deal with it.
> It's not that i'm stubborn, i've changed opinion in many occasions, and
> i'm not seeking to "rub it off" - if i wanted to do so i could just say
> "hashes" which i've proposed years ago with the idea being very much
> rejected at the time - i'm not interested in that.
I don't remember if I was pro or against hashes back at the time.
Probably against, since when Yann proposed the patches, I was still a
bit hesitant about this feature.
> It's dissapointing to just sum up commits doing banal stuff even if
> they're important, to then get the cold shoulder when what i feel are
> interesting or progressive ideas get delayed and/or rejected.
> My feeling is that i'm just wasting my time if i make any serious effort
> to improve things, so basically i give up.
> At this point i would have hoped that i've earned some trust with my
> technical choices, but it feels like not.
> That doesn't mean i want a blank check on decisions, don't get that
> interpretation out of it.
You've definitely earned a *lot* of trust, at least to my eyes, and I
believe to many of the other Buildroot developers, Peter included. When
I see a patch from Gustavo doing something on a package, I typically
merge it eyes closed, or only after a quick look at the patch (I never
do any testing of your patches, because I know they basically work).
Beyond this qemu stuff, can you list the patch series/things you've
tried to push and that haven't been accepted? I think it's good to
discuss what caused the frustration.
> In the end it's not the number of commits that count, that's not an
> indication of who's #1, #3 or anything, it may be fun but that's it.
> The momentum is what makes projects great.
> And mine wrt buildroot has been neutralized, i'll just care about my
> little ranch: no autobuild fixing except what i break, no improvements
> except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no
> opinions and so on.
> Time will tell if i feel like getting back to that or i'll just dial
> down the notch on general involvement permanently (there's a saying
> which i think is quite universal "never say never").
> Sometimes you win sometimes you lose, in both the project and personal
> levels.
Wow, I must say I'm truly shocked that things have reached this level.
This is definitely not where I'd like things to go: your contributions
are very very valuable, and I very often need to refer to you for many
questions/opinions/feedback on various things we're doing in Buildroot.
Would you still be willing to have a Google Hangout at some point this
week to discuss this?
Live discussion very often helps, and it will allow us to exchange our
point of views, and see what we can do to resolve things. At some
point, it would be really great to meet in person, because I believe
you may not realize how much the Buildroot developers value and
respect your contribution.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-21 7:16 ` Thomas Petazzoni
@ 2014-10-21 18:20 ` Yann E. MORIN
2014-10-22 10:23 ` Peter Korsgaard
2014-10-21 19:45 ` Arnout Vandecappelle
1 sibling, 1 reply; 19+ messages in thread
From: Yann E. MORIN @ 2014-10-21 18:20 UTC (permalink / raw)
To: buildroot
Gustavo, All,
On 2014-10-21 09:16 +0200, Thomas Petazzoni spake thusly:
> On Mon, 20 Oct 2014 19:45:06 -0300, Gustavo Zacarias wrote:
[--SNIP--]
> > It's dissapointing to just sum up commits doing banal stuff even if
> > they're important, to then get the cold shoulder when what i feel are
> > interesting or progressive ideas get delayed and/or rejected.
> > My feeling is that i'm just wasting my time if i make any serious effort
> > to improve things, so basically i give up.
> > At this point i would have hoped that i've earned some trust with my
> > technical choices, but it feels like not.
> > That doesn't mean i want a blank check on decisions, don't get that
> > interpretation out of it.
>
> You've definitely earned a *lot* of trust, at least to my eyes, and I
> believe to many of the other Buildroot developers, Peter included.
I agree with Thomas: I too highly recognise your expertise, and that
has earned you my trust, for all the hard topics you have touched in
Buildroot (security, toolchains, weird archs...)
> > In the end it's not the number of commits that count, that's not an
> > indication of who's #1, #3 or anything, it may be fun but that's it.
> > The momentum is what makes projects great.
> > And mine wrt buildroot has been neutralized, i'll just care about my
> > little ranch: no autobuild fixing except what i break, no improvements
> > except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no
> > opinions and so on.
> > Time will tell if i feel like getting back to that or i'll just dial
> > down the notch on general involvement permanently (there's a saying
> > which i think is quite universal "never say never").
> > Sometimes you win sometimes you lose, in both the project and personal
> > levels.
I am really stunned to read that, and am really sorry you feel like
that. :-(
> Wow, I must say I'm truly shocked that things have reached this level.
> This is definitely not where I'd like things to go: your contributions
> are very very valuable, and I very often need to refer to you for many
> questions/opinions/feedback on various things we're doing in Buildroot.
I can only fully concur to what Thomas said.
> Would you still be willing to have a Google Hangout at some point this
> week to discuss this?
I could try to join, but as I am on the move in the US, it will be a bit
difficult for me. Just arrange for a day and time that suits you, and if
I am able to, I'll join.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-21 18:20 ` Yann E. MORIN
@ 2014-10-22 10:23 ` Peter Korsgaard
0 siblings, 0 replies; 19+ messages in thread
From: Peter Korsgaard @ 2014-10-22 10:23 UTC (permalink / raw)
To: buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
Sorry for slow response - I've been busy with family stuff since I got
home from Dusseldorf. I'm now in the airport leaving for the GSoC
summit.
>> You've definitely earned a *lot* of trust, at least to my eyes, and I
>> believe to many of the other Buildroot developers, Peter included.
> I agree with Thomas: I too highly recognise your expertise, and that
> has earned you my trust, for all the hard topics you have touched in
> Buildroot (security, toolchains, weird archs...)
I think we all do. I in general merge Gustavo's patches very fast as
they very rarely have issues.
>> > Time will tell if i feel like getting back to that or i'll just dial
>> > down the notch on general involvement permanently (there's a saying
>> > which i think is quite universal "never say never").
>> > Sometimes you win sometimes you lose, in both the project and personal
>> > levels.
> I am really stunned to read that, and am really sorry you feel like
> that. :-(
So am I! I must say it comes as quite a shock to me.
>> Would you still be willing to have a Google Hangout at some point this
>> week to discuss this?
> I could try to join, but as I am on the move in the US, it will be a bit
> difficult for me. Just arrange for a day and time that suits you, and if
> I am able to, I'll join.
I'm in the same situation as Yann, but I'll join if at all possible.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/3] qemu-system: new package
2014-10-21 7:16 ` Thomas Petazzoni
2014-10-21 18:20 ` Yann E. MORIN
@ 2014-10-21 19:45 ` Arnout Vandecappelle
1 sibling, 0 replies; 19+ messages in thread
From: Arnout Vandecappelle @ 2014-10-21 19:45 UTC (permalink / raw)
To: buildroot
On 21/10/14 09:16, Thomas Petazzoni wrote:
> Dear Gustavo Zacarias,
>
> On Mon, 20 Oct 2014 19:45:06 -0300, Gustavo Zacarias wrote:
>
> >> Yes, it clearly matters. I'm a bit sad to see that this specific story
> >> has affected your motivation. However, on this story, you had your own
> >> idea, and basically rejected the comments that were made. That's not
> >> really the best way to push things forward: maybe doing a concession
> >> sometimes helps, and thanks to this concession, you might prove at a
> >> later point that people were wrong and you were right from the
> >> beginning :)
> >
> > The same can be said the opposite way don't you think?
>
> True in some way. But in another way, doing the concession on what gets
> merged means reducing the "quality" of what we merge. Is this really
> what we want? If something doesn't comply with the Buildroot coding
> style and/or principles, should we merge it just because it has been
> sitting there since one year?
I wouldn't say it's really a matter of quality. We (or actually, the committers)
tend to be conservative when it comes to merging. In particular, if any controversy
exists over a patch, it just remains sitting in the queue.
It could be debated whether this is a good thing. But it is the way we work at
the moment.
But the end result that such controversial patches stay in patchwork for a long
time, nobody comments on them anymore, so the discussion essentially dies. And
then comes along a patchwork cleanup rush, and things get rejected.
As you mention below w.r.t. the hashes, it's very well possible that a year later
the original idea does suddenly get accepted...
Regards,
Arnout
>
> > This patchset has been sitting for almost a year now with no action on
> > the counterproposal from anyone.
> > The likely outcome is that the feature will still be missing until the
> > next release cycle.
>
> I agree this isn't nice. But again, if there is a pending patch that
> doesn't satisfy a majority of developers, should we merge it simply
> because it has been pending for a long time? I'm sure you would agree
> that we should not merge such a patch, even if that means leaving the
> feature out of the tree for a while.
>
> > I won't make a concession on this because i really don't believe it's
> > the proper course of action, it's that simple, deal with it.
> > It's not that i'm stubborn, i've changed opinion in many occasions, and
> > i'm not seeking to "rub it off" - if i wanted to do so i could just say
> > "hashes" which i've proposed years ago with the idea being very much
> > rejected at the time - i'm not interested in that.
>
> I don't remember if I was pro or against hashes back at the time.
> Probably against, since when Yann proposed the patches, I was still a
> bit hesitant about this feature.
>
[snip]
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 19+ messages in thread