Re: Novena update; armhf flavor for i.MX6
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
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
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
Re: Novena update; armhf flavor for i.MX6
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
On Thu, 2013-02-07 at 23:03 +0100, Arnaud Patard wrote: Ian Campbell i...@hellion.org.uk 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
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
Ian Campbell i...@hellion.org.uk 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
