linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Call for opinion: Linaro 'Developer' Image

by Jamie Bennett

Hi, Currently we are reassessing whether or not the Headless image meets the requirements for a console-only developer focused image usable for kernel, boot loader, power management and other types of non-gui development. Just for information the current stats as of 2011-01-21 are: * Download Size: 64M * Download size with OMAP3 hwpack: 100M * Package count: 260 The list of package currently on the image can be found at: https://wiki.linaro.org/Platform/Foundations/Specs/DeveloperImage#Package List The current thoughts are to increase the package count and download size by adding a number of developer focused packages. The initial list of additional packages can be found at: https://wiki.linaro.org/Platform/Foundations/Specs/DeveloperImage#Design Is there anything missing? A more stripped down 'nano' image will be produced for board bring-up and verification, see my other email entitled "Call for opinion: Linaro 'Nano' Image" for more information. Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms? Regards, Jamie. -- Linaro Release Manager

14 years, 3 months

Re: [PATCH] arm: Improve MMC performance on Versatile Express

by Russell King - ARM Linux

On Mon, Jan 24, 2011 at 04:39:21PM -0000, Pawel Moll wrote: > > Well, fixing MMCI because ISP1761 is buggy is not the way forward. > > The answer is to fix the broken ISP1761 driver. > > Totally agree. The thing is that you are the only person right now who > doesn't have any problems. That's not my problem. A simple search of the linux-usb mailing list will give you the patch: http://marc.info/?l=linux-usb&m=129469114904445&w=2 > The others can quickly benefit from the workaround. Others _can_ quickly benefit from the ISP1761 fix by applying the above patch, which not only fixes the MMCI overruns, but also allows USB to serial devices to work with Versatile Express. The above patch is the correct solution. For christ sake, that patch is a fix for a *known* errata issued by the ISP1761 manufacturer. > > Well as I see it, it's pointless enlarging the FIFO. ARM Ltd isn't > > going to give me updated FPGA images for the Integrator/CP, Versatile > > PB926, Realview EB and Versatile Express. > > If we succeed with this, you (and all other users) will get the > "improved" FPGA image. But for VE only indeed. That's utterly useless and completely pointless. Look, stop jumping off a cliff with this and come back to reality. The ISP1761 is buggy. We have a fix. We have a tested fix. We have a tested fix out on mailing lists for everyone to use. It fixes more than MMC overruns and makes the ISP1761 usable. The only problem is that it's taking *FAR* too long for it to get into mainline for no apparant reason. That doesn't stop anyone taking the tested patch in the URL above and gaining proper USB functionality. The right thing to do is to follow up on my reply on the ISP1761 thread to find out why it's taking soo long for it to get into Linus' tree. I repeat, with the proper set of patches in mainline THERE IS NO ISSUE WITH MMCI. THE HARDWARE DOES NOT NEED "FIXING". Please listen to me.

14 years, 3 months

Call for opinion: Linaro 'Nano' Image

by Jamie Bennett

Hi, Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are: * Download Size: 64M * Download size with OMAP3 hwpack: 100M * Package count: 260 The list of package currently on the image can be found at: https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that. Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms? Regards, Jamie. -- Linaro Release Manager

14 years, 3 months

Linaro 2.6.37 git tree not booting?

by john stultz

Hey Nicolas, Over the last few days I've been playing with recent kernels on a BeagleBoard xM. So far I've gotten Linus' v2.6.37 kernel booting, as well as the android-2.6.37 git tree booting as well. However, when I try to boot the latest linaro 2.6.37 git tree, I just get: Starting kernel ... Uncompressing Linux... done, booting the kernel. And nothing else. I've tried enabling early printk, but still nothing. I'm working on bisecting down what broke since 2.6.37, but if you have any hints, I'd appreciate it! thanks -john

14 years, 3 months

how to get hardware accelerated video and OpenGL ES for OMAP3530 (IGEPv2 board)? (noob alert)

by Jörg Hohensohn

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

14 years, 3 months

Notes & Actions: Linaro Developer Platform Weekly Status Meeting 1/19

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on January 19th in #linaro-meeting on irc.freenode.net at 15:00 UTC. https://wiki.linaro.org/Platform/Foundations/2011-01-19 Regards, Tom (tgall_foo) Developer Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 3 months

Linaro PPAs and backports / release cycles

by Loïc Minier

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

14 years, 3 months

btrfs-tools for arm

by Per Forlin

Hi, I am using the linaro-m-headless-rootfs and tools for btrfs are missing. I want to put btrfs on the onboard MMC and therefore I would like to run btrfs-tools on target. Does any one have arm version of the btrfs-tools? BR Per

14 years, 3 months

Linaro Instructions for Overo(Gumstix)

by Andy Doan

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

14 years, 3 months

Hardware Packs v2

by Loïc Minier

Hey there As a result of a series of bugs around linaro-image-tools and daily images, it seemed a sensible approach to solve this class of issues would be to move more data into hardware packs rather than hardcoding stuff in linaro-image-tools. Guilherme, Steve Langasek, and Michael Hudson were all interested in the idea, so Michael convinced me to start a wiki page with some notes: https://wiki.linaro.org/Platform/Specs/11.05/HardwarePacksV2 I'm sending this for others to get the chance to raise issues with hwpacks since we don't want to change the format too frequently. Cheers, -- Loïc Minier

14 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev