The defconfigs use a 5.19 kernel, so specify 5.19 kernel headers now that is
available.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the kernel version for all riscv nommu configs from 5.18 to 5.19.
That way, we can remove the one and only riscv nommu patch,
since this patch is included in kernel 5.19.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Add a buildroot configuration file to build a minimal Linux environment
for the Canaan KD233 board.
The configuration file is canaan_kd233_defconfig. It builds a bootable
kernel image with an embedded initramfs root file system. The image
built can be flashed to the board as is and does not require a boot
loader. This configuration uses the tiny busybox configuration defined
in board/canaan/k210-soc/busybox-tiny.config.
U-Boot currently does not support this board, making it impossible to
boot the kernel after loading it from the SD card. However, the SD card
is usable from Linux once booted using the canaan_kd233_defconfig
configuration.
The configuration also enable the kflash and pyserial-miniterm host
tools for flashing image files to the board and opening a terminal
console.
The readme.txt file documents how to build and boot the Canaan KD233
board with this configuration.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
