linaro-dev February 2011

linaro-dev@lists.linaro.org

120 participants
166 discussions

GCC ICE compiling glibc with latest linaro gcc 4.5

by Khem Raj

Hi Commit r99457 on linaro 4.5 branch is causing a ICE when compiling the attached file with following options gcc-4_5-branch/build.i686-linux.armeb-oe-linux-gnueabi/gcc/cc1 -O2 -mtune=xscale a.i It only happens when I use -mtune=xscale otherwise it compiles fine It was tested on armeb I have not done a test on LE. I have attached the testcase to this email as well. Thanks -Khem

13 years, 10 months

[PM] 16/02/2011 - Minutes for the Power Management WG weekly call

by Vincent Guittot

Hi All, The minutes of the power management weekly call can be found at : https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-02-16 Regards, Vincent

13 years, 10 months

[RFC] agent-based remote validation invocation for LAVA

by Jim Huang

Hello list, Regarding integration of LAVA [1] architecture with Android devices, we would like to reuse the existing infrastructure and framework design. Abrek [2] is a great testsuite framework for running test cases and benchmarks. However, due to the restrictions of unusual Android runtime, we consider to introduce the agent-based remote validation invocation mechanism for LAVA as the extension. Also, the proof-of-concept implementation is attached. ** Why can't we execute LAVA/Abrek directly on Android devices? LAVA/Abrek is written in Python, which implies there must be a solid Python runtime for Android. CPython is verified and well-designed, but it is not well tested on Android. In fact, Android has its own libc implementation, bionic, which is the minimal and special libc originally taken from NetBSD libc. However, bionic libc only supports limited set of POSIX C APIs, and it is almost not feasible to maintain Linaro bionic modifications in early stage just to satisfy CPython. The bionic libc is always changed fast by Google engineers, and we have no idea about their plans. Therefore, we prefer the way not to modify Android runtime. That is, don't execute LAVA/Abrek directly on Android environment. ** Yet another agent? In fact, Android already provide an elegant approach for accessing target environment, adb (Android Debug Bridge)[3], which is a versatile tool allowing users to manage the state of Android-powered device. adb itself is a client-server program that includes three components: (1) A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. (2) A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on the device. (3) A daemon, which runs as a background process on each device instance. The adb protocol can be established through USB (device needs to enable Android USB gadget driver) or TCP/IP. adb is very solid and powerful. For example, if you would like to test Android UI, you can use the command on Host side: $ adb shell monkey -v -p your.package.name 500 The above could be illustrated: Host commands --> adb protocol (USB or TCP/IP) --> Target receives the command --> execute "monkey" Monkey is a program on Android device that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events. In this example, your Android application is launched, and 500 pseudo-random events are sent to it. We call it as "agent-based remote invocation", and it is built-in. ** So, what's agent-based remote validation invocation for LAVA? There are three key items: (a) Agent (b) Remote validation invocation (c) LAVA We keep in mind that we make no technical impact to LAVA architecture, and the "Agent" is just the "helper". Originally, the client-server communication looks like the following: LAVA server <----> LAVA client --> Abrek test suite Since Python runtime is hard to support, the proposed model would be: LAVA server <--> LAVA client --> Abrek test suite || adb extension (host) <--> adb (target) -> execute command For integrating test items and benchmarks for Android, this proposal is running abrek on the host side. By using Android's standard tool, adb to communicate with the adbd (adb daemon) on target, the test case commands can be issued and the output can return back. Besides, the files can be pushed and pull to and from the target by adb as well. Sometimes the results may be stored in certain file on target, and we definitely could couple with the case. Thus, running abrek on host side along with "Agent" should be a workable approach. ** Show me the use case The attached patch is just trivial proof-of concept implementation done by Jeremy Chang that adds a 'monkey' test definition file for abrek. Once TCP/IP or USB is ready, for Android's monkey testing, the procedure is like as following: (1) abrek run monkey (2) abrek dashboard put /anonymous/ monkey1297752359.0 In addition, if we wish to execute certain native application on Android device, abrek could ask adb to send the executable files and related data to target first. Then, execute it as expected. The command looks like: $ adb push <my-executable-file> /system/bin $ adb push <my-data-file> /data $ adb shell /system/bin/<my-executable-file> The above instructions could be refined into "adb extension" as the part of LAVA client framework. That's all. It could be straightforward and transparent. Any suggestion is appreciated. Thank you in advance. Sincerely, Jim Huang (jserv) http://0xlab.org/ [1] https://wiki.linaro.org/Platform/Validation/LAVA/Architecture [2] https://wiki.linaro.org/Platform/Validation/AbrekTestsuites [3] http://developer.android.com/guide/developing/tools/adb.html

13 years, 10 months

ST-Ericsson launches the Igloo open source community

by Lee Jones

http://eetimes.eu/en/st-ericsson-launches-the-igloo-open-source-community.h… =:-D

13 years, 10 months

Announcing the Linaro porting jam

by Steve Langasek

Hello, my fellow ARM aficionados! The Linaro Developer Platform Team is pleased to announce a new initiative to help improve the state of software on ARM: the ARM porting jam. Starting today, February 16th, we will be running a weekly IRC jam on Wednesdays from 1400-1800 UTC to bring developers together to work on all manner of userspace porting bugs, with the aim of fixing portability issues and getting the fixes delivered to our upstreams. An initial porting queue of known issues can be found here: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue Interested in making the software in Ubuntu run better on ARM? Stop on by the #linaro channel on irc.linaro.org today! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

13 years, 10 months

Minutes for Mentor team meeting - 2011-2-15

by Matt Waddel

The wiki formatted minutes are at: https://wiki.linaro.org/Mentoring/Status/2011-02-15 Please direct suggestions or comments to Matt or Andy. Cheers, Matt == Team Highlights == * Wiki Additions * https://wiki.linaro.org/Mentoring/Additions-l-m-c * Email setup * https://wiki.linaro.org/Internal/Process/ThunderbirdSetup * https://wiki.linaro.org/Internal/Process/MuttSetup * https://wiki.linaro.org/Internal/Process/CalendarSetup * https://wiki.linaro.org/Mentoring/HowTo/UbuntuDevelopmentProcess * https://wiki.linaro.org/Mentoring/KernelDeploy == Action Items and Minutes == * Training the Trainers checklist - Both * IRC quick reference link - Matt * Xchat tutorial - Ericm's request - Andy * Conference Call System rewrite - Matt * Tailored new staff to-do list - Add to New Staff task? - Both * Recorded new staff checklist - Maybe a google form - Matt * Review survey - individuals and trends * Mumble - Matt * Gobby - Andy * Tech lead feedback email * Break out Angus' email into to-do items - Andy * Mapping between Launchpad projects and Linaro teams - Both * Android information - Andy * Extend category tag usage * Waiting on Trainers - should we suggest people == Risks / Issues == * Risk - Unable to recruit trainers within member organizations - carry over from last week * Mitigation - Perform mentoring tasks from within this team * Mitigation - Break responsibilities into smaller portions and recruit multiple trainers * Information we have developed is not easy to find or accessible == Miscellaneous == * Holidays - Feb 21, 2011 - US President's day

13 years, 10 months

[RFC] ARM: dma-mapping: outer cache is invalidated twice

by Per Forlin

Hi, My question concerns this patch -------- commit 2ffe2da3e71652d4f4cae19539b5c78c2a239136 Author: Russell King <rmk+kernel(a)arm.linux.org.uk> Date: Sat Oct 31 16:52:16 2009 +0000 ARMv6 and ARMv7 CPUs can perform speculative prefetching, which makes DMA cache coherency handling slightly more interesting. Rather than being able to rely upon the CPU not accessing the DMA buffer until DMA has completed, we now must expect that the cache could be loaded with possibly stale data from the DMA buffer. Where DMA involves data being transferred to the device, we clean the cache before handing it over for DMA, otherwise we invalidate the buffer to get rid of potential writebacks. On DMA Completion, if data was transferred from the device, we invalidate the buffer to get rid of any stale speculative prefetches. Signed-off-by: Russell King <rmk+kernel(a)arm.linux.org.uk> Tested-By: Santosh Shilimkar <santosh.shilimkar(a)ti.com> --------- file: arch/arm/mm/dma-mapping.c > void ___dma_page_cpu_to_dev(struct page *page, unsigned long off, > size_t size, enum dma_data_direction dir) > { > ... > if (dir == DMA_FROM_DEVICE) { > outer_inv_range(paddr, paddr + size); > ... > } > EXPORT_SYMBOL(___dma_page_cpu_to_dev); > > void ___dma_page_dev_to_cpu(struct page *page, unsigned long off, > size_t size, enum dma_data_direction dir) > { > ... > if (dir != DMA_TO_DEVICE) > outer_inv_range(paddr, paddr + size); > ... > } outer_inv_range () is called twice for DMA_FROM_DEVICE. The first time to "get rid of potential writebacks" and the second time to "get rid of any stale speculative prefetches" outer_inv_range() is a rather expensive operation. In the first case isn't it enough to just call cache_sync()? What about: void ___dma_page_cpu_to_dev(struct page *page, unsigned long off, size_t size, enum dma_data_direction dir) { ... if (dir == DMA_FROM_DEVICE) { - outer_inv_range(paddr, paddr + size); + outer_sync(); ... } /Per

13 years, 10 months

Notes from the Infrastructure team meeting - 2011-02-15

by James Westby

Hi, See the notes in full formatted glory: https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-02-15 or see below. Thanks, James === Attendees === * Mattias Backman * Guilherme Salgado * Deepti Kalakeri * James Westby === Agenda === * Team status * Actions from last meeting * AOB === Action Items === * James to Cc Guilherme on RT for patchwork * James to email Guilherme with info on patches(a)linaro.org account === Action Items from previous meeting === * James to talk with Michael about requirement driving not wanting to host artefacts on Hudson === Minutes === * Team status reports * Mattias Backman * Started prototyping BuildFailureBugFiling * Snowball was taken away again * Guilherme Salgado * Wrote design/implementation plans for PatchTracking * Submitted some patchwork patches and got good feedback * James Westby * Continued positive feedback about status.linaro.org, along with requests for improvement * Deepti Kalakeri * Set up Hudson locally to experiment with. * Panda should be arriving this week * Not going to rely on an IS deployed instance of Hudson/Jenkins for short-term experimentation.

13 years, 10 months

Notes & Actions: 2/9 Linaro Developer Platform Weekly Status Meeting

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 February 9th in #linaro-meeting on irc.freenode.net at 16:00 UTC. https://wiki.linaro.org/Platform/Foundations/2011-02-09 Actions from the meeting where as follows: * JamieBennett to come up with test assignments for the new developer image: carried over * jcrigby to write up landing team u-boot, kernel workflows and send for review after first draft is done: carried over * wookey to work with tgall_foo to get the linaro-nano image building * tgall_foo and JamieBennett to get linaro-desktop building in Offspring * slangasek and fturgis to decide whether or not to move to more recent version of systemtap * ppearse to investigate how libtool does ldopen for GObject Introspection work 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

13 years, 10 months

Notes & Actions: Linaro Graphics Working Group - Feb 09, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-02-09 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Summary ======= * Cairo patchset "gl: Replace built-in shader variables with custom variables" sent upstream for review. * Most of the team members able to access git.linaro.org from work place but not confirmed for everyone. * Added desktop GL support to glcompbench benchmark, in order to promote adoption and increase contributions and feedback. * Qtwebkit investigation shows that trace captures for websites (without <canvas>) can be performed without pixmap tracing. * Refactored most core Compiz plugins to make them GLES2 ready. * First experiments adding Mali(ARM's GPU) and UMP driver to Linaro kernel are ongoing. Bugs have been discovered and are being worked on with Samsung landing team. * First version of Unified Memory Management position: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedM… Action Items ============ * Chunsang and Jesse to discuss UMP validation situation and its implications. * Jesse to ensure that we have valid conference call numbers for all members of the gfx WG (deferred from previous meeting). * Jesse to keep track of nux licensing issues (deferred from previous meeting). * Everyone to send Jesse a list of the licenses of the projects they are working on (both new and existing). * Everyone to review Rajeev's comments in their blueprints and fix any pending issues. * Everyone to update blueprints to reflect current work item status. Thanks, -- - Alexandros

13 years, 10 months

← Newer
1
...
6
7
8
9
10
11
12
...
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2011