[OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2
denis at denix.org
Fri Jan 24 22:59:45 UTC 2020
On Fri, Jan 24, 2020 at 09:05:09AM -0800, Khem Raj wrote:
> On 1/24/20 3:42 AM, Ross Burton wrote:
> >On 23/01/2020 22:43, Denys Dmytriyenko wrote:
> >>>Such as all the various cortex etc CPU tuning files?
> >>LOL! :) Of course, since ARM is such an inferior arch to x86.
> >>Otherwise we
> >>should move everything that is not needed by qemux86 to
> >>meta-intel... JK :)
> >I almost pre-empted this comment in my reply because I knew it was
> >coming. :)
> >Personally, not a terrible idea. The slight difference is that
> >meta-intel is *Intel's* BSP and we don't share stuff like
> >firmware/drivers with AMD.
> it will be good to find what the overlap will be, is it something
> that BSPs can use with minimum changes, or are we providing a
> template that will be copied over and housed in form of bbappends or
> bbs. I am not familiar enough to assess that.
It depends how much of a specific platform support was already upstreamed
to ATF. For example, full TI platform support requires a more recent version
that 2.2 release (plus some "linkage" to OPTEE). And based on meta-rockchip
submission from Joshua, RK3399 requires a secondary Cortex-M toolchain to
build some parts. So, it seems like it would require some bbappends in BSPs.
> Perhaps it would be good to limit this to arm compatible machines,
> secondly, there is a point in having it in OE-Core if meta-arm is
> limiting itself to arm provided BSPs alone. I think it will be good
> to have a platform supported in core to be able to test it, between
> qemu and beaglebone, I guess it is not used. Or pehaps it is and we
> do not use it, so that change would be good to have as well.
Well, beaglebone is arm32. From the Yocto Project perspective, we don't
have an arm64 reference platform (membership questions, etc.), which would
More information about the Openembedded-core