[meta-freescale] [PATCH] mx6q-ba16: Add initial board support

Justin Waters justin.waters at timesys.com
Thu Aug 27 10:06:18 PDT 2015


On Thu, Aug 27, 2015 at 12:56 PM, Otavio Salvador <
otavio.salvador at ossystems.com.br> wrote:

> On Thu, Aug 27, 2015 at 1:32 PM, Justin Waters
> <justin.waters at timesys.com> wrote:
> > On Thu, Aug 27, 2015 at 11:37 AM, Otavio Salvador
> > <otavio.salvador at ossystems.com.br> wrote:
> >> On Thu, Aug 27, 2015 at 11:45 AM, Justin Waters
> >> <justin.waters at timesys.com> wrote:
> >> > We have been working with a vanilla (4.0+) kernel on some related
> >> > platforms,
> >> > and are considering moving the BA16 platform to this as well. Is there
> >> > an
> >> > effort to move some of the mainline work, such as etna-viv and related
> >> > packages, into the meta-freescale layer? Would it be acceptable to
> push
> >> > a
> >> > 4.0 kernel even if those packages are not supported?
> >>
> >> We have intending to do this for quite some time but we are lacking
> >> the resources to do so.
> >
> >
> > I do have some patches against meta-fsl-arm-extra to add support for
> > etna-viv. I can clean those up a bit and send them out, although they
> need a
> > lot of work to play nicely with the proprietary packages.
> This is great and very welcome. Those should go for meta-fsl-arm
> though and to be enabled somehow.
> If you can please prepare the patches and send them for initial
> review. We need to make them to play nicely but I am keen to help in
> finding possible ways to do so. Your initial patches would help for
> sure.

I will clean them up and rebase them sometime in the next week or so (they
are still back on dizzy).

> >> However I want to know what level of compromise Timesys will have in
> >> maintaining the board and any proposed new components as we have been
> >> having a hard time to get the Vybrid boards updated[3][4][5] (both
> >> maintained by Timesys) since long time ago even though
> >> Toradex[6][7][8] has did all the hard work of updating it for 4.0
> >> kernel. I do hope to get this solved and discussed this with Andy at
> >> FTF but no move has been done so far.
> >
> > Andy had mentioned that conversation. We are currently working on a plan
> for
> > Vybrid. Once the higher-ups come to an agreement, we'll get that
> implemented
> > and moving forward. I'll keep you posted on any updates. Is there
> anything
> > in particular that is blocking development on your side? If so, I can
> > prioritize that internally.
> Great news but I want to make clear that October is next and our code
> freeze as well so better to have this soon. Seriously, most work is
> done by Toradex so it is a couple of days of work to get the
> integrated boards using it.

There are a few considerations at play here, but I'll keep that in mind.
When exactly is the code freeze so that I can light some fires on my end? I
think the big issue is around MCC, but I'll have to double check that.

> >> So all Timesys help and contributions are welcome but we do need to
> >> have a high level of commitment from you guys if more high impact
> >> changes are going to be proposed.
> >
> > Understood. I'm working with Advantech to get those details ironed out,
> but
> > I needed to make sure this approach was viable. It sounds like it is.
> It is. For them, I believe the 3.14 fork is be very attractive for
> them as it offer all features of the SoC. A 4.1 fork is very appealing
> and something which would help a lot, if done in a polished way,
> however it requires a lot of more work to get done.

The end customer for these boards is actually more interested in the 4.x
work than the feature-completeness of 3.14. We've actually spent a lot of
time working with the 4.0 kernel, and it's surprisingly capable.

Justin Waters
Director of Engineering
Timesys Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20150827/ec32a579/attachment.html>

More information about the meta-freescale mailing list