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.
== 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
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
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
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/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
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
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
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
