On Mon, 2013-02-04 at 00:29 +0000, 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
