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....@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.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
>
>
>
--
- 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 (#195973):
https://lists.openembedded.org/g/openembedded-core/message/195973
Mute This Topic: https://lists.openembedded.org/mt/104488097/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
