poky.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: ross.burton@arm.com
To: poky@lists.yoctoproject.org
Cc: openembedded-core@lists.openembedded.org,
	openembedded-architecture@lists.openembedded.org
Subject: [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig
Date: Wed, 21 Feb 2024 10:57:23 +0000	[thread overview]
Message-ID: <20240221105723.1501833-1-ross.burton@arm.com> (raw)

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



             reply	other threads:[~2024-02-21 10:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21 10:57 ross.burton [this message]
2024-02-21 11:21 ` [Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig Richard Purdie
2024-02-21 13:33 ` Bruce Ashfield
     [not found] ` <17B5E41BBD3629FA.11907@lists.openembedded.org>
2024-02-21 13:37   ` [OE-core] " Bruce Ashfield
2024-02-21 15:06 ` Paul Barker
2024-02-22  3:21   ` [poky] " Mark Hatle
2024-02-21 19:29 ` paulg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240221105723.1501833-1-ross.burton@arm.com \
    --to=ross.burton@arm.com \
    --cc=openembedded-architecture@lists.openembedded.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=poky@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).