Re: [OE-core] [Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig

From: Bruce Ashfield <bruce.ashfield@gmail.com>
To: bruce.ashfield@gmail.com
Cc: Ross Burton <ross.burton@arm.com>,
	poky@lists.yoctoproject.org,
	 openembedded-core@lists.openembedded.org,
	 openembedded-architecture@lists.openembedded.org
Subject: Re: [OE-core] [Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig
Date: Wed, 21 Feb 2024 08:37:43 -0500	[thread overview]
Message-ID: <CADkTA4PkLGBzL82d8cuO0d0+vP5jm2W2ZAZn=aZDfz4weJOzYQ@mail.gmail.com> (raw)
In-Reply-To: <17B5E41BBD3629FA.11907@lists.openembedded.org>

I should add that if just doing this for qemu is acceptable, I can take
over the task of creating the configuration fragments with what remains
for the week.

Are the MACHINE configs and everything else I need already in OE-core
or available somewhere that I can find ?

Bruce

On Wed, Feb 21, 2024 at 8:34 AM Bruce Ashfield via
lists.openembedded.org
<bruce.ashfield=gmail.com@lists.openembedded.org> wrote:
>
> 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.burton@arm.com> wrote:
> >
> > From: Ross Burton <ross.burton@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/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II