[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Novena update; armhf flavor for i.MX6



On Sun, 2013-02-10 at 19:58 +0000, Ben Hutchings wrote:
> On Fri, 2013-02-08 at 09:46 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-07 at 23:03 +0100, Arnaud Patard wrote:
> [...]
> > > >
> > > >> It sounds like there has been talk of a unified i.mx5 and i.mx6 armhf 
> > > >> debian kernel flavor (something like '-mx'),
> > > >
> > > > I wonder if we have now reached the point with all the upstream single
> > > > image work where we could have a single flavour for armhf? i.e. a single
> > > > generic flavour not -mx (or maybe two, regular and lpae).
> > > 
> > > There's still some work needed. Some devices (imx5/omap) have not yet been
> > > converted into DT.
> > 
> > So it sounds like we should have a new generic DT flavour, containing
> > imx6 support (and any other platforms which are ready), and leave the
> > existing imx5/omap flavours alone, as opposed to adding imx6 to the imx5
> > flavour and renaming it to -imx.
> 
> I'm not entirely clear on what's happening with MX5, but it looks like
> all the machines the wheezy mx5 flavour supports are now DT-only
> upstream (as of 3.7).  Can anyone confirm whether the
> linux-image-3.7-trunk-mx5 package in experimental actually works on one
> of these machines?  (Also, I noticed that some i.MX6q DTB files have
> been included in it - I wonder how that happens?)

You mean how the DTB files ended up in the package? We do:
        shopt -s nullglob ; for i in $(DIR)/arch/arm/boot/*.dtb ; do \
                install -D -m644 $$i '$(PACKAGE_DIR)'/'$(DTB_INSTALL_DIR)'/$$(basename $$i) ; \
        done
so we'll automatically pick up anything which upstream adds to its
build, which is itself keyed off of Kconfig options for the platforms,
but not the specific boards. Perhaps that isn't desirable?

> 
> > Over time most new stuff should be added to the generic flavour and
> > things can migrate from the others as they become ready.
> > 
> > > > Even if we can't do that right now I'd have thought it ought to be
> > > > doable by the time we freeze for jessie.
> > > >
> > > 
> > > I think that having a omap/mvebu/imx/... multiplatform kernel for jessie
> > > is possible but clearly not for wheezy.
> > 
> > Agreed, I assume the Wheezy flavours are pretty much fixed by this stage
> > in the freeze?
> 
> I think that in principle we could *add* a flavour, but we can't
> reasonably merge or rename the existing flavours at this stage.

That sounds reasonable.

> > I'm not sure if Bryan is interested in Wheezy anyhow, since it is 3.2
> > kernel I would imagine a fair bit of backporting would be needed, it's a
> > bit of a different conversation to this one I think, we'd need to start
> > by someone identifying the list of changes which would need backporting.
> [...]
> 
> I assume Brian is hoping to use wheezy userland plus a wheezy-backports
> kernel.

So does this.

Ian.

-- 
Ian Campbell

Garbage In -- Gospel Out.


Reply to: