During ELC a few people asked me if Linaro had something bigger than
nano and smaller than Ubuntu that they could use to build stuff. Of
course I said Android, but a lot of people actually want a regular
Linux platform where they can easily recompile what they need to hack
on, add their own libs and scripts and generally work in an "embedded,
cross build way." I know there's OpenEmbedded and I've heard of
something called "livebuild." Does anyone have anymore info? This
class of users is arguably the largest class of people using these
boards so creating something targeted at them would allow them to get
all the benefits of Linaro in a easy to use fashion.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
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
So our current naming scheme is awful.
staging-
landing-
tracking-
ick ick ick
We'd like to make this better, here's the idea:
old
new
staging-vexpress-a9
ics-armlt-stable-gcc46-vexpress-a9
tracking-panda
ics-tilt-tracking-gcc46-panda
aosp-panda
ics-aosp-stable-gcc44-panda
staging-imx53
ics-freescalelt-stable-gcc46-imx53
panda-4.4
ics-tilt-upstream-gcc46-panda
landing-snowball
ics-igloo-stable-gcc46-panda
landing-panda
ics-omapzoom-stable-gcc46-panda, keep
staging-panda
ics-tilt-stable-gcc46-panda
staging-origen
ics-samsunglt-stable-gcc46-origen
panda
ics-kwg-upstream-gcc46-panda
panda-4.4
ics-aosp-stable-gcc44-panda
Its basically,
<type of Android>-<kernel source>-<kernel type>-<toolchain version>-<target>
Hopefully this will allow people to figure out what's what.
Comments, questions, concerns?
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
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 Bernhard
I added support for device trees in this commit:
http://review.android.git.linaro.org/#change,1359
Is there any reason iMX6 can't make use of this rather than having a
custom make recipe in tasks/kernel.mk? I believe that iMX6 just needs to
add the following line to its BoardConfig.mk ...
DEVICE_TREES := imx6q-sabrelite:board.dtb
--
Tixy
Hello,
One of the issues with https://android-build.linaro.org/ is that, if
build fails, it's not easy to tell if it happened because of
compilation error ("real" failure) or due to non-deterministic error
with setting up infrastructure for build (e.g. during source checkout).
The latter not so uncommon due to vast source size of Android and
complexity of cloud infrastructure.
This became especially problematic with start of automated CI loop,
where it leads to false negatives when doing pre-merge testing.
Improving this situation was subject of few blueprints in which
Infrastructure team worked, and recently, a solution was deployed. With
it, if a build fails due to non-deterministic infrastructure error, it
will get status of "NOT BUILT", meaning that a build never actually got
to compilation phase. Suggested action in such case is to retry.
Please note that Jenkins there is some inconsistency within the Jenkins
itself regarding NOT BUILT status - "Pending" is used as a display name
in places, and the same gray icon used as for ABORTED builds. So,
please keep that in mind, or yet better use Build Frontend.
Unfortunately, even short weekend testing showed that error separation
achieved is not ideal (folks who participated in Connect Q4.11
session dedicated to this, may remember that I said that it would
take adding AI to do that properly ;-) ).
In particular, if there was an issue with manifest file (essentially,
an error in Android source code), it will be reported as NOT BUILT
instead of FAILED. Here's example of such build:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc44…
Opposite miscategorization may also happen: very early infra error may
be reported as FAILED instead of NOT BUILT. Example:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc46…
So, Infrastructure team will continue to work on improving reliability
of builds, but in the meantime please keep looking in the build logs for
actual cause of the failure (feel free to report unexpected build
status to https://bugs.launchpad.net/linaro-android-infrastructure)
--
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
Just did an MX6 build with skia and agl built with -ftree-parallelize-loops=4
The results are not very encouraging - visible tearing got worse, and
0xbench 3D results improve by merely 1.5%. (This was done with the 4.7
toolchain, given -ftree-parallelize-loops should be slightly more
effective there).
Either gcc's support for it just isn't where we want it yet, or
skia/agl code is simply not using any bits that could be parallelized
meaningfully.
Let's see how it goes with other parts of the tree...
ttyl
bero