linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Linaro Valgrind snapshot 20100927 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the availability of a "developer preview" of Valgrind which includes the support for ARM and Thumb which has recently been added by the Valgrind developers. Our aim with this preview release is to advertise Valgrind's improved ARM support and encourage people to try it out and find bugs before the official 3.6.0 release. Please report bugs via upstream's BTS: http://valgrind.org/support/bug_reports.html or you can ask on linaro-toolchain(a)lists.linaro.org if you have any problems. This release is a snapshot of upstream subversion; it should generally work but you may encounter bugs, especially if you run it on hand-optimised assembly that uses obscure instructions. New (upstream) features in this snapshot include: * Greatly improved support for ARM * Support for the Thumb instruction set * Support for NEON and VFPv3 instructions Known issues: * callgrind has difficulty identifying ARM function call and return so may not produce useful results Downloads are available from the Linaro Overlay PPA: https://launchpad.net/~linaro-maintainers/+archive/overlay ...so if you're running Linaro on an ARM system you should be able to just install it with 'apt-get install valgrind'. -- Peter Maydell

14 years, 2 months

Linaro Infrastructure Team Weekly Report (2010-09-17 to 2010-09-23)

by Ian Smith

The weekly report for the Linaro Infrastructure team may be found at: Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-09-23 Burndown chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastr… The burndown chart shows that a number of work items were completed this week, and there are a number of work items awaiting reviews that will complete shortly (pending those reviews). * Filed and fixed bug #639930 (Running undefined subcommands gives a traceback) on Abrek * Fixed bug #640251 (A missing file when running the testsuite in a virtual machine) * Merged entire dev branch into trunk * Branched and released Launch Control 0.1 (after 486 commits) * Asked IS to deploy it at validation.linaro.org * (arm-m-image-building-console): several branches in review * HardwarePacks: integrate hwpack-install with linaro-media-create: DONE Please let me know if you have any questions. Kind Regards, Ian

14 years, 2 months

[PATCH 0/0] omap3: omap3: Various fixes and improvements for IGEP v2 board.

by Enric Balletbo i Serra

Hello, I just sent these patch series to linux-omap upstream. These patch series fixes and improves the support for IGEP v2 board and I think could be interesting to include in Maverick and linaro 2.6.35. Please consider to add, thanks. Kind regards, Enric arch/arm/mach-omap2/board-igep0020.c | 347 ++++++++++++++++++++++------------ 1 files changed, 228 insertions(+), 119 deletions(-)

14 years, 2 months

Re: Binary demotions of kernel packages

by Loïc Minier

On Mon, Sep 27, 2010, Tim Gardner wrote: > The packages that are directly maintained by the kernel team should > all be in main. I suspect linux-linaro _should_ be in universe since > it is not strictly subject to SRU criteria and it is not maintained > by the kernel team. This is how I felt as well, but I recall some people argued in favor of having linux-linaro in main; not sure why anymore. It might have been asac, Cc:ing him. (I had also passed this demotion proposal to Jamie and John, but I'm not sure they got the chance to comment yet.) -- Loïc Minier

14 years, 2 months

Refactoring linaro media create

by Guilherme Salgado

Hi, I've recently changed l-m-c to take an hwpack, which is installed before the image is built. To keep that change simple I had to unpack the binary tarball into a tmp directory, install the hwpack, repack the tarball and then continue with the image generation. This extra unpacking/repacking of the binary tarball is obviously not ideal, so I'm now refactoring l-m-c to make it possible to avoid it when installing an hwpack. The one thing I'm not sure about is whether I should a) unpack the binary tarball to a tmp dir, install the hwpack (which may cause lots of data to be written) and then move that to the SD card or b) unpack the tarball straight into the sd card (as is done currently) and then install the hwpack I'm leaning towards a) because of the poor write speed of SD cards, but if anybody knows of any reasons why I should go with b) now's the time to tell me. :) Cheers, -- Guilherme Salgado <https://launchpad.net/~salgado>

14 years, 2 months

Launch Control 0.2 feature plans

by Zygmunt Krynicki

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I'd like to discuss my plans for 0.2 release for the validation dashboard a.k.a. launch control. I would like to have a roughly two-week development cycle. This will ensure that we don't get carried away with large features taking lots of time without planning them ahead of time. I would also like each release to feature some user-visible improvements (features or bug fixes) as well as backend infrastructure improvements (better tests, better internals, new feature elements that take >1 cycle to develop). I would like to reuse the proposal laid out by James Westby that defines how the infrastructure team plans future work and mix it a little with the original blueprint for the dashboard. What this means in practice is that each release should bring us closer to the feature set outlined in the blueprint _and_ introduce features/changes requested via the stakeholder process. I think this will work fine until we finish all of the features originating in the blueprint. For the upcoming 0.2 release (currently scheduled exactly two weeks after 0.1) I'd like to focus on the following topics: * Support for migrations south. South allows us to change the database on upgrades and plays nice with distributed version control. South is like rails migrations and is in general a very good thing. Without it we will soon start rolling out upgrade scripts that are just an ugly reimplementation of the idea. * Support for background (asynchronous) bundle processing. Currently the bundle is deserialized immediately during the put() request. This does not scale very well and we should really do this in the background. There are several solutions on how to implement background processing for Django apps and I'd like to select something _really_ simple until it is obvious we need more. There is a project called django-chronograph that essentially allows to use cron-like tasks inside django. Chronograph itself is triggered from cron (or some other external cron-like program) and then proceeds to process jobs defined within django apps. For this cycle I'd like to add chronograph dependency and move deserialization into a periodic task. * Better information about failed bundle imports. Currently there are some issues with the way databrowse application works (it seems to choke on OneToOne fields and GeneralRelation fields. This makes it impossible (AFAIR) to navigate to bundle deserialization information from the bundle itself and in general makes it hard to know what went wrong. I'd like to provide a basic set of views that show streams and bundles and provide a clear indication of deserialization errors there. This would be based on existing work on bundle stream views so it should fit in this cycle. * Better unit tests for django views. As discussed with James Westby we should have several approaches to each view we offer. We should test for the contents of the django rendering context (the data that goes in the template) _and_ scrub some of the HTML output to see we didn't make a typo in the template or other similar issue. In general we should add the front-facing view tests and I'd like to spend some time on this. * Initial work for JSON validator. There is a branch with generic JSON schema validator. I'd like to finish this branch (add several missing validators we need) and make it possible to include this validator in 0.3. It would change how we do deserialization from JSON to the database. It would no longer require us to use launch_control.models.* (so less dependency on client side code, something we wanted to have to be able to release them separately in the future). It would also dramatically improve the error messages. I would not merge the branch into trunk yet but rather merge several extra branches into the .json-schema branch itself and get those reviewed as usual. * Initial support for user authentication. I would like to add sign-in/sign-out elements to the web UI. This will allow us to have private/team streams and while not exciting in the short term it is a required step to getting full support for private (and non-anonymous) test data in the system. A roughly identical list of planned changes is also here in my redmine instance: http://suxx.pl/redmine/projects/launch-control/roadmap That is all. Please tell me what you think. Best regards Zygmunt Krynicki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMnwZ1AAoJEKkR4hQBRI+lXmQIAJ+JUlYfz1bHWbEc47GqNZ/I w1JwFHDpmKNsDRvNAeYgYC1IRFSIhf8XiKOgCwWya4HHePmL5gTDA8AaTCz3R5zj mgNHOqawYLnx5reaffYDAKY8L4mDFknScUV5M416YIBvy//Cgfn4yJ4oY0e+3Lkv 6Z1fP607mokZzZNGYb1GOel51JZ4JpCnZqI+UJSOaIvLv2S2zyVtB9dhzNNCWNlf cFwtacwBEG7lTrftB98NzzkvHRkD76Qwt596wEpdaQqHe4oiqP2fUC+9+0X7XPkW XYJzRTKMA6M5dJNohtC5PChqhfR2JohSTiV+LMFyMh/smWqg1k4IrslsC69kXqI= =ZWBF -----END PGP SIGNATURE-----

14 years, 2 months

Notes & Actions: Linaro User Platform Weekly Status Meeting 9/22

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro User Platforms Weekly Status meeting dated 9/22 held in #linaro-meeting on irc.freenode.net at 13:00 UTC. https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-09-22 Regards, Tom (tgall_foo) User Platforms Team

14 years, 2 months

Notes from Landing Teams call 2010/09/24

by Loïc Minier

Hi Notes from today's Landing Teams call; also at https://wiki.linaro.org/LandingTeams/Meetings/2010-09-24 Cheers, === Attendees === * Loïc Minier * Scott Bambrough * Torez Smith * Mounir Bsaibes * Matt Waddel === Agenda === * Action items from last meeting. * Achievements / progress reports * OMAP3 * Versatile Express * AOB === Action Items === * Torez to talk to james_w to create an IGEP hwpack === Action Items from Previous Meeting === * Matt to post LTP results for Vexpress on linaro-dev@ or on the wiki * Matt to close uInitrd u-boot-linaro bug (LP #627843) === Minutes === * Action items from last meeting. * Matt to post LTP results for Vexpress on linaro-dev@ or on the wiki . DONE * Matt to close uInitrd u-boot-linaro bug (LP #627843) . DONE * Achievements / progress reports * OMAP3 * LCD corruption has a fix; Torez needs to test and then Nicolas needs to merge and John needs to upload * eth0 is working out of the box now * wifi support for igep: should definitely be a hwpack at this point; Torez will talk to james_w to see how to create one * Paul handed a XM to Torez and Stephen sent a new one to Torez * Loic will ship an EVM to Torez * Torez can check with ndec (Nicolas Dechesnes) for PowerVR drivers * Versatile Express * Worked on LTP testing * ALSA was working on Vexpress * flash-kernel changes committed to bzr, not uploaded yet though * Will drop Monday meetings as they are too close to the Friday meetings and don't add much value -- Loïc Minier

14 years, 3 months

[PATCH 0/2] OMAP3 PM: sleep code clean up

by vishwanath.sripathy＠linaro.org

From: Vishwanath BS <vishwanath.bs(a)ti.com> This patch series has some clean up in OMAP3 sleep code. Vishwanath BS (2): OMAP3 PM: move omap3 sleep to ddr OMAP3 PM: sleep code clean up arch/arm/mach-omap2/pm34xx.c | 9 +- arch/arm/mach-omap2/sleep34xx.S | 375 ++++++++++++++--------------- arch/arm/plat-omap/include/plat/control.h | 2 + 3 files changed, 189 insertions(+), 197 deletions(-)

14 years, 3 months

Refactoring linaro media create

by Guilherme Salgado

14 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev