[1/2] arm/boot-wrapper-aarch64: remove recipe

fvp-baser was the only user of this recipe.  Since that has been
removed, remove this as well.

Signed-off-by: Jon Mason <jon.mason@arm.com>
---
 .../boot-wrapper-aarch64_git.bb               | 95 -------------------
 scripts/machine-summary.py                    |  1 -
 2 files changed, 96 deletions(-)
 delete mode 100644 meta-arm/recipes-bsp/boot-wrapper-aarch64/boot-wrapper-aarch64_git.bb

On Wed, Oct 11, 2023 at 08:02:02AM -0500, Jon Mason wrote:
> fvp-baser was the only user of this recipe.  Since that has been
> removed, remove this as well.

Is *common* meta-arm layer now being relegated to only serve ARM's own BSP?

I don't know what fvp-baser is or was, but I do know that boot-wrapper-aarch64 
is commonly used by other BSPs for early stages of new platform development 
and board bringup, and/or custom bootflows.

Removing this crucial common component sends the wrong message...


> Signed-off-by: Jon Mason <jon.mason@arm.com>
> ---
>  .../boot-wrapper-aarch64_git.bb               | 95 -------------------
>  scripts/machine-summary.py                    |  1 -
>  2 files changed, 96 deletions(-)
>  delete mode 100644 meta-arm/recipes-bsp/boot-wrapper-aarch64/boot-wrapper-aarch64_git.bb
> 
> diff --git a/meta-arm/recipes-bsp/boot-wrapper-aarch64/boot-wrapper-aarch64_git.bb b/meta-arm/recipes-bsp/boot-wrapper-aarch64/boot-wrapper-aarch64_git.bb
> deleted file mode 100644
> index 775f4064..00000000
> --- a/meta-arm/recipes-bsp/boot-wrapper-aarch64/boot-wrapper-aarch64_git.bb
> +++ /dev/null
> @@ -1,95 +0,0 @@
> -SUMMARY = "Linux aarch64 boot wrapper with FDT support"
> -LICENSE = "BSD-3-Clause"
> -
> -LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=bb63326febfb5fb909226c8e7ebcef5c"
> -
> -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mark/boot-wrapper-aarch64.git;branch=master"
> -SRCREV = "d3b1a15d18542b2086e72bfdc3fc43f454772a3b"
> -
> -# boot-wrapper doesn't make releases
> -UPSTREAM_CHECK_COMMITS = "1"
> -
> -PV = "0+git"
> -
> -S = "${WORKDIR}/git"
> -
> -inherit autotools deploy
> -
> -PACKAGE_ARCH = "${MACHINE_ARCH}"
> -
> -COMPATIBLE_MACHINE ?= "invalid"
> -
> -# Device tree to put in the image
> -# by default use the standard kernel devicetree
> -# This should be overwritten if the devicetree is not generated
> -# by the kernel.
> -# This should point to a file in the deploy image directory
> -BOOT_WRAPPER_AARCH64_DEVICETREE ??= "${KERNEL_DEVICETREE}"
> -
> -# Kernel image to put in the image
> -# This should point to a file in the deploy image directory
> -BOOT_WRAPPER_AARCH64_KERNEL ??= "Image"
> -
> -# Kernel command line for the image
> -BOOT_WRAPPER_AARCH64_CMDLINE ??= "rw"
> -
> -# Image generated by boot wrapper
> -BOOT_WRAPPER_AARCH64_IMAGE ??= "linux-system.axf"
> -
> -DEPENDS += "virtual/kernel dtc-native"
> -
> -EXTRA_OECONF += "--with-kernel-dir=${WORKDIR}/kernel"
> -EXTRA_OECONF += "--with-dtb=${WORKDIR}/kernel/dummy.dtb"
> -EXTRA_OECONF += "--with-cmdline=\"\""
> -EXTRA_OECONF += "--enable-psci --enable-gicv3"
> -
> -# unset LDFLAGS solves this error when compiling kernel modules:
> -# aarch64-poky-linux-ld: unrecognized option '-Wl,-O1'
> -EXTRA_OEMAKE += "'LDFLAGS= --gc-sections '"
> -
> -# Strip prefix if any
> -REAL_DTB = "${@os.path.basename(d.getVar('BOOT_WRAPPER_AARCH64_DEVICETREE'))}"
> -
> -EXTRA_OEMAKE += "'KERNEL_DTB=${DEPLOY_DIR_IMAGE}/${REAL_DTB}'"
> -EXTRA_OEMAKE += "'KERNEL_IMAGE=${DEPLOY_DIR_IMAGE}/${BOOT_WRAPPER_AARCH64_KERNEL}'"
> -EXTRA_OEMAKE += "'CMDLINE=${BOOT_WRAPPER_AARCH64_CMDLINE}'"
> -
> -
> -do_configure:prepend() {
> -    # Create dummy files to make configure happy.
> -    # We will pass the generated ones directly to make.
> -    mkdir -p ${WORKDIR}/kernel/arch/arm64/boot
> -    echo "dummy" > ${WORKDIR}/kernel/arch/arm64/boot/Image
> -    echo "dummy" > ${WORKDIR}/kernel/dummy.dtb
> -
> -    # Generate configure
> -    (cd ${S} && autoreconf -i || exit 1)
> -}
> -
> -do_compile[noexec] = "1"
> -do_install[noexec] = "1"
> -
> -# We need the kernel to create an image
> -do_deploy[depends] += "virtual/kernel:do_deploy"
> -
> -do_deploy() {
> -    if [ ! -f ${DEPLOY_DIR_IMAGE}/${REAL_DTB} ]; then
> -        echo "ERROR: cannot find ${REAL_DTB} in ${DEPLOY_DIR_IMAGE}" >&2
> -        echo "Please check your BOOT_WRAPPER_AARCH64_DEVICETREE settings" >&2
> -        exit 1
> -    fi
> -
> -    if [ ! -f ${DEPLOY_DIR_IMAGE}/${BOOT_WRAPPER_AARCH64_KERNEL} ]; then
> -        echo "ERROR: cannot find ${BOOT_WRAPPER_AARCH64_KERNEL}" \
> -            " in ${DEPLOY_DIR_IMAGE}" >&2
> -        echo "Please check your BOOT_WRAPPER_AARCH64_KERNEL settings" >&2
> -        exit 1
> -    fi
> -
> -    oe_runmake clean
> -    oe_runmake all
> -
> -    install -D -p -m 644 ${BOOT_WRAPPER_AARCH64_IMAGE} \
> -        ${DEPLOYDIR}/linux-system.axf
> -}
> -addtask deploy before do_build after do_compile
> diff --git a/scripts/machine-summary.py b/scripts/machine-summary.py
> index 0f5d1d99..3038237c 100755
> --- a/scripts/machine-summary.py
> +++ b/scripts/machine-summary.py
> @@ -146,7 +146,6 @@ recipes = ("virtual/kernel",
>             "u-boot",
>             "optee-os",
>             "hafnium",
> -           "boot-wrapper-aarch64",
>             "gator-daemon",
>             "opencsd",
>             "gcc-aarch64-none-elf-native",
> -- 
> 2.30.2

On 11 Oct 2023, at 18:08, Denys Dmytriyenko via lists.yoctoproject.org <denis=denix.org@lists.yoctoproject.org> wrote:
> 
> On Wed, Oct 11, 2023 at 08:02:02AM -0500, Jon Mason wrote:
>> fvp-baser was the only user of this recipe.  Since that has been
>> removed, remove this as well.
> 
> Is *common* meta-arm layer now being relegated to only serve ARM's own BSP?
> 
> I don't know what fvp-baser is or was, but I do know that boot-wrapper-aarch64 
> is commonly used by other BSPs for early stages of new platform development 
> and board bringup, and/or custom bootflows.
> 
> Removing this crucial common component sends the wrong message…

It’s aim is to be a common source of recipes, certainly.

Can you point us at a BSP layer that uses this recipe?

Ross

On Wed, Oct 11, 2023 at 05:28:29PM +0000, Ross Burton wrote:
> On 11 Oct 2023, at 18:08, Denys Dmytriyenko via lists.yoctoproject.org <denis=denix.org@lists.yoctoproject.org> wrote:
> > 
> > On Wed, Oct 11, 2023 at 08:02:02AM -0500, Jon Mason wrote:
> >> fvp-baser was the only user of this recipe.  Since that has been
> >> removed, remove this as well.
> > 
> > Is *common* meta-arm layer now being relegated to only serve ARM's own BSP?
> > 
> > I don't know what fvp-baser is or was, but I do know that boot-wrapper-aarch64 
> > is commonly used by other BSPs for early stages of new platform development 
> > and board bringup, and/or custom bootflows.
> > 
> > Removing this crucial common component sends the wrong message…
> 
> It’s aim is to be a common source of recipes, certainly.
> 
> Can you point us at a BSP layer that uses this recipe?

Unfortunately, early stages of new platform development and board bringup 
activities aren't done in the open and are not public. By the time a new 
platform is made public, it usually has all the other pieces of the boot 
chain integrated - U-boot/EFI, TF-A, OPTEE, etc.

Back when I was still with TI we used boot-wrapper-aarch64 to bring up the 
new K3 family of processors and the first 2 platforms - AM65x (A53) and 
J721e (A72). Though it was before meta-arm was established, so I maintained 
own version of the recipe inside internal-only layers.

A similar situation was with TF-A and OPTEE where BSPs would have own recipes 
for those components back then. But the only difference is that those would 
eventually have to become public, and hence we all worked hard to unify those 
recipes under meta-arm around early 2020. I'd argue same applies to this 
boot-wrapper-aarch64 recipe, although it's less visible.

I know it's been added to meta-arm as part of Gem5 and you never heard of 
anyone else using it, but it is still useful and having a common recipe for 
it is quite beneficial and probably worth a bit extra maintenance burden...

On Wed, Oct 11, 2023 at 02:36:05PM -0400, Denys Dmytriyenko wrote:
> On Wed, Oct 11, 2023 at 05:28:29PM +0000, Ross Burton wrote:
> > On 11 Oct 2023, at 18:08, Denys Dmytriyenko via lists.yoctoproject.org <denis=denix.org@lists.yoctoproject.org> wrote:
> > > 
> > > On Wed, Oct 11, 2023 at 08:02:02AM -0500, Jon Mason wrote:
> > >> fvp-baser was the only user of this recipe.  Since that has been
> > >> removed, remove this as well.
> > > 
> > > Is *common* meta-arm layer now being relegated to only serve ARM's own BSP?
> > > 
> > > I don't know what fvp-baser is or was, but I do know that boot-wrapper-aarch64 
> > > is commonly used by other BSPs for early stages of new platform development 
> > > and board bringup, and/or custom bootflows.
> > > 
> > > Removing this crucial common component sends the wrong message…
> > 
> > It’s aim is to be a common source of recipes, certainly.
> > 
> > Can you point us at a BSP layer that uses this recipe?
> 
> Unfortunately, early stages of new platform development and board bringup 
> activities aren't done in the open and are not public. By the time a new 
> platform is made public, it usually has all the other pieces of the boot 
> chain integrated - U-boot/EFI, TF-A, OPTEE, etc.
> 
> Back when I was still with TI we used boot-wrapper-aarch64 to bring up the 
> new K3 family of processors and the first 2 platforms - AM65x (A53) and 
> J721e (A72). Though it was before meta-arm was established, so I maintained 
> own version of the recipe inside internal-only layers.
> 
> A similar situation was with TF-A and OPTEE where BSPs would have own recipes 
> for those components back then. But the only difference is that those would 
> eventually have to become public, and hence we all worked hard to unify those 
> recipes under meta-arm around early 2020. I'd argue same applies to this 
> boot-wrapper-aarch64 recipe, although it's less visible.
> 
> I know it's been added to meta-arm as part of Gem5 and you never heard of 
> anyone else using it, but it is still useful and having a common recipe for 
> it is quite beneficial and probably worth a bit extra maintenance burden...

I/we didn't know of any current users besides fvp-baser, which was
recently removed.  Per your comment, it is (potentially) in use by
many other layers.  So, I think it best we keep it in.

That being said, it would be nice to point to something that is using
it.  This way we know if changes to it break them.  Specifically, when
we update it.  Some time ago, I had a change queued to update it to
the newest version, but I dropped it when I was told internally that
the only known user was going to be removed.  So, I'll resurrect this
change.

Thanks,
Jon

> 
> -- 
> Denys
>