I'm quite simply a hard NACK on this.
Everyone can feel free to overrule me here, but I won't be able to
maintain this along with the other board that I test each -dev,
variant and -stable bump with.
There are tools, etc, that while gathering dust can help chop up a
config, and that's where we can spend the time, along with making sure
the fragments make sense and are usable.
We all agreed to hold the reference boards to a higher standard, and
now I see this. So as tired and frustrated as you say you are,
multiply that by two with me.
Cheers,
Bruce
On Wed, Feb 21, 2024 at 5:57 AM Ross Burton <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?
>
> 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.
>
> 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
> 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
>
>
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195972):
https://lists.openembedded.org/g/openembedded-core/message/195972
Mute This Topic: https://lists.openembedded.org/mt/104488028/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
