meta-bsp

meta-bsp

[Trevor Woerner]

Hi,

I'm tempted to reply to RP's "2.6 planning proposals and meeting" email thread
to ask if there could be some support added for common BSP things, but I have
a feeling it probably won't go down well. Also, I've been trying to get some
traction on https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881 for a
while (i.e. since last August), but no dice.

Basically, I believe there are a small number of basic, general things that
many BSP layers could use (or need) and it'd be nice to see them available in
one place so everyone could use them, instead of having everyone create their
own, or copy+paste (I'm not sure which of those is worse).

Bug 11881 is an example of one such thing, but others exist.

Many embedded boards will come with repositories somewhere of that board's
vendor kernel and vendor bootloader. Many BSP layers have recipes to make
building with these repositories easier. However, we're seeing more and more
boards getting upstream {kernel|u-boot} support. This means users are
increasingly having a choice between using the vendor's repositories or
upstream. But often the choice of bootloader, kernel, and graphics are tied
together; if you want one, it means using or not using the others in specific
combinations. Therefore it's not simply a matter of providing two kernel
recipes and letting the user PREFERRED_PROVIDER_virtual/kernel one or the
other. So bug 11881 points to a class (written by Otavio) that allows a BSP to
offer different sets that the user then selects (either by doing nothing and
selecting the default, or setting a one-liner in a configuration to choose the
other).

Another example of something that might be useful to various BSP
layers is a common recipe for the upstream linux kernel itself
(git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git). Many BSP
layers provide a vendor recipe and an upstream recipe, but I believe it would
be better if the upstream recipe were common instead of requiring every BSP
layer to keep theirs current. Maybe the same is true for linux-next or
linux-stable?

Also some common mali (or perhaps the upcoming lima) recipes might be nice?

Since it seems unlikely I'll be able to convince openembedded-core to add
these things, maybe meta-openembedded would be a better home?

Best regards,
	Trevor

Re: meta-bsp

[Bruce Ashfield]

On Tue, Apr 24, 2018 at 10:30 PM, Trevor Woerner <twoerner@gmail.com> wrote:

> Hi,
>
> I'm tempted to reply to RP's "2.6 planning proposals and meeting" email
> thread
> to ask if there could be some support added for common BSP things, but I
> have
> a feeling it probably won't go down well. Also, I've been trying to get
> some
> traction on https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881 for a
> while (i.e. since last August), but no dice.
>
> Basically, I believe there are a small number of basic, general things that
> many BSP layers could use (or need) and it'd be nice to see them available
> in
> one place so everyone could use them, instead of having everyone create
> their
> own, or copy+paste (I'm not sure which of those is worse).
>
> Bug 11881 is an example of one such thing, but others exist.
>
> Many embedded boards will come with repositories somewhere of that board's
> vendor kernel and vendor bootloader. Many BSP layers have recipes to make
> building with these repositories easier. However, we're seeing more and
> more
> boards getting upstream {kernel|u-boot} support. This means users are
> increasingly having a choice between using the vendor's repositories or
> upstream. But often the choice of bootloader, kernel, and graphics are tied
> together; if you want one, it means using or not using the others in
> specific
> combinations. Therefore it's not simply a matter of providing two kernel
> recipes and letting the user PREFERRED_PROVIDER_virtual/kernel one or the
> other. So bug 11881 points to a class (written by Otavio) that allows a
> BSP to
> offer different sets that the user then selects (either by doing nothing
> and
> selecting the default, or setting a one-liner in a configuration to choose
> the
> other).
>
> Another example of something that might be useful to various BSP
> layers is a common recipe for the upstream linux kernel itself
> (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git). Many
> BSP
> layers provide a vendor recipe and an upstream recipe, but I believe it
> would
> be better if the upstream recipe were common instead of requiring every BSP
> layer to keep theirs current. Maybe the same is true for linux-next or
> linux-stable?
>

FWIW, I already have kernel recipes that I maintain that do this, and
"linux-yocto" is
now a single repository (versus one per version).  The korg recipes aren't
enangled
with anything extra (and can use fragments, once I re-submit my changes for
2.6
to move things into kernel.bbclass), so I could take something like that on
as part
of my existing workflow and try to get them into oe-core.

That being said, the reason that the upstream recipes vary so much is that
although
the repo is common, that is pretty much the only thing that is common.
There's no
agreement on versions, SRCREVs, etc, so it is nearly impossible to make the
recipe
actually useful, unless it is tied to a BSP.  You are saving a few lines of
a simple
recipe, that that is about it.

Cheers,

Bruce


>
> Also some common mali (or perhaps the upcoming lima) recipes might be nice?
>
> Since it seems unlikely I'll be able to convince openembedded-core to add
> these things, maybe meta-openembedded would be a better home?
>
> Best regards,
>         Trevor
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"