[Openembedded-architecture] RFC: Non-Linux BSPs and/or non-standard architectures

[Richard Purdie]

On Thu, 2017-05-11 at 17:18 -0400, Denys Dmytriyenko wrote:
> Somewhat related to the other Yocto Project Compliance 2.0
> discussion, I have a question about supporting non-Linux BSPs or BSPs
> with both Linux and non-Linux targets. I've noticed there's some
> support for "baremetal" builds. What about non-standard
> architectures? Will that affect Compliance factors in 
> any way?

Right now, the compliance discussion is around Linux. I don't see the
discussion being materially different for baremetal/RTOS type
scenarios. If you include a layer, it shouldn't activate without the
relevant distro/machine config. That would actually make it usable for
multiconfig scenarios for example so is generally desirable.

> Just to provide some specific examples - I'm trying to determine
> feasibility and validity of adding meta-ti support for RTOS OS on TI
> existing platforms, as well as adding C6x-architecture DSP-based
> platforms to meta-ti that can only do RTOS. Unfortunately, support
> for C6x architecture is not proper, as from OE perspective it's not a
> new architecture, but instead just a hacked up ARM one, that uses own
> toolchain, kernel and so on. Yes, it's not clean, but it is what it
> is at this point... I don't expect these new platforms to affect 
> regular Linux builds or conflict with other BSPs. But still, wanted
> to run it by the community for any comments. Thanks.

I added pieces to OE-Core which allow other layers to extend the core
to other architectures without needing to patch OE-Core itself. If
there are places where something can't be done I'd be open to ideas on
allowing ways to extend it from other layers.

With systems with multiple cores of differing sizes and architectures
and so on, I see composite systems being important to support going
forward and non-Linux is an element of that. Its likely we don't want
that in OE-Core but I'm happy to see layers adding various
capabilities. Multiconfig allows support of this as one of its
objectives. 

Does that help answer the question?

Cheers,

Richard