Message ID | 20240221105723.1501833-1-ross.burton@arm.com |
---|---|
State | New |
Headers | show |
Series | [RFC] Add genericarm64 MACHINE using upstream defconfig | expand |
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/RFC-Add-genericarm64-MACHINE-using-upstream-defconfig.patch FAIL: test Signed-off-by presence: Mbox is missing Signed-off-by. Add it manually or with "git commit --amend -s" (test_mbox.TestMbox.test_signed_off_by_presence) FAIL: test shortlog format: Commit shortlog (first line of commit message) should follow the format "<target>: <summary>" (test_mbox.TestMbox.test_shortlog_format) PASS: test author valid (test_mbox.TestMbox.test_author_valid) PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence) PASS: test max line length (test_metadata.TestMetadata.test_max_line_length) PASS: test mbox format (test_mbox.TestMbox.test_mbox_format) PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade) PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length) SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint) SKIP: pretest src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.pretest_src_uri_left_files) SKIP: test CVE check ignore: No modified recipes, skipping test (test_metadata.TestMetadata.test_cve_check_ignore) SKIP: test CVE tag format: No new CVE patches introduced (test_patch.TestPatch.test_cve_tag_format) SKIP: test Signed-off-by presence: No new CVE patches introduced (test_patch.TestPatch.test_signed_off_by_presence) SKIP: test Upstream-Status presence: No new CVE patches introduced (test_patch.TestPatch.test_upstream_status_presence_format) SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format) SKIP: test lic files chksum modified not mentioned: No modified recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned) SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence) SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence) SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint) SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head) SKIP: test src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.test_src_uri_left_files) SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence) SKIP: test target mailing list: Series merged, no reason to check other mailing lists (test_mbox.TestMbox.test_target_mailing_list) --- Please address the issues identified and submit a new revision of the patch, or alternatively, reply to this email with an explanation of why the patch should be accepted. If you believe these results are due to an error in patchtest, please submit a bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category under 'Yocto Project Subprojects'). For more information on specific failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank you!
On Wed, 2024-02-21 at 10:57 +0000, Ross Burton 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? Can you point at the policy/process which decides how a config option makes it in there? > 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. Let me play devils advocate. I do understand it is a pain, equally, once you do have it working, it is something you rarely have to touch again for a given board. In the context of linux-yocto, I suspect we'd end up with a few board specific lists of config options (fragments) that board *really* needs. genericarm64 would end up as the sum of all those configs, plus any other bits which you really want in a generic machine, presumably the genericx86 machines have an idea of that. The advantage here is that you give the users three options: a) the kitchen sink upstream "systemready" defconfig b) the genericarm64 machine defconfig which works most places and is 'guaranteed' on our target test platforms c) a machine targeted defconfig with only what a board needs Developers/users end up in different places at different points in there lifecycles. For in depth development, you might like to be able to cut the kernel down so you'd not rebuilding tons of stuff you don't need/use/care about each time, nor transferring it to a device during updates. For a specific product release, you again might want to trim it down to what it needs. If you're shipping demo software, a full systemready image would be much more appropriate. I think it comes down to whether the fragments are usable and testable. We have a list of targets we want this new machine to run on so lets start with those, define genericarm64 as that set of fragments combined plus the generic pieces linux-yocto adds, then go from there. If you add a new machine to the test matrix, we add a new fragment. If someone wants to add new config, they need to show a machine using it. Cheers, Richard
Hi, On Wed, Feb 21, 2024 at 11:21:39AM +0000, Richard Purdie wrote: > On Wed, 2024-02-21 at 10:57 +0000, Ross Burton 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? > > Can you point at the policy/process which decides how a config option > makes it in there? > > > 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. > > Let me play devils advocate. > > I do understand it is a pain, equally, once you do have it working, it > is something you rarely have to touch again for a given board. > > In the context of linux-yocto, I suspect we'd end up with a few board > specific lists of config options (fragments) that board *really* needs. > genericarm64 would end up as the sum of all those configs, plus any > other bits which you really want in a generic machine, presumably the > genericx86 machines have an idea of that. > > The advantage here is that you give the users three options: > > a) the kitchen sink upstream "systemready" defconfig > b) the genericarm64 machine defconfig which works most places and� > is�'guaranteed' on our target test platforms > c) a machine targeted defconfig with only what a board needs > > Developers/users end up in different places at different points in > there lifecycles.� > > For in depth development, you might like to be able to cut the kernel > down so you'd not rebuilding tons of stuff you don't need/use/care > about each time, nor transferring it to a device during updates. > > For a specific product release, you again might want to trim it down to > what it needs. > > If you're shipping demo software, a full systemready image would be > much more appropriate. > > I think it comes down to whether the fragments are usable and testable. > We have a list of targets we want this new machine to run on so lets > start with those, define genericarm64 as that set of fragments combined > plus the generic pieces linux-yocto adds, then go from there. If you > add a new machine to the test matrix, we add a new fragment. If someone > wants to add new config, they need to show a machine using it. FWIW, we have been using upstream kernel.org aarch64 defconfig plus few board specific fragments and few extra features for our testing needs. I have been very happy that several major kernel version updates have already been done this way and zero adaptations needed on our side for the ARM SystemReady boards and firmware which we support. A simple CI run to show passing test results was sufficient for a poky update with new kernel major version. The implementation here looks pretty much like ours. Looks good, thanks Ross! More details of our setup: https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/main/meta-ledge-secure/recipes-kernel/linux/linux-ledge-common.inc?ref_type=heads https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/tree/main/meta-ledge-secure/recipes-kernel/linux/ledgearm64-kmeta?ref_type=heads https://trs.readthedocs.io/en/latest/ Cheers, -Mikko
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 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#1966): https://lists.openembedded.org/g/openembedded-architecture/message/1966 > Mute This Topic: https://lists.openembedded.org/mt/104485828/1050810 > Group Owner: openembedded-architecture+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
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] > -=-=-=-=-=-=-=-=-=-=-=- >
Hi, On Wed, Feb 21, 2024 at 03:23:48PM +0200, Mikko Rapeli via lists.openembedded.org wrote: > FWIW, we have been using upstream kernel.org aarch64 defconfig plus > few board specific fragments and few extra features for our testing needs. > I have been very happy that several major kernel version updates have already > been done this way and zero adaptations needed on our side for the > ARM SystemReady boards and firmware which we support. A simple CI run to show > passing test results was sufficient for a poky update with new kernel > major version. > > The implementation here looks pretty much like ours. Looks good, thanks Ross! > > More details of our setup: > > https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/main/meta-ledge-secure/recipes-kernel/linux/linux-ledge-common.inc?ref_type=heads > https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/tree/main/meta-ledge-secure/recipes-kernel/linux/ledgearm64-kmeta?ref_type=heads > https://trs.readthedocs.io/en/latest/ Our machine is based on poky qemuarm64 machine and thus uses KBRANCH:qemuarm64 so I don't see a need for new branch from linux-yocto recipe maintainer. https://git.yoctoproject.org/linux-yocto/log/?h=v6.5/standard/qemuarm64 But maybe I don't see the full picture. Cheers, -Mikko
On 21/02/2024 10:57, Ross Burton 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. I am in favour of this - I think the "genericarm64" machine should use the in-tree defconfig so that it can support the widest array of hardware. If someone wants to trim down the kernel for a particular platform then they should probably create a specific MACHINE anyway. If we take the other approach of building up the kernel config from fragments, how would we know that all SystemReady IR capable systems will be supported? Yocto Project doesn't have the resources to test every platform. For the Renesas RZ SoCs I work on these days, the in-tree defconfig is the configuration we test with the mainline kernel. Thanks,
On Wed, Feb 21, 2024 at 03:21 AM, Richard Purdie wrote: > > I think it comes down to whether the fragments are usable and testable. > We have a list of targets we want this new machine to run on so lets > start with those, define genericarm64 as that set of fragments combined > plus the generic pieces linux-yocto adds, then go from there. If you > add a new machine to the test matrix, we add a new fragment. If someone > wants to add new config, they need to show a machine using it. Although Ross mentioned that there are not a lot of SystemReady IR compatible hardware in the wild, we're already talking about tens of them in existence. With this approach the genericarm64 machine will be compatible with only some of them unless we test all of the certified platforms and update kernel fragments accordingly. The whole idea of SystemReady+defconfig is that it would allow to avoid future maintenance of kernel fragments in Yocto for existing and new SR certified platforms. If a platform is SystemReady certified (i.e. required drivers are up-streamed and mainline defconfig is updated) then the genericarm64 Yocto image would "just work". On the last Yocto summit Bruce mentioned a tool which can automate defconfig -> kernel fragments conversion. Using this tool as a part of kernel versions updates in Yocto might solve the problem for genericarm64. But, I don't know how up to date and robust the tools is. Some additional information explaining requirements for genericarm64 - currently for SystemReady IR certification it is required that at least two of the main Linux distros (Fedora, Debian, Ubuntu, OpenSuse) generic arm64 images are bootable and functional. We would like to expand this list with Yocto and Openwrt as well. There is also a PR into Openwrt which adds a generic armsr target with the same defconfig approach to build the kernel. Cheers, Anton
On Wed, 2024-02-21 at 08:15 -0800, Anton Antonov wrote: > On Wed, Feb 21, 2024 at 03:21 AM, Richard Purdie wrote: > > I think it comes down to whether the fragments are usable and > > testable. > > We have a list of targets we want this new machine to run on so > > lets > > start with those, define genericarm64 as that set of fragments > > combined > > plus the generic pieces linux-yocto adds, then go from there. If > > you > > add a new machine to the test matrix, we add a new fragment. If > > someone > > wants to add new config, they need to show a machine using it. > > Although Ross mentioned that there are not a lot of SystemReady IR > compatible hardware in the wild, we're already talking about tens of > them in existence. With this approach the genericarm64 machine will > be compatible with only some of them unless we test all of the > certified platforms and update kernel fragments accordingly. > The whole idea of SystemReady+defconfig is that it would allow to > avoid future maintenance of kernel fragments in Yocto for existing > and new SR certified platforms. If a platform is SystemReady > certified (i.e. required drivers are up-streamed and mainline > defconfig is updated) then the genericarm64 Yocto image would "just > work". On the last Yocto summit Bruce mentioned a tool which can > automate defconfig -> kernel fragments conversion. Using this tool as > a part of kernel versions updates in Yocto might solve the problem > for genericarm64. But, I don't know how up to date and robust the > tools is. > > Some additional information explaining requirements for genericarm64 > - currently for SystemReady IR certification it is required that at > least two of the main Linux distros (Fedora, Debian, Ubuntu, > OpenSuse) generic arm64 images are bootable and functional. We would > like to expand this list with Yocto and Openwrt as well. There is > also a PR into Openwrt which adds a generic armsr target with the > same defconfig approach to build the kernel. I think the problem here is going to be defining which kinds of configuration should come from where. Let me pick for example, ZFS as a random kernel config option. I could pick a USB Alcatel Speedtouch modem instead, the point is something which doesn't really have hardware implications (but could have distro ones). I have no idea whether the "systemready defconfig" enables zfs or or not. From a Yocto Project perspective that option is very much a "distro" piece of configuration and not related to the "machine" or hardware. By using fragments, we can clearly keep something like that separate and off limits. I don't know what policy this defconfig has to have things enabled or disabled but if the policy is "supports anything and everything", zfs and likely a lot of other things are probably enabled that we wouldn't usually want in Yocto Project builds. This is where the full defconfig becomes tricky since you get the bits needed for the Systemready spec, but you potentially get all kinds of other pieces too. You end turning on everything just in case. Is there some policy which says whether zfs should or should not be enabled in that defconfig? There has to be some set of config options that systemready requires and some that it doesn't care about and the real issue here is wanting to know which are which. Cheers, Richard
From: Paul Gortmaker <paulg@kernel.org> [[RFC PATCH] Add genericarm64 MACHINE using upstream defconfig] On 21/02/2024 (Wed 10:57) 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? 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 > >
On 2/21/24 9:06 AM, Paul Barker wrote: > On 21/02/2024 10:57, Ross Burton 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. > > I am in favour of this - I think the "genericarm64" machine should use > the in-tree defconfig so that it can support the widest array of > hardware. If someone wants to trim down the kernel for a particular > platform then they should probably create a specific MACHINE anyway. > > If we take the other approach of building up the kernel config from > fragments, how would we know that all SystemReady IR capable systems > will be supported? Yocto Project doesn't have the resources to test > every platform. I disagree here. I think it would be MUCH better to have a 'SystemReady IR' hardware configuration. So if SystemReady IR is desired, it is something that anyone can enable (starting with genericarm64). Remember the defconfig is going to have more then hardware configs in it. Will it have the right systemd configurations? Will is have the magic filesystem a random user wants? Will avoid having some other filesystem type that another user doesn't want? Building up the kernel, and considering SystemReady IR as a 'hardware feature', and then add in the additional things that are needed for whatever reason is a much more reasonable way to do this and make it useful to otthers. > For the Renesas RZ SoCs I work on these days, the in-tree defconfig is > the configuration we test with the mainline kernel. AMD does the same thing, for the kernel development it makes sense. Kernel is built and tested standalone from userspace. But with that said, I think it's the wrong way to do Yocto Project development. Yocto Project development needs further control and the separation of hardware and software configurations is pretty essential to having a system that can be customized appropriately. The defconfig can be used as a guide to the other configurations, but separating hardware and software configs is a necessary first step in my opinion. --Mark > Thanks, > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#13264): https://lists.yoctoproject.org/g/poky/message/13264 > Mute This Topic: https://lists.yoctoproject.org/mt/104489783/3616948 > Group Owner: poky+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/poky/unsub [mark.hatle@kernel.crashing.org] > -=-=-=-=-=-=-=-=-=-=-=- >
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"
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