linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Fan Ye

Hi, I am currently working on Pandaboard and want to make PMU interrupt work. I notice that you have a patch to enable pmu/perf support on OMAP4: http://lists.linaro.org/pipermail/linaro-dev/2011-April/004019.html Can you please tell me on which code base of the kernel the patch is working? I am using minimal FS on pandaboard. But the patch does not work. I find the PMU interrupt is not triggered. Thanks a lot in advance. Ye Fan

13 years, 6 months

hackbox will be rebooted on Friday, 2011/11/11 (how cool is that date eh?) at 11:11 UTC

by Zach Pfeffer

We're going to upgrade the hackbox on Friday, which means a reboot. As we've always mentioned the hackbox doesn't get backed up, so everything in /mnt/user will be nuked. Please back anything you care about up. Danilo, If we can get a list of files together, would you be able to set up a backup restore mechanism for those files? The only file on the list right now would be /home/ubuntu/.ssh/authorized_keys -- 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

13 years, 6 months

Linaro Android Kernel Release for Nov 2011

by John Stultz

Just following the release of the linux-linaro-3.1-20011.11-0 tag being made, I've updated the Linaro+Android tree. I've tagged it as: linux-linaro-3.1-2011.11-0-android-1 >From the branch: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase thanks -john

13 years, 6 months

[ACTIVITY] Multimedia WG weekly status report - wk46.2011 (20111107-20111111)

by Ilias Biris

Detailed status report - with working links: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Week 46 meeting notes: = Highlights = - Speex is back in the radar following requests coming from Android to provide a NEON optimised version. Deliverables arranged for 11.11 and 11.12. - libpng: NEON auto detection is now implemented at a local patch which will go into the Ubuntu LEB for 11.11. - libjpeg-turbo: moving forward with the actions at Connect. The first list of actions are reflected in the blueprints targeted for 11.11, such as updating libjpeg-turbo packaging to include libjpeg8 support, and collecting tjbench performance information - Alsa UCM for PA: the work aims to provide a more natural natural fit of alsa UCM concepts to Pulseaudio core concepts. The work continued post-LC with a look at the contributed upstream patches (intel-origin) which seem to be partly driven from a need to handle policy and also partly originating at the jack detection discussion and patches upstream. The investigation there is ongoing, but a list of findings are put together in the MMWG UCM for PA analysis page. But at least for 11.11 a release containing the patches Wei has been putting together which do the mapping in a more PA agreeable way will be made available. - UCM for Android phase 1 has started and will be hopefully at a good shape for the 11.12 release - End2End testing: the basic case of end2end testing for audio will be ready for 11.12 - From UMM side: + Debug and tracing patch for CMA has been contributed thread on linaro-mm-sig) + Following the dri2video on xf86-video-nouveau reference implementation for dri2video effectively employing the UMM work that has been going on. Most of the dri2video stuff is implemented plus a simple test app in libdri2. The nouveau reference prototype seems to have reached a good point to allow sending patches after some cleanup. This will be officially ready during 11.12 Questions, comments, other feedback are welcome. -- 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

13 years, 6 months

Linaro Kernel November 2011 Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) is excited to announce the availability our October 2011 development snapshot: linux-linaro-3.1-2011.11-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/linux-linaro-3.… The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.1.git tag: linux-linaro-3.1-2011.11-0 This kernel includes the following changes from the 2011.10 kernel: - The v3.1.1 stable kernel - LPAE support from Catalin Marinas - Samsung cpuidle work from Amit Kachhap - sched_mc optimization from Vincent Guittot - Fix for mmap greater than 2GB from Rob Herring A full change log against the 2011.09 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/CHANGELOG-linux… High Priority Known Issues: - None at this time This month's release is about a week early due to the upcoming Thanksgiving holidays in the US. If we find any major issues in the next few days, we will spin a new tarball. Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

13 years, 6 months

important oneiric daily snapshot change

by Tom Gall

Hi All, As a result of bug https://bugs.launchpad.net/linaro-ubuntu/+bug/890185, it was decided to enable a default password on images going forward. The released snapshots now use the password "linaro" for the linaro account. Auto login behavior for the serial cons as well as the graphical cons via lightdm for those images that use it should be otherwise unchanged. -- 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

13 years, 6 months

Re: [android-building] Re: ICS is coming to AOSP

by Zach Pfeffer

On 14 November 2011 20:01, Jean-Baptiste Queru <jbq(a)android.com> wrote: > I've just pushed the source for the PandaBoard kernel: branch > android-omap-panda-3.0 in the kernel/omap project. I expect that's the > one you might be most interested in since it can be run on hardware > right away. Thanks! > Maguro (i.e. Galaxy Nexus) is next on my list. > > JBQ > > On Mon, Nov 14, 2011 at 5:20 PM, Ezekeel <notezekeel(a)googlemail.com> wrote: >> Thank you very much. Sadly there are some companies out there that do not >> take the GPL seriously and release the source whenever they see fit (which >> might be never). Fortunately judging from previous experience Google is not >> one of them. >> I am just really excited about having a new kernel to toy around with and >> with the sources released I can start porting my kernel for ICS. >> >> -- >> You received this message because you are subscribed to the "Android >> Building" mailing list. >> To post to this group, send email to android-building(a)googlegroups.com >> To unsubscribe from this group, send email to >> android-building+unsubscribe(a)googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-building?hl=en >> > > > > -- > Jean-Baptiste M. "JBQ" Queru > Software Engineer, Android Open-Source Project, Google. > > Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning. > > -- > You received this message because you are subscribed to the "Android Building" mailing list. > To post to this group, send email to android-building(a)googlegroups.com > To unsubscribe from this group, send email to > android-building+unsubscribe(a)googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-building?hl=en > -- 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

13 years, 6 months

dependencies between actions in the dispatcher

by Michael Hudson-Doyle

Recently I've been thinking about the dispatcher a bit (as other mails should have indicated) and I've gotten to think about dependencies between actions. If you don't already know, a dispatcher job file mostly consists of a list of actions to execute, for example: "actions": [ { "command": "deploy_linaro_image", "parameters": {"rootfs": "...", "hwpack": "..."} }, { "command": "lava_test_install", "parameters": {"tests": ["stream", "ltp"]} }, { "command": "boot_linaro_image" }, { "command": "lava_test_run", "parameters": {"test_name": "stream"} }, { "command": "lava_test_run", "parameters": {"test_name": "ltp"} }, { "command": "submit_results", "parameters": { "server": "http://localhost/lava-server/RPC2/", "stream": "/anonymous/test/" } } ] I hope what the actions do is reasonably clear from their names. What is easy-ish for us, but probably rather harder for a computer program to do is to see the data dependencies between the different actions. boot_linaro_image makes no sense if deploy_linaro_image failed. Running tests with lava_test_run doesn't make sense if the test failed to install (or if boot_linaro_image failed). But the lava_test_run's are independent, even if the stream test hangs we could still run the ltp tests. And we should always submit the results, that's a kind of special case (and I'm not sure submit results should really be an action). It seems like the way we (aim to, at least) handle this isn't too bad: basically any action can veto the running of any more actions (apart from the special case of submit_results). But there's more than control flow going on here -- there is data flow too. The reason I'm writing this mail is that I'm working on testing images in qemu[1]. If we want to use a similar layout of the job files (and I think using the same commands even will be possible), then we'll have an action that builds an image and another that starts up qemu. The action that starts up qemu needs to know where the previous action is! And of course I've been a bit sneaky here, because there's another, very important kind of data that needs to move around: the test results. Currently we assume that all the test results end up in a particular directory (either on the device (for ubuntu-based tests) or on the host (android-based tests)). This feels a bit grotty to me, and will need to change for tests run under qemu and possibly for the multi-system tests that were discussed at the connect. There is an object in the dispatcher -- the context -- that encapsulates the state that persists through the run, so this is probably where the data should live -- we could have a dictionary attached to the context and then deploy_linaro_image for a qemu client type could stuff the path into this and the boot_linaro_image action for a qemu client could read this path (and complain appropriately if its not there). Additionally we could have a list of 'result locations' (could be filesystem paths on the host, or locations on the linaro image) and the submit results step could read from here to gather together the results. This feels like it will work, but is still a bit implicit -- it's still not obvious that boot_linaro_image depends on something deploy_linaro_image does -- but maybe this is information that should be maintained outside in the job file, maybe in a JSON schema for job files? Apologies for the second brain dump today. I think these are the changes I want to make: 1) Change submit results to not be an action. 2) Add a result_locations list and action_data dictionary to LavaContext. My half-thought through idea is that actions will use the action name as a prefix, e.g. deploy_linaro_image for a qemu client might set 'deploy_linaro_image.qemu_img_path' in this dict. 3) Change the lava-test and lava-android-test to store into result_locations and the submit step to read from there. 4) Use action data to have deploy_linaro_image and boot_linaro_image (and maybe lava_test_install and lava_test_run) talk to each other. What do you guys think? Cheers, mwh [1] testing in qemu is perhaps not incredibly useful for us, but doing this forces me to confront some of the issues with testing images with in a fast model, which is something we really want to do, as we can get access to the fast model of the cortex-a15 long before we'll get access to hardware

13 years, 6 months

Freeze date for the Linaro 11.11 kernel release

by Nicolas Pitre

We are considering freezing the 11.11 kernel this next Monday (Nov 14) in order to release it on Wednesday (Nov 16), so it is out there before the US Thanksgiving holiday. If anyone would like to see their patches included in the Linaro kernel for this month, please consider submitting them ASAP. As discussed in Orlando, we are also considering a shift towards using the latest tagged release from Torvalds' mainline tree. This process is not fully in place yet, so the regular Linaro release based on the latest stable upstream release will still occur for this month. Nicolas

13 years, 6 months

Re: LAVA validation status

by Paul Sokolovsky

Hello Dave, On Fri, 11 Nov 2011 10:36:45 +0000 Dave Pigott <dave.pigott(a)linaro.org> wrote: [] > look and feel!), we're asking that you hold off submitting jobs to > LAVA until we give the go-ahead. "Hold-off" as in "please don't submit jobs now - they disrupt us", or "if you submit now, be prepared to not get expected results"? > > I'll e-mail later to let you know when we are fully operational again. > > Many thanks > > Dave Pigott > Validation Engineer > T: +44 1223 45 00 24 | M +44 7940 45 93 44 > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > -- Best Regards, 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

13 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev