kumquat-buildroot/configs/qemu_xtensa_lx60_nommu_defconfig

41 lines
1.2 KiB
Plaintext
Raw Normal View History

# Architecture
BR2_xtensa=y
BR2_XTENSA_CUSTOM=y
BR2_XTENSA_OVERLAY_FILE="https://github.com/jcmvbkbc/xtensa-toolchain-build/raw/95291b7c39e6f790d0b2f062c945a630290f2c81/overlays/xtensa_dc233c.tar.gz"
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
# BR2_XTENSA_USE_MMU is not set
# Use minimal busybox with hush and networking tools
BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config"
# System
BR2_SYSTEM_DHCP="eth0"
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
# Filesystem
# BR2_TARGET_ROOTFS_TAR is not set
BR2_TARGET_ROOTFS_INITRAMFS=y
# Image
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/qemu/post-image.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="$(BR2_DEFCONFIG)"
# Linux headers same as kernel
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_1=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.1.26"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
qemu: update defconfigs to Linux 4.16.7 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>
2018-06-02 22:07:20 +02:00
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/xtensa-lx60/linux-nommu.config"
BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
BR2_LINUX_KERNEL_IMAGE_NAME="Image.elf"
configs/qemu: bump to the latest kernel version 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>
2017-06-05 21:52:07 +02:00
BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="Image"
# Kernel needs mkimage
BR2_PACKAGE_HOST_UBOOT_TOOLS=y
# host-qemu for gitlab testing
BR2_PACKAGE_HOST_QEMU=y
BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y