Re: Hardware Packs v2
On 20 January 2011 05:15, Scott Bambrough scott.bambro...@linaro.orgwrote: On Wed, 2011-01-19 at 15:02 -0600, James Westby wrote: An illustration of what I mean: if we add linux_image and ignore it, and then use it within Android hwpacks, someone with the old code will try and use one of those new hwpacks, and get an unbootable Android image. When that happens someone will say we should have the tool warn people when it can't do what they ask, which we could have done now with a format bump, or by having a more complete plan than ignore the field. I have to jump in here. Hardware packs for Android or ChromeOS seem ridiculous to me. If we want to be accepted by mainstream developers for these OS, then we need to conform to the accepted norm for that community. Imposing hardware packs in these two projects is just likely to get our efforts ignored. Scott I agree with Scott. There is no such thing in Android. The Android build system creates a number of images. A boot image (depending of configuration), a system image and a user data image. A hardware pack would probably be a subset of the boot and system image. It would be hard to introduce a hardware pack for Android without doing major changes. We should not fork Android and become a new Android distribution. We should try to be as close to AOSP as possible. /Patrik -- Scott Bambrough Technical Director, Landing Teams ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Instructions for Overo(Gumstix)
Andy, thanks, and I've just added wiki.linaro.org/Boards as a top level index and a page that I've been using for the Efika mx smartbook... Dave On 20 Jan 2011, at 06:50, Andy Doan wrote: FYI: I've just created a page describing how to get a Linaro image running on the Overo Gumstix board: https://wiki.linaro.org/Boards/Overo/Setup -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-image-tools 0.4(.1)
On Thu, Jan 20, 2011, Alexander Sack wrote: What's the plan for staging/QA before pushing this backport into the tools ppa? Good question; do we have a process for this? I realize we don't have a -proposed/-updates etc. setup for stuff which we only provide in PPAs. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro PPAs and backports / release cycles
Hey As a followup to IRC conversations around backports, releases and QA today, I'd like to hear what others think of our Linaro PPAs. I'll start with some history and proposals: We created a fairly ad hoc PPA layout for the 10.11 cycle, with ppa:linaro-maintainers/tools ppa:linaro-maintainers/override ppa:linaro-maintainers/kernel and nowadays we also have this PPA for toolchain backports: ppa:linaro-maintainers/toolchain and misc other PPAs which I don't really know much about: ppa:linaro-maintainers/user-platforms ppa:linaro-toolchain-dev/ppa ppa:linaro-infrastructure/launch-control ppa:linaro-infrastructure/launch-control-snapshots (and probably many more) There are multiple problems with our current approach: * ~linaro-maintainers membership is poorly defined * it's not clear which software should go in which PPA * it's not clear when we can update which PPAs, e.g. can we update them after 6-monthly releases? how do we QA/validate updates? In general, it's good to avoid PPA proliferation, both for sanity and for the confort of our end users, but I think a consistent set of PPAs is more important than trying to optimize the number of PPAs to the smallest subset possible. Some ideas on addressing this: * have software ownership split by team; ~toolchain owns gcc-linaro and qemu-linaro, ~infrastructure owns * have each team decide between either: - a single PPA for all their outputs (e.g. ~infrastructure/ppa for linaro-image-tools and gcc-log-analyzer) - or multiple PPAs, one per software (e.g. ~toolchain/gcc-linaro PPA for gcc-linaro, ~toolchain/qemu-linaro PPA for qemu-linaro) * optionally, additional PPAs for dailies * optionally, additional PPAs for RC releases [ this is inspired from the set of PPAs for bzr: http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu%20and%20derivatives ] In addition, we'd have a single overlay PPA which would be used for rootfs builds. We could keep the existing one below ~linaro-maintainers. Open questions: - list of ~linaro-teams - do we upload latest release of e.g. gcc-linaro to the natty toolchain PPA if it already gets uploaded to natty proper? Thanks, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro PPAs and backports / release cycles
On 20 January 2011 18:30, Loïc Minier loic.min...@linaro.org wrote: Hey As a followup to IRC conversations around backports, releases and QA today, I'd like to hear what others think of our Linaro PPAs. I'll start with some history and proposals: To my mind the important constraint is that there should be some relatively easy thing that we can say to someone 'and this is how you get a stable Linaro'; and by that I mean the whole thing - a set of tools that build and run everything else including a kernel and preferably debug it. By 'easy' I mean relatively simple, but critically pretty difficult to do wrong or miss a step. There should be a 'stable' version of the entire set - i.e. we're not asking someone else to pick a particular kernel/tools/etc - so that it's easy for people to know what they should get and it 'should just work'. And it should stay working up until at least the next release. Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to get hardware accelerated video and OpenGL ES for OMAP3530 (IGEPv2 board)? (noob alert)
Hi Jorg, The availability of graphics drivers is obviously quite a hot topic at the moment. For your OMAP3 board, you are probably better off sticking with the ubuntu packages (you'll need to add multiverse in order to find the various '*-sgx-omap3' packages) as that will get you up and running fastest. We are working, through the landing teams at Linaro, to get drivers integrated and redistributable, but that is still a work in progress and does not include OMAP3 for this cycle. In the short term, these would also all be binary-only proprietary drivers (as the ones in the ubuntu packages for omap3 are). The free driver question is a much longer term project, though it has begun for us this cycle. I hope this helps you out. cheers, Jesse 2011/1/20 Jörg Hohensohn joerg.hohens...@dreamchip.de Hello, This is my first post, I'm a complete noop to Linaro, discovered it yesterday. Needing to run OpenGL ES applications and media playback, I was excited to find e.g. this one: http://www.youtube.com/watch?v=yhglD0mJiLk (under Linaro, GStreamer playing a video by DSP in fullscreen) and this one, admittedly not Linaro but Debian: http://www.youtube.com/watch?v=Qaypv-JhEVI (Quake3 using hardware OpenGL ES) During first and promising own experiments, I was surprised to find that OpenGL acceleration and A/V decoding by hardware don't seem to be part of the Linaro hardware package. Does anybody have that integrated, or how would I do about that? Interestingly, TI has just released those supporting components in a fresh version: http://focus.ti.com/docs/toolsw/folders/print/linuxdvsdk-dm37x.html But they come with an older kernel. To my understanding, the TI code would have to be recompiled with the Linaro kernel? Thanks for answers, Jörg ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Instructions for Overo(Gumstix)
Followed this quickly today. My build line was different due to the way the branch executed: joey@warthog:~$ overo-kernel-suffix/linaro-hwpack-create --local-deb ./u-boot-linaro-omap3-overo_2010.12-0ubuntu1_armel.deb --local-deb ./x-loader-omap3-overo_1.4.4+git20101223+6f3a261-1ubuntu1_armel.deb ./hwpack.natty.linaro-overo/configs/hwpacks/linaro-overo test On Wed, Jan 19, 2011 at 11:50 PM, Andy Doan andy.d...@canonical.com wrote: FYI: I've just created a page describing how to get a Linaro image running on the Overo Gumstix board: https://wiki.linaro.org/Boards/Overo/Setup -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro PPAs and backports / release cycles
On Fri, Jan 21, 2011 at 7:44 AM, David Gilbert david.gilb...@linaro.org wrote: On 20 January 2011 18:30, Loïc Minier loic.min...@linaro.org wrote: Hey As a followup to IRC conversations around backports, releases and QA today, I'd like to hear what others think of our Linaro PPAs. I'll start with some history and proposals: To my mind the important constraint is that there should be some relatively easy thing that we can say to someone 'and this is how you get a stable Linaro'; and by that I mean the whole thing - a set of tools that build and run everything else including a kernel and preferably debug it. By 'easy' I mean relatively simple, but critically pretty difficult to do wrong or miss a step. There should be a 'stable' version of the entire set - i.e. we're not asking someone else to pick a particular kernel/tools/etc - so that it's easy for people to know what they should get and it 'should just work'. And it should stay working up until at least the next release. Agreed. I'd like an easy way of getting pre-built binaries of all the stable enough Linaro outputs. On the toolchain side this would include the latest monthly releases of Linaro GCC, GDB, and QEMU in native and cross versions as appropriate. A single PPA for the whole of Linaro would be nice. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Instructions for Overo(Gumstix)
Thanks Joey. We had a late breaking bug yesterday that made me switch branches in the document. The fix has now been merged and the Wiki has been updated to point you to the correctLinaro Image Tools: bzr branch lp:linaro-image-tools On 01/20/2011 01:10 PM, Joey Stanford wrote: Followed this quickly today. My build line was different due to the way the branch executed: joey@warthog:~$ overo-kernel-suffix/linaro-hwpack-create --local-deb ./u-boot-linaro-omap3-overo_2010.12-0ubuntu1_armel.deb --local-deb ./x-loader-omap3-overo_1.4.4+git20101223+6f3a261-1ubuntu1_armel.deb ./hwpack.natty.linaro-overo/configs/hwpacks/linaro-overo test On Wed, Jan 19, 2011 at 11:50 PM, Andy Doan andy.d...@canonical.com wrote: FYI: I've just created a page describing how to get a Linaro image running on the Overo Gumstix board: https://wiki.linaro.org/Boards/Overo/Setup -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
AW: how to get hardware accelerated video and OpenGL ES for OMAP3530 (IGEPv2 board)? (noob alert)
Hello Jesse (et al) Thanks for your answer, some confusion remains, see below. I'm fine with proprietary drivers, this just has to work. The availability of graphics drivers is obviously quite a hot topic at the moment. For your OMAP3 board, you are probably better off sticking with the ubuntu packages (you'll need to add multiverse in order to find the various '*-sgx-omap3' packages) as that will get you up and running fastest. Multiverse does include the graphics and DSP objects? Matching what kernel? Ubuntu or Linaro? I'm confused that TI has just made a release, but supply their own, older kernel, probably mismatching kernel objects in Linaro. We may have to stay close to their releases, because there are still bugs in the OpenGL ES implementation. What has to be recompiled then to make it fit? Thanks Jörg ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to get hardware accelerated video and OpenGL ES for OMAP3530 (IGEPv2 board)? (noob alert)
On Thu, Jan 20, 2011 at 4:44 PM, Joerg Hohensohn joerg.hohens...@dreamchip.de wrote: Hello Jesse (et al) Thanks for your answer, some confusion remains, see below. I'm fine with proprietary drivers, this just has to work. The availability of graphics drivers is obviously quite a hot topic at the moment. For your OMAP3 board, you are probably better off sticking with the ubuntu packages (you'll need to add multiverse in order to find the various '*-sgx-omap3' packages) as that will get you up and running fastest. Multiverse does include the graphics and DSP objects? Matching what kernel? Ubuntu or Linaro? I'm confused that TI has just made a release, but supply their own, older kernel, probably mismatching kernel objects in Linaro. We may have to stay close to their releases, because there are still bugs in the OpenGL ES implementation. What has to be recompiled then to make it fit? The Graphics are based off TI's 3.01.00.07 release.. https://launchpad.net/ubuntu/+source/opengles-sgx-omap3 It's a blob, same stuff you get from TI's... with build tweaks to the kernel modules, the same bin works from 2.6.32 to 2.6.37... I don't believe linaro caries the DSP objects yet for the omap3.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
