Wireless regulatory database lists the allowed radio frequencies for
each local jurisdiction. Since linux-4.15 the kernel supports loading
the files regulatory.db/regulatory.db.p7s directly from the
/lib/firmware directory. Currently this package is not enabled and
kernel complains with the following message on every boot:
"""
platform regulatory.0: Direct firmware load for regulatory.db failed
with error -2
cfg80211: failed to load regulatory.db
"""
Add wireless regulatory database package to fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
objtool built by the kernel requires libelf
ldd output/build/linux-6.1.24/tools/objtool/objtool
linux-vdso.so.1
libelf.so.1 => output/host/lib/libelf.so.1
While updating the kernel [1] we forgot to select
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF to provide Buildroot's host-libelf.
Using host-libelf avoid linking with libelf installed on the host or
failing to build objtool if libelf is not installed.
[1] d45538f2e7
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4889436869https://gitlab.com/buildroot.org/buildroot/-/jobs/4889436872
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Let's use a more modern kernel with a broader range of hardware support
for PCs.
We stick to 6.1, rather than 6.2, as the former is an LTS, whicle the
latter is not.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Following the switch to Glibc as the default libc in Buildroot [1],
all defconfigs expecting uClibc with wchar (or any other uClibc
specific option) should now select BR2_TOOLCHAIN_BUILDROOT_UCLIBC too.
Even if all defconfigs has been tested with uClibc, maintainers
prefer to not enforce a C library and use the default of Buildroot,
which is now glibc.
This commit remove uClibc specific options BR2_TOOLCHAIN_BUILDROOT_WCHAR,
BR2_PTHREAD_DEBUG (required by gdb) and BR2_TOOLCHAIN_BUILDROOT_USE_SSP.
Since glibc always has argp built-in, also remove the standalone one
from affected toolchains...
Fixes:
https://gitlab.com/kubu93/buildroot/-/jobs/2911738579
[1] 4057e36ca9
[2] http://lists.busybox.net/pipermail/buildroot/2022-August/649998.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[yann.morin.1998@free.fr: also drop argp-standalone]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
gcc 10.x is now used by default but the kernel 4.18.10 used by
pc_x86_64_{efi,bios}_defconfig doesn't build with it.
Bump the kernel to 4.19.204 release that contains a lot of
fixes for newer gcc.
Fixes:
https://gitlab.com/kubu93/buildroot/-/jobs/1525741062https://gitlab.com/kubu93/buildroot/-/jobs/1525741060
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Thanks to the introduction of GPT partition table support in genimage,
this commit improves the pc_x86_64_efi_defconfig to remove the use of
the custom script creating the image.
Tested in QEMU, not on a physical device.
So:
- revert commit fee29b05bb7db25e37c8a5175ce00dc712554edf[1]
- add GPT support
- tweak shell script to add the correct UUID in genimage config.
[1]: https://git.buildroot.net/buildroot/commit/?id=fee29b05bb7db25e37c8a5175ce00dc712554edf
[2]: https://git.buildroot.net/buildroot/commit/?id=79b8540d624ac4846ba341b1b9691eccacf0bc05
Signed-off-by: Alexandre PAYEN <alexandre.payen@smile.fr>
Cc: Carlos Santos <casantos@datacom.com.br>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas:
- drop commented code in post-build.sh
- take into account comments made by Carlos Santos in
http://patchwork.ozlabs.org/patch/1143502/]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since all EFI-based systems support GPT, this commit changes
pc_x86_64_efi to use a GPT partition table. It shows an example of how
to craft a disk image with GPT partitioning instead of MBR. This is
achieved by means of a post-image script which uses
mkdosfs+mcopy+sfdisk, since genimage is unable to deal with GPT. Long
term, it would be ideal if genimage had GPT support, but until then,
this script shows how to achieve creating a GPT-based disk image.
The script was kept as simple as possible to make it easy to understand
and adapt for other purposes.
The root filesystem location is passed to the kernel by a partition
UUID, so it is possible to boot on QEMU, directly from the disk image,
or dump the image to a physical device.
Signed-off-by: Carlos Santos <casantos@datacom.com.br>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Before this commit, the grub configuration file was copied to the
TARGET_DIR in a post-image hook, after the filesystem has been
generated. It was kinda working because the board/pc's grub
configuration and the default one are the same and the later was
copied during the build process of the grub2 package.
This commit ensures the custom board/pc grub configuration is copied at
the right time.
Signed-off-by: Grégoire Delattre <gregoire.delattre@gmail.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump the kernel version to 4.18.10.
Tested with qemu 2.11.2 on bios and UEFI virtual machines.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This simplifies the pc configs and respective post image scripts to use
the shared genimage script and separate grub config files.
Separate grub files are cleaner to maintain and easier to copy and
modify, for example to support booting the pc defconfigs in qemu.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump the kernel version to 4.13.8.
Tested with qemu 2.9.1 on bios and UEFI virtual machines.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This change deprecates the ext2/3/4 rootfs size in blocks symbol in
favor of one that mimic the fs-size argument behavior of mkfs (i.e.
size in a human readable format accepting k, m, g or t suffix or their
upper-case variants).
This change also updates the defconfigs that used to set
BR2_TARGET_ROOTFS_EXT2_BLOCKS symbol.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reusing the qemu x86-64 linux config isn't very obvious, so these defconfigs
aren't taken into consideration when the qemu defconfigs are updated,
breaking the build.
Instead use a custom linux config for the pc defconfigs. With this, we also
can get rid of the fragment file containing the delta fra the qemu config.
Created by linux-update-defconfig (after turning of the fragment file).
Also drop the linux kernel version number from the file name as it just
causes extra noise whenever the kernel is bumped.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The pc_x86_64 defconfigs reuse the linux configuration from qemu_x86_64, but
they weren't adjusted when this was updated to use linux-4.11 in 28d97609b2
(configs/qemu: bump to the latest kernel version), breaking the build.
Fix it by also moving them to linux-4.11.x.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit c6bca8cef0 removed autocalculation of the ext2 filesystem
size, the default size is now set to 60MB. However, this is too small
for pc_x86_64_efi_defconfig. Indeed, the ext2 filesystem contains the
kernel (4MB), the wireless modules (4MB), all firmware for wireless
modules (40MB), and the wifi userspace (9MB) and the udev hwdb (5MB)
which brings the total to 70MB.
Increase the filesystem size to 120000K, which is a nice and round
number and leaves enough space for overhead on a 128MB flash drive.
Fixes:
https://gitlab.com/buildroot.org/buildroot/builds/15762234
This commit is identical to 9c393ad2fd
from Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>, except it
is done for pc_x86_64_efi_defconfig.
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.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>
To match it's friendly qemu counterpart.
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>
Add two new sample defconfigs oriented towards real PC targets.
It adds two variants for BIOS and EFI boot strategy.
On the build side we enable eudev to autoload relevant kernel
modules/support when necessary.
It adds a bunch of drivers and extra filesystem support which is by no
means extensive/complete, mostly geared towards the hardware i've got at
hand to test with.
This is accomplished by adding on top of the Qemu x86_64 kernel sample
config.
Build connman since by using eudev network interfaces get renamed on
boot thus complicating any form of automatic and friendly bringup.
It also makes Wi-Fi configuration/support easier.
In principle these base defconfigs should work just fine for other
storage media != pendrive like sata or ssd disk, however driver support
isn't there quite yet, and pendrive is mostly supported by usb storage
plus the usual usb host controller drivers.
Tested on old Lenovo laptop (BIOS) and Asus Zenbook (EFI).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
