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

[Denys Dmytriyenko <denis@denix.org>]

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...

-- 
Denys