linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Connect 2011 Q4 - SoC Technology Group

by Lee Jones

(Go and get yourself a coffee) :) The idea of this new group has gained enough traction such that we have decided to run multiple sessions at Connect. Before we can start to plan the sessions however, we need to gain a better idea of interested parties. So, who and in what capacity do people wish to participate? What is the SoC Technology Group (STG)? Broadly speaking it's a splinter/pseudo group of technical engineers from each applicable Working Group. Although it could easily contain members from Platform, Infrastructure and/or Landing Teams. The primary role of the STG would be to enable feature sets being produced by the Working Groups on each of our supported boards. This team will focus heavily on the upstream kernel. Discussion sessions at Connect Interested parties should be encouraged to attend these sessions. It is here that we shall knock some kind of proposal into shape. There are currently lots of unknowns and loose ends which we need to tie up. Some of the important items shall be mentioned in this email and can be discussed accordingly, others will undoubtedly crop up along the way. A clearly defined road map will need to be defined: 1. Detailing whether we intend to (and are capable of) parallelising development, so that each board is being worked on concurrently. Our members would be less than pleased if we were to prioritise our platforms and theirs were found at the bottom of the list. There are many ways in which we can utilise our limited resources to make this happen, but it will take some careful deliberation in order to figure out an optimal way of working. 2. Detailing which features are the most important for our members. Once decided we need to create a prioritised feature list which will be worked through in sequence. Engineering resources is clearly going to be a touchy subject. Some of the Working Groups are already feeling over-worked and under staffed, but engineers need to come from somewhere. To ease the strain I propose an assignee rotation solution. Swapping out old for new on a per-cycle or per-board enablement basis. The latter is the preferred solution, as it ensures that there are no ends to tie-up and that a feature will be complete before the STG saw fresh blood requiring learning-curve post context-switch. Carrying on with the resources theme, other teams from within Linaro have offered support. As the work is meaningful and interesting there should be no shortage of volunteers. Should the STG consist of members from Platform for instance, or can some of the work be sub-contracted out to them instead? Hacking sessions at Connect Anyone who's interested in undertaking some real coding that will end-up upstream should attend these sessions. There will be plenty of interesting work available to share around. No upstreaming experience necessary. As long as you are capable of turning documentation into functional code I'm sure we can put you to good use. :) Hacking sessions will require clear documentation detailing the APIs for each piece of functionality we wish to enable. Does this already exist? If so, where can it be acquired (http://g.l.o/<wg-tree>/Documentation/)? In the absence of clear documentation, would the WGs provide a Subject Matter Expert (SME) to adopt the role of mentor for the sessions? Or better still, both. As already discussed, we require a detailed, prioritised feature list of missing (i.e. to be coded) and enabled (i.e. fully implemented) features for each board from each of the participating Working Groups. Topics summarised - Discuss: Platform development concurrency strategy - Discuss: Assignee rotation/permanent re-assignment - Required: Documentation - Required: Engineering resources (during the sessions and in the team) - Required: Prioritised missing/enabled feature lists for each platform I think that'll do for now. :) Kind regards, Lee -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

14 years, 1 month

Updated Libjpeg-turbo benchmarks

by Tom Gall

All, For those that care about such things, located in the linaro wiki : https://wiki.linaro.org/TomGall/LibJpegTurbo is benchmarking information and numbers from various arm boards and OSes. Much thanks must be given to Chao Yang for collecting the android numbers. The page is an evolving beast but I thought worth drawing your attention to. OSes include: Android 2.3.5 Linux (Linaro natty) Libs measured include: libjpeg62 libjpeg62 + android extentions libjpeg-turbo - 1.1.90 libjpeg-turbo - 1.1.90 + android extentions I've also included some some graphs for those that might want a higher level comparison. I will at some point add libjpeg v8 numbers into the mix. Feedback most welcome. -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 1 month

[ACTIVITY] Weekly status Graphics WG - wk39.2011 (20110926-20110930)

by Ilias Biris

Status: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-09-28 == Highlights == * Planning 11.10 * Working out how to handle backlogs - details discussed about series, backlog milestones, creation of blueprints in backlog and targeting blueprints to monthly milestones * For next quarter, there have been some draft requirements in review such as * UMM * Buffer sharing : https://linaro-public.papyrs.com/public/4147/GWG2011-UMM-BUFFER-SHARING# * DMA mapping API: https://linaro-public.papyrs.com/public/4524/GWG2011-UMM-DMA-MAPPING# * Benchmarking: https://linaro-public.papyrs.com/public/4143/GWG2011-BENCHMARK-DASHBOARD, also in Launchpad https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-be… * Webkit port using CAIRO-GLES: https://linaro-public.papyrs.com/public/4146/GWG2011-WEBKIT-CAIRO-GLES/# also in Launchpad https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-we… * Other Launchpad blueprints * Unity-GLES: https://blueprints.launchpad.net/unity-gles/+spec/linaro-gfxmm-unity-gles * GLProxy: https://blueprints.launchpad.net/glproxy/+spec/linaro-gfxmm-glproxy Please let me know if there are any questions. Best, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

14 years, 1 month

Re: downloading repo -- can't connect to android.git.kernel.org ?

by Paul Sokolovsky

Hello, On Tue, 4 Oct 2011 14:19:39 -0700 Jean-Baptiste Queru <jbq(a)android.com> wrote: > Chicken-and-egg: you can't submit a patch for the AOSP web site saying > that the AOSP servers are down... because the AOSP servers are down. > > We're working on it. Now that kernel.org is up, any ETA for when we can expect android.git.kernel.org be back up too? Or at least, can we be sure it will be the same hosts structure/setup as before? Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

14 years, 1 month

android-build prefixes: staging- landing- tracking- <no prefix>

by Zach Pfeffer

I've had a couple of questions about some new prefixes that are showing up on https://android-build.linaro.org. Here's the breakdown: staging- LT board support patches + jstultz's common Android tree, this is a pretty stable point landing- LT board support patches on some version of the kernel tracking- LT board support patches + Linus HEAD + the Android tracking branch <no prefix> Only jstultz's common Android tree, the so-called upstreamed only support These builds go into the LEB ranking system. This system gives the build a star value depending on what's working (Ethernet, Audio, etc..). If a build attains a certain star value it is called an LEB. Feel free to catch me on this thread or on irc or mumble if you've got any comments or questions. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

14 years, 1 month

Announcing linaro-media-create and live-build integration

by Tom Gall

Hi All, As part of the 11.09 cycle I've completed an extension to live-build3 that add linaro-media-create. This means with this branch of linaro's live-build 3 one is able to build your custom image and directly output it to either your SD media or to a file which you an dd directly to the media of your choice. The extension lives in a bzr branch at lp:~tom-gall/live-build/integrate-linaro-media-create This code should be considered beta quality. There are bugs. The code is however useful. It will be especially useful when combined with the cross build support for live-build that was announced as part of the 11.07 cycle. I've updated my HOWTO which can be found here: https://wiki.linaro.org/LiveHelper/Hacking If you run into issues please either file a bug in launchpad https://bugs.launchpad.net/linaro-ubuntu , post to the list, or grab me on irc. (tgall_foo or Dr_Who) -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 1 month

Linaro and common- tree

by Andy Green

Hi - Recently at Linaro we've started a new tree linaro-androidization-tracking, which is pretty much "common-3.1"[1] at the moment on 3.1-rc8 basis. http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary We have already been running a kernel tree tracking Linus HEAD since 2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD, so we have some experience with the rough and tumble. What we missed having was an "all year round" Androidization tree that we could combine it with to casually create Android versions of the work we were doing on Vanilla Linus HEAD basis. We used common-3.0 for that for a while late in the kernel release cycle when it was tracking Linus HEAD itself and that was great. But common-3.0 like the name suggests is really a release tree, and it stops tracking at release, and a new one starts up only late in the next kernel release cycle. Actually, it would be a big advantage for many folks to not be doing their Android kernel development on lagging releases, but by tracking Linus HEAD. They would have access to latest stuff already and they don't have to think about backport or later forwardport stuff to a new release, it's constantly tracking HEAD and being adapted. One side-effect of using this tracking methodology is if they want release trees, they can just clone their tracking branch at the time Linus HEAD is at a release point and bam, a hopefully fully working release tree is there. Another very nice side-effect is they can do the bulk of the work once on a Vanilla Linus HEAD basis, and get and Android version of that work routinely by merging or rebasing in the Androidization tree - instead of doing and validating work twice on separate Vanilla and Android trees. So linaro-androidization-tracking is our attempt at that Linus HEAD Androidization tree, moving it on regularly and fixing breakage as it happens throughout the cycle. It's generic same as common-, it should be usable for any arch or board to Androidize a vanilla kernel that is on the same Linus HEAD basis just by merge or rebase action. It seemed this effort might be interesting for the guys that make the common- trees, since if there was a tracking Androidization tree, in fact common- releases for release trees like common-3.1 would just naturally fall out of it when Linus HEAD was at 3.1. So I'd be very happy to hear any opinions about that. Another side-issue is we are also looking at refactoring the Androidization patchset into topic branches, at the moment they're kind of reflecting the history that they were applied on plus or minus some munging around. So, all the net core patches for example would be together in one series, then all the wireless ones in a series on top of that, etc. It seems they would be easier to maintain then, opinions on that approach are also welcome. -Andy [1] TI have a tree on omapzoom where we got the patches from http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi… (Apologies for any duplication, googlegroups needs mail sent from Google mail) -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

14 years, 1 month

Ubuntu build jobs are now scheduled at 16:00 UTC

by Fathi Boudra

Hi, Follow-up to Linaro 11.09 RC call for testing thread: > > IMO, we should stick to Monday for the RC images and call for testing. > > It gives 3 full days to collect the reports and fixes critical issues. > > Though, using autobuilt images isn't optimal. What about triggering a > > manual rebuild on Monday at 16:00 UTC to get the RC images? > > This way it gives some extra time for integration, but not a full day. > > Unfortunately, the schedule is tight on a monthly release cadence... > > so we don't have much flexibility. > > We could just have a build job scheduled at 16 UTC at offspring, so we > avoid requiring manual builds. I believe this would be our best option > (and it usually takes around 3 hours to build all images). This is effective now. Ubuntu build jobs are scheduled at 16:00 UTC. Cheers, -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs

14 years, 1 month

oneiric, hwpacks + linaro-media-create

by Tom Gall

Hi, Not getting any answers in #linaro. Which version of linaro-media-create is required for oneiric based hwpacks and images? Should the PPA version suffice or does one need to use the latest greatest from bzr? Thanks! -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 1 month

Please complete registration for Linaro Connect

by Stephen Doel

Hi All, I'd like to remind you to complete all the registration details for Linaro Connect. These can all be found here: http://connect.linaro.org/events/event/linaro-connect-q411/#welcome As a reminder, you need to do 4 things: 1. Plan your travel - you should arrive on Sunday and leave the following Saturday 2. <https://resweb.passkey.com/Resweb.do?mode=welcome_ei_new&eventID=3836512&ut m_source=186&utm_medium=email&utm_campaign=5535736> Book accommodation - at our discounted delegate rates 3. <https://www.tfaforms.com/208876> Register Now - and we'll make sure you're kept up to date with the latest information about the event 4. <https://launchpad.net/sprints/lcq4.11> Register for Linaro Connect Q4.11 on Launchpad - this is our planning tool for the event. (Note: If you have already registered with UDS-P, you don't need to re-register) Summits and tracks are now being put together, so once you've registered on Launchpad, you can start subscribing to the Blueprints you're interested in. Thx Stephen Doel Chief Operating Officer T: +44 1223 45 00 23 │ M: +44 77 66 014 247 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro/155974581091106> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog

14 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev