Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will
encounter a problem that bootanimation shows endless. It results from
the mis-optimization in libgui, which handles the operations in
Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk
+++ b/libs/gui/Android.mk
@@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
+
ifeq ($(TARGET_SIMULATOR),true)
LOCAL_LDLIBS += -lpthread
endif
Then, replace /system/lib/libgui.so with the newer one.
I didn't look into the details. But at least, Android is able to
serve user interaction again.
Related bug:
https://bugs.launchpad.net/linaro-android/+bug/787072
Sincerely,
-jserv
[1] Prebuilt x86 toolchain for Android:
http://people.linaro.org/~jserv/toolchain/
=== Highlights ===
* Gave Android Public Plan Review
* Interviewed and reviewed potential new Android hires
* Attended and participated in the Multimedia WG Mini-Summit in Austin
* Gave LT SoW input
=== Plans ===
* Package and distribute the Panda Android LEB on GCC 4.5
* Help debug Panda Android LEB on GCC 4.6 issues
* Start-up weekly Android/LT/WG meetings
* Interview
=== Issues ===
* jstultz + the landing team kernel on Panda
Meeting minutes in https://wiki.linaro.org/OfficeofCTO/2011-06-07
== Summary ==
* Setup for August sprint in discussion
* status.linaro.org fixed for Octo, but not everything shows up (eg LLVM
was not showing due to missig series target for TR, fixed now)
* ARMHF:
* weekly sync for HF setup
* Fixing a lot of bugs, still too many to go
* Gnome 2.3 desktop running the efika
* Cross build - started looking into LSB
* Boot architecture:
* Document writing: overview of the model that Linux uses for device
tree plus a guide for implementors porting a platform to use device tree
* Boot architecture - start collecting data about what we care about
* Server:
* Canonical Ubuntu Platform sprint in Dublin - Loic going to liase
with the server people - week of 27th June
* xen.org? Met with Lars Kurth,
* Discussion on OpenMax, ready for the multimedia working group
BR,
--
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
Dear Jim,
After changing TARGET_TOOLS_PREFIX in
build/core/combo/TARGET_linux-arm.mk to
android-toolchain-eabi-4.5-2011.05, then source build/envsetup.sh. go
to dalvik/vm dir by:
cd dalvik/vm
compile dalvik in this dir:
mm -B
we will find many compiling error like: "break strict-aliasing rules",
"used uninitialized in this function" and so on. all those actually
are warnings which become errors due to -Werror option. A patch like
the below can make compiling pass, but we feel strange why old
toolchain has no this issue.
Index: Dvm.mk
===================================================================
--- Dvm.mk (revision 4149)
+++ Dvm.mk (working copy)
@@ -26,7 +26,8 @@
#
LOCAL_CFLAGS += -fstrict-aliasing -Wstrict-aliasing=2 -fno-align-jumps
#LOCAL_CFLAGS += -DUSE_INDIRECT_REF
-LOCAL_CFLAGS += -Wall -Wextra -Wno-unused-parameter
+#LOCAL_CFLAGS += -Wall -Wextra -Wno-unused-parameter
+LOCAL_CFLAGS += -Wextra -Wno-unused-parameter
LOCAL_CFLAGS += -DARCH_VARIANT=\"$(dvm_arch_variant)\"
#
@@ -264,7 +265,7 @@
ifeq ($(dvm_arch),arm)
#dvm_arch_variant := armv7-a
#LOCAL_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfp
- LOCAL_CFLAGS += -Werror
+# LOCAL_CFLAGS += -Werror
MTERP_ARCH_KNOWN := true
# Select architecture-specific sources (armv4t, armv5te etc.)
LOCAL_SRC_FILES += \
Any configuration error from us?
Thanks
Barry
There is a packaged kernel work in progress here:
http://git.linaro.org/gitweb?p=ubuntu/linux-linaro-oneiric.git;a=summarygit://git.linaro.org/ubuntu/linux-linaro-oneiric.git
It is based on a snapshot of linux-linaro-2.6.39 from today plus sauce
and packaging from Ubuntu-2.6.39-3.10.
The bad news is that this kernel does not even boot for me. As I
chase that down I would like feedback on the new configs. They are
dramatically reduced compared to the last cycle. I created the new
configs by starting with the upstream defconfigs for each soc and then
added only what was necessary to satisfy the Ubuntu config enforce
script.
This is the perfect time in the release process to start over with
minimal configs since we have time deal with missing options. So
please look at the configs and let me know what else should be turned
on.
The packaged kernel has configs split across multiple files. Which is
a little confusing. Here is a synopsis:
./debian_linaro/config/config.common.ubuntu is the part that is common
across all arch's and flavours (socs).
./debian_linaro/config/armel/config.common.armel has stuff common
across all armel flavours but since we only have armel then this file
is empty with all the common stuff propagating up to
config.common.ubuntu.
./debian/linaro/config/armel/config.flavour.linaro-* contain the soc
specific stuff.
Any input appreciated. One obvious thing I have noticed is that the
soc specific options differ in non-soc specific ways that could be
made consistent. For example lots of CONFIG_CRYPTO options are not
set in mx51 but m or y in omap. As you see these please give your
opinion on if all plats should make an these y, m or n.
Thanks,
John
As you may have noticed in a recent email thread, the validation team is in
the process of making some structural changes to the LAVA project. For
finding all the projects for Linaro Validation that we are working on, the
easiest option is to go to the main LAVA project group page [1] on
Launchpad, which links to each of them.
The last project name change should happen today, and that will be the
rename of abrek to lava-test. What this means, is that if you currently
pull abrek for use in any other test framework, it will need to be fixed to
pull lp:lava-test instead. We will make sure this change is reflected in
lava-dispatcher so that there are no interruptions in daily tests that are
running in the validation farm. However, if you are running your own
dispatcher you will want to update your installation with the update, which
should land in the next 24 hours once the rename of abrek is complete.
Thanks,
Paul Larson
[1] http://launchpad.net/lava
Hello there,
This week I initiated a confused conversation during the techleads
call about having a way to describe what the hardware pack was built
from. We had a couple of false starts but I think we agreeing that there
needs to be some form of manifest that describes what the hardware pack
contains.
I seem to be hung up on having a way of saying "this hardware pack's
kernel was built from this git tree with this config", so I wanted to
explore the use cases a bit more:
- My #1 use case is, once I've installed a hardware pack, running
into a problem and then being able to verify whether it contains a
certain patch or was built with a certain config option. I'd like
to know that because it's the first thing the KWG and LT people
ask me when I go to report the bug.
- I think there's also a use case of wanting to know how to get that
hwpack rebuilt with slightly updated kernel code or configs. If
it's much easier to just document how to build and replace a
kernel for a running image, that may cater for most of that use
case, the exception being weird bugs caused by our build process
and/or toolchain.
- I wonder if there's a use case for understanding and/or replacing
the other contents of the hardware pack. I normally think of the
hardware pack as "a built kernel and not much else" XXX.
Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm
not sure I understand enough about it (Loïc's provided a sample file at
http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my
strawman proposal of what data we should give people quick access to:
- What kernel tree it was built from
(A URL to the git tree)
- What revision
(A revision ID)
- What patches were applied on top of it
(A URL to the patchset, maybe?)
- What kernel config was used to build it
(A separate file in the hwpack directory?)
How does that sound? Too simplistic?
--
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko
