linaro-dev July 2011

linaro-dev@lists.linaro.org

107 participants
163 discussions

[ACTIVITY] Tony Mansson 2011/07/03 to 2011/07/09

by Tony Mansson

Tony Mansson <mansson> === Highlights === Gearing up for PM tasks. Support by asac and Mounir. Participated in 11.07 standup release meetings. Installed a daily build on Beagleboard XM and fired it up. Helped Zack with some PM tasks. Established how to work with Mumble (Must leave the office). Verifying build environment is ongoing. === Plans === Verify build environment by using the 11.06 release Tackle the "Enable Launcher2 in Android Builds" BP === Issues === Manufacturing problems with Snowballs. Pulled to help with Snowball verification & release of new firmware. The current 2.6.38 BSP Kernel git does not run. *No* Android-on-Snowball resources available at ST-Ericsson for another three weeks.

13 years, 3 months

[ACTIVITY] Frans Gifford 2011/07/03 to 2011/07/09

by Frans Gifford

== Frans Gifford <fgiff> == === Highlights === * Continued weekly hacking sessions with LT. Android builds now available for Snowball. * Got prototype build job working on android-build.l.o sandbox and generating JSON for validation.l.o. === Plans === * Work with LAVA team to get tests started securely from android-build.l.o. * Continue work with LT to improve android on Snowball. * Start work on Android demo, see what does and doesn't work on Snowball. === Issues === * Need to source a MiniUSB-A to USB-A adapter so I can connect USB hub and then keyboard to Snowball. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years, 3 months

Re: [ACTIVITY] Zach Pfeffer 2011-7-3 to 2011-7-10

by Zach Pfeffer

Original at https://wiki.linaro.org/Platform/Android/Meetings/2011-07-13 === Highlights === * Supported unaccelerated Snowball Android bringup and got the first leb-snowball build going in https://android-build.linaro.org/ * Drove android-build to LAVA integration * Onboarded Chao Yang, Tony Mansson and Botao Sun * Started new MLO integration into TI 3.0 LEB * Reworked HDMI parsing patch to unblock 2.6.39 and TI LT kernel === Plans === * Make the first 11.07 release * Finish MLO integration * Work on libjpeg-turbo Android integration * Switch upstream focused builds to jstultz 3.0 tree * Keep supporting all LTs === Issues === * Need to get WG's work landed early and often so their work will ship

13 years, 3 months

[ACTIVITY] Android Platform Team 2011-06-26 to 2011-07-02

by Tony Mansson

Key Points for wider discussion: 8 engineers are now on board and operative in the Android Platform Team. LT/Android plugfests are all running and seem to be speeding up integration We'd like all teams to ensure that what their doing is always included in our daily Android builds in support of our switch to a continuously integrated flow. Team Highlights: "Include Busybox in Android Builds" for Panda and Beagle boards is ongoing. Team members are setting up build and work environments. The Quickstart guide ( https://wiki.linaro.org/Platform/Android/ImageInstallation) has been updated. A multimedia test script with CPU usage coverage is ongoing. A HDMI issue in TI 2.6.39 Kernel has been fixed. Cooperation with Landing Teams are working well. 11.07 Android Blueprints can be found at https://launchpad.net/linaro-android/+milestone/11.07 Miscellaneous: Please pull and test our daily builds: https://android-build.linaro.org/builds/~linaro-android/panda/ https://android-build.linaro.org/builds/~linaro-android/leb-panda/ https://android-build.linaro.org/builds/~linaro-android/beagle/ https://android-build.linaro.org/builds/~linaro-android/leb-snowball/ (note: if your contribution isn't in these builds it probably won't get in for 11.07 unless you talk to me ASAP) and our first 11.07 releases: https://android-build.linaro.org/builds/~linaro-android/beagle-11.07-releas… https://android-build.linaro.org/builds/~linaro-android/panda-11.07-release/

13 years, 3 months

11.07 Android Deliverable Reminder

by Zach Pfeffer

All, Just a quick reminder. If you're trying to get anything delivered into an Android target for 11.07 you should have talked to me and we should have an integration BP tracking it. You should also be testing your stuff against the Android target you want to deliver on. Simply getting source into an Android build that isn't turned on is not considered landing. Things will need to be tested, documented and characterized against Android. We're doing continuous integration so code should be pushed early and often. Here's the current list of things we're going to land in 11.07: https://launchpad.net/linaro-android/+milestone/11.07 If you're not sure where to start with Android talk to me and we'll get you going. You don't even need a board (though it helps). Our tip build right now is on Panda and will be pointing to the 3.0 kernel soon. -Zach

13 years, 3 months

Problems re-using "repo manifest -r" manifests with repo

by Paul Sokolovsky

Hello, Here at Linaro, we pull components for Android builds from various sources, like AOSP upstream, our forks of AOSP components (to fix compatibility issues with gcc 4.5/4.6, etc.), bootloaders and kernels from SoC support teams, etc. All in all, that means that we don't have full control over those repositories for example to tag them. So, to achieve build reproducibility, we decided to use a feature that repo provides, exporting "release" manifest for a build using "repo manifest -r", which dumps manifest with SHA1 revision ids of components used for particular build. However, we found that such release manifests are not robust over time. If an upstream project uses rebase work model, then, even if a particular revision was tagged which ensures that this revision won't be garbage-collected if rebased later in main branch, the repo tool may not be able to fetch it. This happens because, unlike git clone, the repo tool limits what it fetches to refs/heads/*. So, if some revision is not reachable from one of branches (but still reachable from refs/tags/*), it will lead to an error like: error.GitError: boot/u-boot-linaro-stable update-ref: error: Trying to write ref refs/remotes/m/linaro_android_2.3.3 with nonexistant object 9736a9332fcfe5fef1361a6d91740e160ad04bd5 fatal: Cannot update the ref 'refs/remotes/m/linaro_android_2.3.3'. So, we would like to know if this can be considered a bug (it looks pretty much such for us, after all, we're just trying to feed up repo with what it generated, while 100% having valid revisions in the underlying repositories), and can be fixed. The patch would be pretty simple: diff --git a/project.py b/project.py index 9d67dea..31ee90f 100644 --- a/project.py +++ b/project.py @@ -1369,7 +1374,7 @@ class Project(object): else: ref_dir = None - cmd = ['fetch'] + cmd = ['fetch', '--tags'] # The --depth option only affects the initial fetch; after that we'll do # full fetches of changes. -- 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, 3 months

Usefulness of GCC's 64bit __sync_* ops on ARM

by Ken Werner

Hi, We've been thinking about adding support for the built-in functions for 64bit atomic memory access and I'd like to know if this is of any interest. Currently the main use of these functions seems to be to implement (SMP safe) locking mechanisms where the existent 32bit memory ops are sufficient. However, there might be code out there that implements a parallel algorithm using 64bit atomic memory operations. Currently the GCC ARM backend doesn't provide a pattern to inline 64bit __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The libgcc does not provide these symbols via the usual thin wrapper around the kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit only. My understanding is that for ARMv7 the GCC backend could be enhanced to inline the __sync_* functions by using the LDREXD and STREXD instructions. But for ARMv5 we would still rely on a new kernel helper. Any ideas/thoughts are appreciated. [1] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#GCC [2] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#impl… Regards Ken

13 years, 3 months

[PATCH 0/2] ORIGEN Board Support

by Chander Kashyap

Adds support for ORIGEN board with MMC Booting. Chander Kashyap (2): ARMV7: Add support for Samsung ORIGEN board ORIGEN: Add MMC SPL support MAINTAINERS | 1 + board/samsung/origen/Makefile | 46 ++ board/samsung/origen/lowlevel_init.S | 468 +++++++++++++++++++++ board/samsung/origen/mem_setup.S | 392 +++++++++++++++++ board/samsung/origen/origen.c | 103 +++++ boards.cfg | 1 + include/configs/origen.h | 167 ++++++++ mmc_spl/board/samsung/origen/Makefile | 105 +++++ mmc_spl/board/samsung/origen/mmc_boot.c | 75 ++++ mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 ++++++ mmc_spl/board/samsung/origen/u-boot.lds | 86 ++++ 11 files changed, 1583 insertions(+), 0 deletions(-) create mode 100644 board/samsung/origen/Makefile create mode 100644 board/samsung/origen/lowlevel_init.S create mode 100644 board/samsung/origen/mem_setup.S create mode 100644 board/samsung/origen/origen.c create mode 100644 include/configs/origen.h create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds -- 1.7.4.1

13 years, 3 months

Fwd: Re: ppas, version numbers, releases and validation.linaro.org

by Zygmunt Krynicki

Forwarding at it got bounced (odd?) ------ Wiadomość oryginalna ------ Temat: Re: ppas, version numbers, releases and validation.linaro.org Data: Mon, 11 Jul 2011 11:35:46 +0200 Nadawca: Zygmunt Krynicki <zygmunt.krynicki(a)linaro.org> Firma/Organizacja: Linaro Adresat: Michael Hudson-Doyle <michael.hudson(a)linaro.org> Kopia: linaro-dev(a)linaro.org, paul.larson(a)linaro.org W dniu 11.07.2011 06:34, Michael Hudson-Doyle pisze: > Hi Paul& Zygmunt (& others), > > I spent a while today fixing a couple of bugs in lava-tool and in the > packaging of lava-server, and was wondering what the process should be > for getting them into the ~linaro-validation ppa and onto v.l.o > (although there's no particular urgency in getting these precise fixes > deployed, there will be changes that are more urgent). > > In some sense these are basic debian packaging questions I guess. But > my understanding of the process is that it should go like this: > > If there are upstream changes, make a new release (update the version in > __init__.py, tag the branch, make an sdist and upload it to pypi). Agreed > Then (whether there is an upstream change or not) it should be uploaded > to a PPA. I think the part here that I don't really get is basically > how to use bzr build-deb in practice. But I've just found > http://jameswestby.net/bzr/builddeb/user_manual/merge.html so I think I > should read that first :) I do bzr bd && bzr bd -S followed by some pbuilder commands. Look at .bzr-builder/ in each packaging branch. > Another question I have is around version numbers. Currently we're > using version numbers like 0.2-0ubuntu0~zyga1. I don't really see why > the "zyga" is in there :) I think simply dropping the zyga and using > versions like 0.2-0ubuntu0~1 would be fine, or if we want to know who > uploaded a particular version we can use things like > 0.2-0ubuntu0~2mwhudson. In short: ~zygaN is the thing we can increment. We should KEEP and perhaps change the name to ~lava (but this has to be coordinated as ~lava < ~zyga. There are three possible scenarios which this system correctly handles: 1) We need a new release, the pattern is always the same: ${UPSTREAM}-0ubuntu0~${PACKAGE}${PACKAGE_VERSION} Where PACKAGE is the marker (currently zyga) and PACKAGE_VERSION is reset to 0 each time UPSTREAM changes. 2) Our packages land in Ubuntu. The version becomes: ${UPSTREAM}-0ubuntu${PACKAGE_VERSION} Where PACKAGE_VERSION is >= 1 (this is important to differentiate from all of our internal releases 3) Our packages land in Debian. The version in Debian becomes: ${UPSTREAM}-${PACKAGE_VERSION} The version in Ubuntu becomes/changes to: ${UPSTREAM}-${PACKAGE_VERSION}ubuntu${UBUNTU_PACKAGE_VERSION} Where PACKAGE_VERSION is the one from Debian and UBUNTU_PACKAGE_VERSION is something Ubuntu developers can increment. > > Finally, I think that we should be triggerhappy about releases, and so > going through the above process shouldn't take very long. I guess > lava-dev-tool can help here. Agreed. I will look at this problem this week, hopefully I'll resurrect the package builder code. Thanks ZK

13 years, 3 months

better libjpeg-turbo 1.1.1 perf numbers

by Tom Gall

Hi All, I put some timestamp code into the compress and decompress testcases that I had posted about last friday for libjpeg-turbo. I have new and much better performance numbers as a result. In addition, I've put together a simple wiki page to capture various libjpeg-turbo kinds of things. https://wiki.linaro.org/TomGall/LibJpegTurbo >From the table there is an improvement in the libjpeg-turbo-1.1.1+patches from libjpeg62 of approx 30-40% in the decode case. In the encode case there are improvements from 6 to 17% however with larger images a regression is noted. -- 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, 3 months

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev July 2011