Novena update; armhf flavor for i.MX6

2013-02-03 Thread bnewbold


Hello again debian-kernel!

I wrote to this list in December[0] regarding the Novena open hardware 
laptop project[1]; there is now a Debian porting wiki page here:


  http://www.kosagi.com/w/index.php?title=Novena/Debian

I met Ben H and bunnie in late December, and then had access to a 
development board again a week ago. I was able to build and boot an SD 
card image using a mainline linux kernel (clean ~3.8 kernel.org checkout 
with custom defconfig), a custom u-boot, and wheezy armhf rootfs 
(instructions at [2]). The Novena boards are in very short supply, and I 
don't have one in my hands at this time, but a couple second rev boards 
might be available in the coming months.


Currently mainline does not include working support for SATA, the PCI-e 
port, HDMI, and several other peripherals, but the Novena team is working 
towards getting support for those (perhaps older Freescale BSP or Linaro 
code) merged into mainline. Ethernet has a couple bugs but mostly works.


As far as I know, basic framebuffer graphics over HDMI and the LVDS ports 
should be feasible under DFSG, but non-proprietary accelerated GPU support 
would be new work and need to come from the community or a third party.


It sounds like there has been talk of a unified i.mx5 and i.mx6 armhf 
debian kernel flavor (something like '-mx'), which would be the place for 
us to submit kernel defconfig tweaks to, and potentially device tree files 
before they are accepted upstream (is there policy for that?).


I have no idea what would be involved in creating or maintaining a new 
flavor[3]. How can I help? Is a proposal required?


FWIW, the only other devices using i.MX6 chips so far that I know of (and 
might make use of this flavor) are the Sabre Lite and Nitrogen6x 
development boards, the Wandboard development board (using single and 
dual-core chips, not quad-core), the Zealz GK802 Android "TV stick", and 
the Ampe A10 table (confusingly named, not using the A10 ARM chip).


--bryan

[0] https://lists.debian.org/debian-kernel/2012/12/msg00349.html
[1] http://www.kosagi.com/w/index.php?title=Novena_Main_Page
[2] http://www.kosagi.com/w/index.php?title=Novena/DebianBuildProcess
[3] It seems like it could be a real spiritual quest! A thrilling journey
into the dark heart of maintenance, mucking with the overlapping
build internals of two huge software communities, with all commits
almost certain to be cursed in posterity!


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1302032343260.14...@adelie.robocracy.org



Re: Novena update; armhf flavor for i.MX6

2013-02-07 Thread Ian Campbell
On Mon, 2013-02-04 at 00:29 +, bnewb...@robocracy.org wrote:
> Hello again debian-kernel!
> 
> I wrote to this list in December[0] regarding the Novena open hardware 
> laptop project[1]; there is now a Debian porting wiki page here:
> 
>http://www.kosagi.com/w/index.php?title=Novena/Debian
> 
> I met Ben H and bunnie in late December, and then had access to a 
> development board again a week ago. I was able to build and boot an SD 
> card image using a mainline linux kernel (clean ~3.8 kernel.org checkout 
> with custom defconfig), a custom u-boot, and wheezy armhf rootfs 
> (instructions at [2]).

I don't see any mention of Novena in the mainline git logs. I also took
a look in some of the likely looking arm-soc branches. Perhaps I'm just
looking for the wrong keywords? Or maybe with all the DT stuff no Novena
specific patches were required?

> 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).

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.

>  which would be the place for 
> us to submit kernel defconfig tweaks to, and potentially device tree files 
> before they are accepted upstream (is there policy for that?).

debian-kernel@ is the place.

defconfigs are in debian/config, you should patch the one for the
flavour concerned.

For general patches backported from upstream (or at the least a relevant
arch maintainer's tree targeting the next merge window) are preferred.

I don't know about Device Tree patches -- I suppose there isn't much
reason to deviate from the upstream first policy. Getting a device tree
for stuff where the code is already upstream into mainline ought to be
pretty easy.

If there are patches which aren't in mainline yet then I would
prioritise getting those into mainline above getting them into Debian's
kernels.

> I have no idea what would be involved in creating or maintaining a new 
> flavor[3]. How can I help? Is a proposal required?

Patches! :-)

As I say above we may not need a new flavour at all, but if you did
you'd be looking first at modifying debian/config/armf/defines and
debian/config/armhf/config.flavour. Other potentially interesting places
would be debian/installer/armhf.

Ian.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1360268337.22622.29.ca...@hastur.hellion.org.uk



Re: Novena update; armhf flavor for i.MX6

2013-02-07 Thread Rtp
Ian Campbell  writes:

> On Mon, 2013-02-04 at 00:29 +, bnewb...@robocracy.org wrote:
>> Hello again debian-kernel!
>> 
>> I wrote to this list in December[0] regarding the Novena open hardware 
>> laptop project[1]; there is now a Debian porting wiki page here:
>> 
>>http://www.kosagi.com/w/index.php?title=Novena/Debian
>> 
>> I met Ben H and bunnie in late December, and then had access to a 
>> development board again a week ago. I was able to build and boot an SD 
>> card image using a mainline linux kernel (clean ~3.8 kernel.org checkout 
>> with custom defconfig), a custom u-boot, and wheezy armhf rootfs 
>> (instructions at [2]).
>
> I don't see any mention of Novena in the mainline git logs. I also took
> a look in some of the likely looking arm-soc branches. Perhaps I'm just
> looking for the wrong keywords? Or maybe with all the DT stuff no Novena
> specific patches were required?

imx6 is nowadays DT only. Fsl devs are testing only on DT so trying to
support imx6 on non-DT setup will likely leads to troubles. If one
looks at the imx6 related dts file in mainline, afaik there's only
sabrelite devices. So, this probably means that some work is needed to get
Novena hardware support in mainline.

>
>> 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.

>
> 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. I'm also not sure we'll be able to drop
non-DT armhf kernels soon. At least every new platform should be supported with 
DT.

>>  which would be the place for 
>> us to submit kernel defconfig tweaks to, and potentially device tree files 
>> before they are accepted upstream (is there policy for that?).
>
> debian-kernel@ is the place.
>
> defconfigs are in debian/config, you should patch the one for the
> flavour concerned.
>
> For general patches backported from upstream (or at the least a relevant
> arch maintainer's tree targeting the next merge window) are preferred.
>
> I don't know about Device Tree patches -- I suppose there isn't much
> reason to deviate from the upstream first policy. Getting a device tree
> for stuff where the code is already upstream into mainline ought to be
> pretty easy.
>
> If there are patches which aren't in mainline yet then I would
> prioritise getting those into mainline above getting them into Debian's
> kernels.
>

yes, the device should be supported in mainline first. IMX6 support may
be missing some parts so getting this support in mainline first should
be the main priority.

>> I have no idea what would be involved in creating or maintaining a new 
>> flavor[3]. How can I help? Is a proposal required?
>
> Patches! :-)
>
> As I say above we may not need a new flavour at all, but if you did
> you'd be looking first at modifying debian/config/armf/defines and
> debian/config/armhf/config.flavour. Other potentially interesting places
> would be debian/installer/armhf.

If we have a new flavour, it should be a multiplatform one imho. In the
case of IMX6, there's no real point to create a new flavor if it's not
to make a multiplatform kernel. It's already possible to build a kernel
with mx5 and mx6 support iirc.

Arnaud


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjzfok6w@lebrac.rtp-net.org



Re: Novena update; armhf flavor for i.MX6

2013-02-08 Thread Ian Campbell
On Thu, 2013-02-07 at 23:03 +0100, Arnaud Patard wrote:
> Ian Campbell  writes:
> 
> > On Mon, 2013-02-04 at 00:29 +, bnewb...@robocracy.org wrote:
> >> Hello again debian-kernel!
> >> 
> >> I wrote to this list in December[0] regarding the Novena open hardware 
> >> laptop project[1]; there is now a Debian porting wiki page here:
> >> 
> >>http://www.kosagi.com/w/index.php?title=Novena/Debian
> >> 
> >> I met Ben H and bunnie in late December, and then had access to a 
> >> development board again a week ago. I was able to build and boot an SD 
> >> card image using a mainline linux kernel (clean ~3.8 kernel.org checkout 
> >> with custom defconfig), a custom u-boot, and wheezy armhf rootfs 
> >> (instructions at [2]).
> >
> > I don't see any mention of Novena in the mainline git logs. I also took
> > a look in some of the likely looking arm-soc branches. Perhaps I'm just
> > looking for the wrong keywords? Or maybe with all the DT stuff no Novena
> > specific patches were required?
> 
> imx6 is nowadays DT only. Fsl devs are testing only on DT so trying to
> support imx6 on non-DT setup will likely leads to troubles. If one
> looks at the imx6 related dts file in mainline, afaik there's only
> sabrelite devices. So, this probably means that some work is needed to get
> Novena hardware support in mainline.

Bryan's instructions at [0] seem to suggest that mainline 3.8-rcFOO plus
a custom DTB are all that is required for basic functionality, although
he does say that some peripherals (e.g. SATA) aren't supported yet.

Getting the DTB which supports the current basic functionality into
upstream doesn't sound to hard and then it would seem reasonable to take
that DTB into Debian while the upstream work for the other peripherals
is on going.

[0] http://www.kosagi.com/w/index.php?title=Novena/DebianBuildProcess

> >
> >> 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.

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'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'm also not sure we'll be able to drop non-DT armhf kernels soon.

Those are just the imx5 and omap flavours?

> At least every new platform should be supported with DT.

Yes, that sounds reasonable.

> > As I say above we may not need a new flavour at all, but if you did
> > you'd be looking first at modifying debian/config/armf/defines and
> > debian/config/armhf/config.flavour. Other potentially interesting places
> > would be debian/installer/armhf.
> 
> If we have a new flavour, it should be a multiplatform one imho. In the
> case of IMX6, there's no real point to create a new flavor if it's not
> to make a multiplatform kernel. It's already possible to build a kernel
> with mx5 and mx6 support iirc.

Agreed.

Ian.
-- 
Ian Campbell
Current Noise: Rush - Finding  My Way

I'll see you... on the dark side of the moon...
-- Pink Floyd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1360316762.32479.133.ca...@zakaz.uk.xensource.com



Re: Novena update; armhf flavor for i.MX6

2013-02-10 Thread Ben Hutchings
On Fri, 2013-02-08 at 09:46 +, 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?)

> 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.

> 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.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part


Re: Novena update; armhf flavor for i.MX6

2013-02-11 Thread Ian Campbell
On Sun, 2013-02-10 at 19:58 +, Ben Hutchings wrote:
> On Fri, 2013-02-08 at 09:46 +, 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.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1360586878.20449.18.ca...@zakaz.uk.xensource.com



Re: Novena update; armhf flavor for i.MX6

2013-02-11 Thread Ben Hutchings
On Mon, 2013-02-11 at 12:47 +, Ian Campbell wrote:
> On Sun, 2013-02-10 at 19:58 +, Ben Hutchings wrote:
> > On Fri, 2013-02-08 at 09:46 +, 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,

I understood that.

> which is itself keyed off of Kconfig options for the platforms,
> but not the specific boards. Perhaps that isn't desirable?
[...]

I think this is the right thing to do (following the principle of Don't
Repeat Yourself).  I was just surprised that these were selected by a
configuration that doesn't mention IMX6.  Actually the rule is pretty
simple:

dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
imx53-qsb.dtb \
imx53-smd.dtb \
imx6q-arm2.dtb \
imx6q-sabrelite.dtb \
imx6q-sabresd.dtb

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


signature.asc
Description: This is a digitally signed message part


Re: Novena update; armhf flavor for i.MX6

2013-02-11 Thread Ian Campbell
On Mon, 2013-02-11 at 13:02 +, Ben Hutchings wrote:
> I think this is the right thing to do (following the principle of Don't
> Repeat Yourself).  I was just surprised that these were selected by a
> configuration that doesn't mention IMX6.  Actually the rule is pretty
> simple:
> 
> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
>   imx53-ard.dtb \
>   imx53-evk.dtb \
>   imx53-qsb.dtb \
>   imx53-smd.dtb \
>   imx6q-arm2.dtb \
>   imx6q-sabrelite.dtb \
>   imx6q-sabresd.dtb

Seems nasty of upstream to produce these without a dependency on the
config options actually needed to support the boards in question (e.g.
sabrelite seems to need config SOC_IMX6Q, which is a sub option of
ARCH_MXC support)

Ian.
-- 
Ian Campbell
Current Noise: Godflesh - Wound

I want you to organize my PASTRY trays ... my TEA-TINS are gleaming in
formation like a ROW of DRUM MAJORETTES -- please don't be FURIOUS with me --


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1360598651.20449.56.ca...@zakaz.uk.xensource.com