The long awaited first linux-linaro kernel package is available in the linaro-maintainers kernel ppa:
ppa:linaro-maintainers/kernel
On Fri, Jul 30, 2010, John Rigby wrote:
Awesome! So it's OMAP for now, is it OMAP3 and 4, or just 3?
By any chance, would you have a list of enabled boards / boards expected to work?
I guess we should file bugs against: https://launchpad.net/linux-linaro
Thanks!
On Sat, Jul 31, 2010 at 12:35 AM, Loïc Minier loic.minier@linaro.org wrote:
John,
If you're following the Ubuntu Kernel Team mailing list, you'll find patches posted by me to enable OMAP4 (one backport + config). This will get you OMAP3 and 4 support in the same kernel. You could also consider enabling the i.MX51 Babbage board from mainline. Both of these will boot up to serial console.
Regards, Amit
Are these changes going into the Ubuntu kernel? If so then they will come in next time I merge with it. If not I will grab your patches.
On Sat, Jul 31, 2010 at 12:51 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
Ok, I see Nico is planning on getting them for his next merge so they will go in then.
On Mon, Aug 2, 2010 at 6:27 AM, John Rigby john.rigby@linaro.org wrote:
On the subject of adding other platforms, should we do a source package per platform since it takes seven hours to build? I'm not talking about omap4, that can coexist with omap3. Adding mx51 and versatile express are issues though.
As I am thinking about this I wonder if it matters. Is there a difference between one build machine taking 21 hours to build three kernels and three build machines taking seven hours?
John
On Sat, Jul 31, 2010 at 12:51 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
Separate source packages have the following features: + One flavour of the kernel is not dependent on others + Parallel builds (in theory, if there are build machines available) + Different people can upload + Different upload schedules + More useful if we are going to carry non-upstream BSPs - More debian packaging overhead to deal with (debian developers might not agree) - Will go against kernel consolidation WG's work since we might end up with one source tree per SoC
Single source package have the following features: + Single source base for all kernels (multiple flavours to start with, but single flavour once Kernel Consolidation WG is done with it) - Long build times since builds are serialized
In the end, it depends on what exactly we want to package. Are we pushing all BSPs into a single source tree? Or are we carrying separate branches for each?
Cheers, Amit
On 10 Aug 02, John Rigby wrote:
The specific case I was wondering about was parallel builds. Is it worth it to have multiple sources packages that are completely identical sources with the only difference the flavours they build in order to allow for example omap, mx51 and versatile express to all build in parallel.
On Mon, Aug 2, 2010 at 7:20 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Mon, Aug 02, 2010 at 04:20:23PM +0300, Amit Kucheria wrote:
Dependent in what sense? There is some risk that with everything in one source package, a bug in a flavour-specific module will cause a build failure for all flavours; but I would expect this to stabilize fairly quickly, and we could always revisit the package organization if it proved to be an ongoing problem.
Kernels that aren't built from the consolidated source tree are a separate issue. Certainly if it's built from a separate kernel tree, it needs to be a separate source package.
Again, a separate issue; if we build separate source packages for each flavour because it's convenient, those source packages should be strictly managed to avoid divergence between kernel source, with differences only in the package names, kernel configs, and module contents.
For me the only reason that could tip us in favor of separate source packages for a single kernel tree is the serialized build and long build time.
Cheers,
Bumping up this discussion.
On Sat, Jul 31, 2010 at 9:51 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
John,
Any news on adding a i.MX51 and versatile-express flavour?
/Amit
On Fri, Jul 30, 2010, Loïc Minier wrote:
By any chance, would you have a list of enabled boards / boards expected to work?
I tested it on IGEPv2, and it started fine; to my surprize, it found: mmcblk0: p1 p2
which I thought was borken with Ubuntu-ish kernels. I didn't actually try Ubuntu OMAP kernels to compare though, and it might also be a specific config combination which triggers the issue with Ubuntu kernels. How was the OMAP config built for your packages?
I'd love a place where I could note that I test-booted linux-image-2.6.35-1000-omap_2.6.35-1000.2_armel.deb on IGEP v2 and that it passed smoke testing.
Cheers,
-
Amit Kucheria -
John Rigby -
Loïc Minier -
Steve Langasek