[meta-freescale] [meta-fsl-extra][PATCH 0/4] Add Nitrogen6QP_MAX support

[Gary Bisson]

Hi Otavio,

On Mon, Nov 16, 2015 at 4:25 PM, Otavio Salvador
<otavio.salvador at ossystems.com.br> wrote:
>
> On Mon, Nov 16, 2015 at 11:24 AM, Gary Bisson
> <gary.bisson at boundarydevices.com> wrote:
> > On Mon, Nov 16, 2015 at 12:55 PM, Otavio Salvador
> > <otavio.salvador at ossystems.com.br> wrote:
> >> Hello Gary,
> >>
> >> On Fri, Nov 13, 2015 at 11:35 AM, Gary Bisson
> >> <gary.bisson at boundarydevices.com> wrote:
> >>> This series adds the support for our Nitrogen6QP_MAX platform:
> >>> https://boundarydevices.com/product/nitrogen6_max-i-mx6-quad-plus-4gb-ddr3/
> >>>
> >>> A machine has been created for the time being since the 3.14.38-6qp-ga
> >>> release from Freescale has only been tested on 6QP platforms. Therefore
> >>> we decided to keep our other platforms (MX6QDL/SX) on the 3.14.28-1.0.0-ga
> >>> kernel already present.
> >>
> >> I won't include temporary machines into the BSP as this is disruptive
> >> for users.
> >
> > Ok I understand.
> >
> >> I think you can add the new kernel and u-boot recipes with
> >> DEFAULT_PREFERRENCE as -1 and document how to enable them for early
> >> adopters of QuadPlus allowing them to use it until the consolidate
> >> release is out.
> >
> > Yes here is what I'm planning to do for v2:
> > - modify 3.14.38 kernel recipe to target nitrogen6x only
> > - remove nitrogen6qp_max machine patch
> > - add a PREFERRED_VERSION_linux-boundary to 3.14.28 for nitrogen6x.conf
> >   - explaining in the commit log how to switch to 3.14.38-6qp when needed
> > - keep u-boot and u-boot-script bumps (removing machine compatible
> > changes though)
> >   - those bumps do not break compatibility with any other platform
> >
> > Let me know if you're ok with this approach.
>
> Mostly except that I wish you to mark the 3.14.38 recipe as
> DEFAULT_PREFERRENCE = -1 so people wishing to use it set the
> PREFERRED_VERSION on local.conf and we avoid touching the machine
> file.

Ok I didn't know about DEFAULT_PREFERENCE to be honest. Indeed it
makes sense to use it since it avoids modifying the machine conf. I'll
submit a v2 today.

Regards,
Gary