meta-bsp

[Trevor Woerner <twoerner@gmail.com>]

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