From: Paul Gortmaker <pa...@kernel.org>
[[RFC PATCH] Add genericarm64 MACHINE using upstream defconfig] On 21/02/2024
(Wed 10:57) ross.bur...@arm.com wrote:
> From: Ross Burton <ross.bur...@arm.com>
>
> This is a new 64-bit "generic" Arm machine, that expects the hardware to
> be SystemReady IR compatible. This is slightly forward-leaning as there's
> not a _lot_ of SystemReady hardware in the wild, but most modern boards
> are and the number will only grow. Also, this is the only way to have a
> 'generic' machine as without standardised bootloaders and firmware it
> would be impossible.
>
> The base machine configuration isn't that exciting: it's a fully featured
> machine that supports most things, booting via UEFI and an initramfs.
>
> However, the kernel is more interesting. This RFC uses the upstream defconfig
> because unlike some other platforms, the arm64 defconfig is actively
> maintained with the goal of being a 'boots on most hardware' configuration.
> My argument is: why would we duplicate that effort?
I have no problem with the idea of a genericarm64, but the defconfig
approach is not the way to go.
> The "linux-yocto way" is configuration fragments and after a week of
> hair-pulling I do actually have fragments that boot on a BeaglePlay, but
> to say this was a tiresome and frustrating exercise would be understating it.
Yes, if you start with a giant "defconfig" file and try and slowly chip
away at it, it can be frustrating and time consuming. I never do that.
It is the same problem space as trying to turn core-image-full-cmdline
into core-image-minimal by removing one package at a time. Always
easier to start with the bare minimum and then add stuff.
> So, a request for comments: is it acceptable to use the upstream defconfig in
> a reference BSP? Personally I'm torn: the Yocto way is fragments not
> monolithic
In a word, the answer is "no".
Let me insert a bit of history here - darn near 20y ago now - when we
were just starting out with linux, we had BSPs on different kernel
versions, and worse - the use of flat monolithic "defconfig" type files
on a per BSP basis. The latter was to be blunt, just crap. There was
no uniformity across BSPs in the same "family" - where family would be
something like CGL back in the 2005 era.
One BSP might have built iso9660 fs, another one not. Or one enabled
some debug option and another one didn't. The inconsistency was just
horrible and unbearable. BSPs were screwing with options they had no
business touching.
After a couple years of that mess, I believe several of us (which
included Bruce and myself) had just about enough. What we came up with
was isolating the board config to a select subset of hardware/driver
Kconfig options and the "platform" would handle "non-harware" options.
That largely is still what exists in Yocto today, even though we were
not using Yocto waaay back then. It immediately brought consistency
across platforms, and a stark clarity to exactly what the board required
for Kconfig settings - typically less than a screen full - choose the
CPU and the driver for video and disk/flash and USB chip etc. Compare
that to the unreadable 10,000+ lines in a defconfig now.
So, yes I'll grant you that making that one screen full of core hardware
settings can be frustrating. But at the same time, it has also served
as a valuable filter. If a person can't distill a BSP down into the
core options it *really* needs, then they typically either don't
understand the hardware, or are just not invested enough to go that
extra mile. I'm not saying either is the case here - just in general.
On top of all that - we've had similar discussions before along similar
lines - where Yocto/OE are not RedHat or Ubuntu - where we try and
deliver a distro with "one config works everywhere" kind of stuff.
I'm fine with genericarm64 - but please please don't encourage the chaos
and madness associated with random unmaintainable defconfigs! Just
because it exists upstream doesn't mean it is good.
Thanks,
Paul.
> configs, but repeating the effort to fragmentise the configuration and then
> also have it sufficiently modular that it can be used in pieces - instead of
> just being a large file split up into smaller files - is a lot of effort for
> what might end up being minimal gain. My fear is we end up with a fragmented
> configuration that can't be easily modified without breaking some platforms,
> and badly copies what the defconfig already does.
>
> Ross
> ---
> meta-yocto-bsp/README.hardware.md | 7 +++++
> meta-yocto-bsp/conf/machine/genericarm64.conf | 26 +++++++++++++++++++
> .../linux/linux-yocto_6.6.bbappend | 9 +++++++
> meta-yocto-bsp/wic/genericarm64.wks.in | 11 ++++++++
> 4 files changed, 53 insertions(+)
> create mode 100644 meta-yocto-bsp/conf/machine/genericarm64.conf
> create mode 100644 meta-yocto-bsp/wic/genericarm64.wks.in
>
> diff --git a/meta-yocto-bsp/README.hardware.md
> b/meta-yocto-bsp/README.hardware.md
> index a8f38cb21a6..58ebc328b56 100644
> --- a/meta-yocto-bsp/README.hardware.md
> +++ b/meta-yocto-bsp/README.hardware.md
> @@ -29,6 +29,7 @@ The following boards are supported by the meta-yocto-bsp
> layer:
>
> * Texas Instruments Beaglebone (beaglebone-yocto)
> * General IA platforms (genericx86 and genericx86-64)
> + * General 64-bit Arm SystemReady platforms (genericarm64)
>
> For more information see the board's section below. The appropriate MACHINE
> variable value corresponding to the board is given in brackets.
> @@ -126,6 +127,12 @@ USB Device:
> dd command to write the image to a USB stick.
>
>
> +SystemReady Arm Platforms
> +=========================
> +
> +TODO
> +
> +
> Texas Instruments Beaglebone (beaglebone-yocto)
> ===============================================
>
> diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf
> b/meta-yocto-bsp/conf/machine/genericarm64.conf
> new file mode 100644
> index 00000000000..2ea270d8b06
> --- /dev/null
> +++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
> @@ -0,0 +1,26 @@
> +#@TYPE: Machine
> +#@NAME: genericarm64
> +#@DESCRIPTION: Generic Arm64 machine for typical SystemReady platforms, which
> +#have working firmware and boot via EFI.
> +
> +require conf/machine/include/arm/arch-armv8a.inc
> +
> +# Arm Base System Architecture says v8.0+ is allowed, but FEAT_CRC32 is
> required
> +DEFAULTTUNE = "armv8a-crc"
> +
> +MACHINE_FEATURES = "acpi alsa bluetooth efi keyboard pci qemu-usermode rtc
> screen usbhost vfat wifi"
> +
> +# Install all the kernel modules and all the firmware
> +MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
> +
> +KERNEL_IMAGETYPE = "Image"
> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> +INITRAMFS_IMAGE ?= "core-image-initramfs-boot"
> +
> +IMAGE_FSTYPES ?= "wic"
> +WKS_FILE ?= "genericarm64.wks.in"
> +
> +EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd",
> "systemd-boot", "grub-efi", d)}"
> +
> +# Try to bring up one physical serial console, or a virtualized serial
> console
> +SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
> diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
> b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
> index 8e465c241e8..18f95de348f 100644
> --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
> +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
> @@ -1,19 +1,28 @@
> KBRANCH:genericx86 = "v6.6/standard/base"
> +KBRANCH:genericarm64 = "v6.6/standard/base"
> KBRANCH:genericx86-64 = "v6.6/standard/base"
> KBRANCH:beaglebone-yocto = "v6.6/standard/beaglebone"
>
> +KMACHINE:genericarm64 ?= "genericarm64"
> KMACHINE:genericx86 ?= "common-pc"
> KMACHINE:genericx86-64 ?= "common-pc-64"
> KMACHINE:beaglebone-yocto ?= "beaglebone"
>
> +SRCREV_machine:genericarm64 ?= "332d4668fcc32826907d4f3c4938845206006089"
> SRCREV_machine:genericx86 ?= "332d4668fcc32826907d4f3c4938845206006089"
> SRCREV_machine:genericx86-64 ?= "332d4668fcc32826907d4f3c4938845206006089"
> SRCREV_machine:beaglebone-yocto ?= "332d4668fcc32826907d4f3c4938845206006089"
>
> +COMPATIBLE_MACHINE:genericarm64 = "genericarm64"
> COMPATIBLE_MACHINE:genericx86 = "genericx86"
> COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
> COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
>
> +LINUX_VERSION:genericarm64 = "6.6.15"
> LINUX_VERSION:genericx86 = "6.6.15"
> LINUX_VERSION:genericx86-64 = "6.6.15"
> LINUX_VERSION:beaglebone-yocto = "6.6.15"
> +
> +# Use upstream defconfig for genericarm64
> +KBUILD_DEFCONFIG:genericarm64 = "defconfig"
> +KCONFIG_MODE:genericarm64 = "--alldefconfig"
> diff --git a/meta-yocto-bsp/wic/genericarm64.wks.in
> b/meta-yocto-bsp/wic/genericarm64.wks.in
> new file mode 100644
> index 00000000000..417d4d88104
> --- /dev/null
> +++ b/meta-yocto-bsp/wic/genericarm64.wks.in
> @@ -0,0 +1,11 @@
> +# short-description: Create an EFI disk image
> +# long-description: Creates a partitioned EFI disk image that the user
> +# can directly dd to boot media.
> +
> +part /boot --source bootimg-efi
> --sourceparams="loader=${EFI_PROVIDER},initrd=${INITRAMFS_IMAGE}-${MACHINE}.${INITRAMFS_FSTYPES}"
> --label boot --active --align 1024 --use-uuid
> +
> +part / --source rootfs --fstype=ext4 --label root --align 1024 --use-uuid
> +
> +part swap --size 44 --label swap --fstype=swap --use-uuid
> +
> +bootloader --ptable gpt --timeout=5 --append="rootwait rootfstype=ext4"
> --
> 2.34.1
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195983):
https://lists.openembedded.org/g/openembedded-core/message/195983
Mute This Topic: https://lists.openembedded.org/mt/104485830/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
