Re: gold generate broken sysv-style hash table when --hash-style=both

2012-01-17 Thread Jim Huang
2012/1/17 Kito Cheng k...@0xlab.org:
 Recently we are make the dynamic linker support GNU-style hash, but
 for the compatible reason we build android with  -Wl,--hash-style=both
 instead of -Wl,--hash-style=gnu.

Thank Kito's observation.

The change was applied in cyanogenmod:
http://review.cyanogenmod.com/#change,11448

inker: Support GNU-style hash to speed up symbol lookup

Since 2006, GNU toolchain developers added a new style of hash section to
ELF with better performance than the original SysV hash.

GNU hash function uses the DJB (Daniel J Bernstein) hash, which has much
fewer symbol conflicts than SysV hash.

GNU hash sections include a Bloom filter, which is used to rapidly reject
symbol names that will not be found in the object, avoiding the more
expensive hash lookup operation. Normally, only one object in a process
has the given symbol. Skipping the hash operation for all the other objects
can greatly speed symbol lookup.

 And then we discover this bug in gold, gold generate broken sysv-style
 hash table when --hash-style=both, we already file a bug to bugzilla
 for bintuils[1].

 [1] http://sourceware.org/bugzilla/show_bug.cgi?id=13597

For some Android applications such as Mozilla (Android version) and
the games utilizing Unity3D,
they come with their own dynamic linker derived from bionic linker,
which only supports SysV hash.
Therefore, Kito added --hash-style=both to build rules.  However, he
found new problem resulting
from gold linker shipped in Android ICS toolchain.

Can any toolchain hacker take a look at this issue?

Thanks,
Jim Huang (jserv)
http://0xlab.org/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: ANN: 0xbench, integrated Android benchmark suite

2011-11-06 Thread Jim Huang
Hello list,

Recently, we already released 0xbench version 1.1.5, and you can get
the latest binary/source here:
http://code.google.com/p/0xbench/downloads/list
http://gitorious.org/0xbench

Changes since version 1.1.1:
- Add SunSpider JavaScript benchmark
- Allow customized result output path
- Support dashboard bundle format used in Linaro Automated Validation
Architecture
- Enable detailed report of libmicro and UnixBench
- Android 2.3+ build fixes

Also, you can install 0xbench on your Android devices through Android Market.

NOTE: due to the expiration of previous key for Android Market, we
have to rename the package and then upload to Marketplace again.
Therefore, the package namespace is now changed from
org.zeroxlab.benchmark to org.zeroxlab.zeroxbenchmark.  We feel sorry
for inconvenience.

The next version will be 1.2.x, and glmark2 [*] is known to be part of
test cases.

Sincerely,
Jim Huang (jserv)
http://0xlab.org/

[*] https://launchpad.net/glmark2

2010/8/18 Jim Huang js...@0xlab.org:
 Hello list,

 We are proud to announce the release of 0xBench, an open source
 Android benchmarking app developed by 0xlab.

 0xBench comes with several built-in benchmarks, such as Linpack,
 Scimark2, and LibMicro.  0xBench itself could be extended as well.
 Developers can add their own benchmarks (either in native C or Java)
 to suit their needs.  Please check the project page for details:
   http://code.google.com/p/0xbench/

 Documentation in Wiki: http://code.google.com/p/0xbench/w/list

 As usual, 0xBench GIT repository is hosted in Gitorious:
   http://gitorious.org/0xbench/

 0xBench is now on the Android Market. If you wish to try it on your
 phone,  please search for “0xBench” in the Market.  In addition to
 0xBench, we are also introducing a website called 0xBenchWeb, a simple
 web service that stores and visualizes your benchmarking results.
 After finish running benchmarks on your phone, you can choose to
 upload your results to 0xBenchWeb.
   http://0xbenchmark.appspot.com/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: auxv + neon

2011-09-03 Thread Jim Huang
2011/9/3 Tom Gall tom.g...@linaro.org:
 Is a method via the aux vectors to know at runtime if neon is or is
 not present?

hi Tom,

Did you mean this?
https://bugs.meego.com/show_bug.cgi?id=12448

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Fwd: Would you send me your hard float experiment results you presented in Budapest?

2011-09-03 Thread Jim Huang
2011/9/3 Christian Robottom Reis k...@linaro.org:
 On Tue, Aug 30, 2011 at 11:24:59AM -0500, Zach Pfeffer wrote:
 I'd like you to meet Jim who did the initial hardfloat work. This
 email contains the results that Jim produced.

 Hmm, but the email seems to not actually contain a hard-float run. Or am
 I misreading what he means by Fixed vs VFP?

hi kiko,

In fact, the presentation was incomplete.  That is exactly the reason
why I didn't want to make it public.

The original plans were as following:
 - Analyze skia and webkit for soft/hard-fp
 - Select fixed-point, soft-vfp, and hard-fp implementations in skia
and then check the benchmark results.

However, I didn't make all benchmark results ready when I built with
hard-fp.  I didn't know why and stopped the study due to personal
reasons. (sorry for being absent)

 I believe that the conclusion was that skia and webkit may benefit,
 but that such benefits would impose an undue burden on Android's
 distribution model which tries to create libs that can run on as many
 architectures as possible.

 You may be confusing things here. Hard-float is a pure software ABI
 change, and any platform which supports VFP can use it if you build it
 that way. However, since it is an ABI change it requires that hard-float
 libraries be available.

Yes, since ABI has to be changed, we have to confirm the modifications
against existing components:
 - dalvik fast-interpreter and jitter
 - v8 compiler/evaluator
 - android software OpenGL|ES renderer

Again, please don't be too serious about my incomplete materials.
I didn't have enough time to analyze that time.

 What /would/ stop code from running on certain platforms is using
 NEON (it would exclude the Tegra2 and some existing Marvell v7s). But
 that doesn't seem to be in question here.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


ANN: ASTER - Android System Testing Environment and Runtime

2011-08-25 Thread Jim Huang
Hello list,

0xlab announced the new system testing utility for Android.

-- Forwarded message --
From: Kan-Ru Chen ka...@0xlab.org
Date: 2011/8/24
Subject: [0xlab-discuss] [ANN] ASTER System Testing Environment and Runtime
To: 0xlab-disc...@googlegroups.com


Hi everyone,

I am glad to announce our new project, ASTER System Testing Environment
and Runtime, an automated functional testing tool. This is a tool aimed
for testers, it includes an easy to use IDE for generating UI test cases
and a script runner for batch running test cases. The tool is built upon
the concept of Sikuli desktop automation tool and the Android monkey
runner engine.

We gave a talk at COSCUP[1] introducing this project and demonstrated
the capability of the tool. You can grab the slides from here[2]. The
project page is here[3] and you can also download the prebuilt preview
binary at the download page[4]. The documentation is currently lacking
but I hope the IDE is simple enough for everyone to figure out how to
use it. In the other hand you always can checkout the source code and
explore the underlying implementation.

[1]: http://coscup.org/2011/en/
[2]: http://0xlab.org/~kanru/COSCUP_aster.svg
[3]: https://code.google.com/p/aster
[4]: https://code.google.com/p/aster/downloads/list

Cheers,
--
http://0xlab.org
Kanru

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Input for an optimized slide

2011-08-22 Thread Jim Huang
2011/8/22 Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org:
 On 21 August 2011 15:00, Michael Hope michael.h...@linaro.org wrote:
 Sorry, silly question, but does Android use the glibc dynamic linker?

 No, they really like reinventing the wheel. Bionic comes with its own
 dynamic linker.

hi Bernhard and Michael,

The dynamic linker is file /system/bin/linker.

 If not, does its linker support other hash styles?

 It looks like it supports both the sysv and gnu styles. It uses libelf
 to do most of its ELF parsing, and libelf seems to do the right thing.

I don't think so.  Since Android uses the libelfcopy[2], derived from
some really old parts in binutils, providing the
facilities about DWARF/ELF, we would need extra modifications like the
attached patch.[*]

Also, bionic linker changes are required.  Another attachment contains
the 0xlab internal modifications.

Sincerely,
-jserv

[*] The related patches are expected to be submitted to AOSP Gerrit recently.
From 71f965b55ffaaa0853e60be2e8b97daf95544712 Mon Sep 17 00:00:00 2001
From: Kito Cheng k...@0xlab.org
Date: Fri, 12 Aug 2011 00:55:37 +0800
Subject: [PATCH] Basic GNU-style hash support for elfcopy

---
 elfcopy.c |   17 +++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/elfcopy.c b/elfcopy.c
index ed1e6ce..cac10ea 100644
--- a/elfcopy.c
+++ b/elfcopy.c
@@ -34,6 +34,16 @@
 */
 #define ELF_STRPTR_IS_BROKEN (1)
 
+/* Compatible for older elfutils.
+   elfutils support gnu-style hash since version 0.122
+*/
+#ifndef DT_GNU_HASH
+#define DT_GNU_HASH 0x6ef5
+#endif
+#ifndef SHT_GNU_HASH
+#define SHT_GNU_HASH 0x6ff6
+#endif
+
 static void update_relocations_section_symbol_references(Elf *newelf, Elf *elf,
  shdr_info_t *info, int info_len,
  shdr_info_t *relsect_info,
@@ -744,7 +754,6 @@ void adjust_elf(Elf *elf, const char *elf_name,
 
 FAILIF(shdr_info[cnt].shdr.sh_entsize != sizeof (Elf32_Word),
Can't handle 64-bit ELF files!\n);
-
 update_hash_table(newelf,  /* new ELF */
   elf, /* old ELF */
   shdr_info[cnt].idx, /* hash table index */
@@ -846,7 +855,9 @@ void adjust_elf(Elf *elf, const char *elf_name,
 } /* for each symbol... */
 }
 }
-
+/* We don't support update gnu-style hash table now! */
+FAILIF(shdr_info[cnt].shdr.sh_type == SHT_GNU_HASH,
+   Can't handle SHT_GNU_HASH!\n);
 FAILIF(shdr_info[cnt].shdr.sh_type == SHT_GNU_versym,
Can't handle SHT_GNU_versym!\n);
 FAILIF(shdr_info[cnt].shdr.sh_type == SHT_GROUP,
@@ -1933,6 +1944,7 @@ static void adjust_dynamic_segment_offsets(Elf *elf, Ebl *oldebl,
 
 case DT_PLTGOT:
 case DT_HASH:
+case DT_GNU_HASH:
 case DT_SYMTAB:
 (void)update_dyn_entry_address(elf, dyn, shdr_info, shdr_info_len);
 break;
@@ -2582,6 +2594,7 @@ static int get_end_of_range(shdr_info_t *shdr_info,
 (shdr_info[end].shdr.sh_type == SHT_INIT_ARRAY) ||
 (shdr_info[end].shdr.sh_type == SHT_FINI_ARRAY) ||
 (shdr_info[end].shdr.sh_type == SHT_PREINIT_ARRAY) ||
+(shdr_info[end].shdr.sh_type == SHT_GNU_HASH) ||
  /* (shdr_info[end].shdr.sh_type == SHT_NOBITS) || */
 #ifdef ARM_SPECIFIC_HACKS
 /* SHF_ALLOC sections with with names starting with .ARM. are
-- 
1.7.5.4

From 5bf2ca212750d3dadac96de0bfd4d621abbb0dea Mon Sep 17 00:00:00 2001
From: Kito Cheng k...@0xlab.org
Date: Fri, 12 Aug 2011 00:49:57 +0800
Subject: [PATCH] GNU-style hash support for linker

---
 linker/linker.c   |  116 ++---
 linker/linker.h   |7 +++
 linker/linker_debug.h |   17 +++
 3 files changed, 133 insertions(+), 7 deletions(-)

diff --git a/linker/linker.c b/linker/linker.c
index bb31703..d5fc459 100644
--- a/linker/linker.c
+++ b/linker/linker.c
@@ -62,6 +62,13 @@
 #define LDPRELOAD_BUFSIZE 512
 #define LDPRELOAD_MAX 8
 
+/* Compatible for older elfutils.
+   elfutils support gnu-style hash since version 0.122
+*/
+#ifndef DT_GNU_HASH
+#define DT_GNU_HASH	0x6ef5  /* address of gnu-style symbol hash table */
+#endif
+
 /*  IMPORTANT NOTE - READ ME BEFORE MODIFYING 
  *
  * Do NOT use malloc() and friends or pthread_*() code here.
@@ -399,6 +406,54 @@ dl_iterate_phdr(int (*cb)(struct dl_phdr_info *info, size_t size, void *data),
 }
 #endif
 
+static Elf32_Sym *_gnu_lookup(soinfo *si, unsigned gnu_hash, const char *name)
+{
+Elf32_Sym *s;
+Elf32_Sym *symtab = si-symtab;
+const char *strtab = si-strtab;
+int elfclass = 32;
+Elf32_Word bitmask_word = si-gnu_bitmask[(gnu_hash / elfclass)
+   

Re: Ethernet configuration

2011-08-17 Thread Jim Huang
2011/8/17 Frans Gifford frans.giff...@linaro.org:
 Hi Mathieu,

 I think 0xdroid has ethernet support (I'm sure jserv could confirm).
 Did Movial get it from there?

hi Frans and Mathieu,

I think both Movial and 0xdroid have similar Ethernet implementations
since android-x86 project originally contributed it to public.

However, I just wonder if LEB does need Ethernet setting UI and
framework changes.  They are indeed large piece of modifications, and
AOSP already rejected these.

Just my two cents.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: 3D Demo at ARM

2011-08-13 Thread Jim Huang
2011/8/11 Zach Pfeffer zach.pfef...@linaro.org:
 Ramin,

 Thanks for the email. I've added linaro-dev to my response.

hi Ramin and Zach,

 The demo consisted of two identical PandaBoards with identical SD
 cards running the 3D benchmark of 0xbench using software 3D to amplify
 compiler and kernel improvements. 0xbench is a benchmarking program we
 ship with our Android images from 0xlab.
[...]

For more information, please check the wiki:
http://code.google.com/p/0xbench/wiki/Benchmarks

Recently, we even added JavaScript benchmark.  And, every piece of
0xbench is licensed in the form of open source:
http://gitorious.org/0xbench

We are considering to integrate existing OpenGL|ES benchmark tests
such as glmark2:
https://launchpad.net/glmark2

Sincerely,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: What are the chances of a phone based developer image

2011-08-10 Thread Jim Huang
2011/8/10 Ramana Radhakrishnan ramana.radhakrish...@linaro.org:
 . Would you be interested in adding a Firefox-based benchmark? As a large
 application it is a good testbed for LTO, FDO and other aggressive
 optimizations.

 I would be interested in hearing how you get on with LTO and FDO on
 ARM. Listening to Honza talking at the GCC unconference in London
 about the memory usage for full LTO with trunk I did wonder what would
 happen if we tried it on the ARM target to see what we got, but I
 never managed to get around to trying anything there :) . We did look
 at getting FDO working with Linaro GCC last cycle but there are still
 a couple of issues with PGO in Linaro GCC 4.5.

FYI.
The toolchain benchmark suite derived from Google already includes the
FDO mode, and I would suggest to enable it for comparisons.

Android build system has (incomplete) FDO integration since Android
2.2[*].  In my experience, it sometimes helps the performance for
special cases slightly.

Sincerely,
-jserv

[*] The build system would perform build-run-build scheme with the
help of ADB, which deploys the profiler on target.
Option: BUILD_FDO_INSTRUMENT

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: FYI: Linaro Validation showcase video at Computex 2011

2011-06-27 Thread Jim Huang
On 24 June 2011 13:17, Paul Larson paul.lar...@linaro.org wrote:
 Neat!  Any feedback from those who saw it?


hi Paul,

Yes, we got many feedback and inputs while presenting LAVA and
corresponding Android platform support.

I think most visitors agreed with the idea and importance of LAVA, but
it is a bit hard for some of them to Imagine how (and why) various
steps are necessary to perform ordinary concepts such as Built in the
cloud - Deploy Linaro Evaluation Build images into target - Execute
system benchmark - Collect results and visualize in somewhere.

The reason why I attempted to write Gtk+ front-end is simplifying
the details of the showcase and even making it visualized for LAVA.
By the way, thank Validation team to bring it to the world. :)

Sincerely,
-jserv

 On Fri, Jun 24, 2011 at 12:00 AM, Jim Huang jim.hu...@linaro.org wrote:
 During the first week of June, we prepared the technical showcase[1]
 about Linaro powered devices and projects including LAVA[1].

 To emphasize how LAVA works, we just uploaded another demo video:
    http://www.youtube.com/watch?v=_3dT68MOzz0
 It starts at 2:27.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH android/bionic] strftime: Use snprintf() instead of sprintf()

2011-06-23 Thread Jim Huang
Merged in AOSP:

http://android.git.kernel.org/?p=platform/bionic.git;a=commitdiff;h=e6cff939e603e445c2576958c3777d7b7f5d84fa

On 22 June 2011 16:48, Jim Huang jim.hu...@linaro.org wrote:
 Code Review:
    https://review.source.android.com/#change,23997

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


FYI: Linaro Validation showcase video at Computex 2011

2011-06-23 Thread Jim Huang
Hello list,

During the first week of June, we prepared the technical showcase[1]
about Linaro powered devices and projects including LAVA[1].

To emphasize how LAVA works, we just uploaded another demo video:
http://www.youtube.com/watch?v=_3dT68MOzz0

It starts at 2:27.

Sincerely,
-jserv

[1] The overview video: ARM at Computex 2011 with Linaro
http://www.youtube.com/user/ARMflix#p/a/9ABC7CFA0491638F/0/9RzbAt27qic
[2] https://wiki.linaro.org/Platform/Validation/LAVA

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH android/toolchain/build] Fix host-libbfd installation problem caused by undefined $(INSTALL)

2011-06-22 Thread Jim Huang
Merged in AOSP:

http://android.git.kernel.org/?p=toolchain/build.git;a=commit;h=7ee395d10100fc9ed2c03c49b949033600082a4f

On 27 May 2011 01:29, Jim Huang jim.hu...@linaro.org wrote:
 While executing target install-host-libbfd, the build system complains:

 make -C libbfd-binutils-2.20.1/bfd install \
 bfdlibdir=/tmp/android-toolchain-eabi/lib
 bfdincludedir=/tmp/android-toolchain-eabi/include  \ -m 644
 libbfd-binutils-2.20.1/intl/libintl.a \ /tmp/android-toolchain-eabi/lib
  \ -m 644 libbfd-binutils-2.20.1/libiberty/libiberty.a \
 /tmp/android-toolchain-eabi/lib

 /bin/sh: line 2: -m: command not found

 The problem was caused by undefined $(INSTALL). The patch attempts to
 configure `install' program by autotool in order to set $(INSTALL)
 properly and replace $(INSTALL) -m 644 with multi-platform friendly
 $(INSTALL_DATA).

 Code Review:
    https://review.source.android.com/#change,23179

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/bionic] strftime: Use snprintf() instead of sprintf()

2011-06-22 Thread Jim Huang
Code Review:
https://review.source.android.com/#change,23997
From afd989ca9f3415df9807847745e854522866f66f Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Thu, 16 Jun 2011 22:35:16 +0800
Subject: [PATCH 1/2] strftime: Use snprintf() instead of sprintf()

Change-Id: I112ac012894eddc96e5f3e77cb87bb300596e3ce
---
 libc/tzcode/strftime.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libc/tzcode/strftime.c b/libc/tzcode/strftime.c
index ab713fb..d35d58a 100644
--- a/libc/tzcode/strftime.c
+++ b/libc/tzcode/strftime.c
@@ -407,9 +407,9 @@ label:
 tm = *t;
 mkt = mktime64(tm);
 if (TYPE_SIGNED(time64_t))
-(void) sprintf(buf, %lld,
+(void) snprintf(buf, %lld, sizeof(buf),
 (long long) mkt);
-else(void) sprintf(buf, %llu,
+else(void) snprintf(buf, %llu, sizeof(buf),
 (unsigned long long) mkt);
 pt = _add(buf, pt, ptlim, modifier);
 }
-- 
1.7.5.4

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/bionic] time: Improve C99 compliance

2011-06-22 Thread Jim Huang
Quote from Linux Programmer's Manual:
If t is non-NULL, the return value is also stored in the memory
pointed to by t.

Code Review:
https://review.source.android.com/#change,23998
From 30a19b9cdbe509d62c7d4c5df9a6daab13ff8857 Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Thu, 16 Jun 2011 22:40:10 +0800
Subject: [PATCH 2/2] time: Improve C99 compliance

Quote from Linux Programmer's Manual:
  If t is non-NULL, the return value is also stored in the memory
   pointed to by t.

Change-Id: I8cb66b67e5f34c536ce2f0db76a6dc337c42ea3f
---
 libc/unistd/time.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/libc/unistd/time.c b/libc/unistd/time.c
index 13d7366..7b450c7 100644
--- a/libc/unistd/time.c
+++ b/libc/unistd/time.c
@@ -34,12 +34,15 @@ time_t
 time(time_t *t)
 {
 	struct timeval tt;
+	time_t ret;
 
 	if (gettimeofday(tt, (struct timezone *)0)  0)
-		return (-1);
-	if (t)
-		*t = (time_t)tt.tv_sec;
-	return (tt.tv_sec);
+		ret = -1;
+	else
+		ret = tt.tv_sec;
+	if (t != NULL)
+		*t = ret;
+	return ret;
 }
 
 
-- 
1.7.5.4

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Clarify Licensing terms of build/tools/{isprelinked,soslim,apriori} in Android source tree

2011-06-22 Thread Jim Huang
Hello list,

I am not sure if android-platform@ is the right place to discuss
licensing terms in Android or not.  Please ignore the post if it was
mistaken.

Recently, we at Linaro are trying to integrate gcc-linaro[1] into
Android build system as the optional toolchain optimized for latest
ARM cores.  We encounter some unknown prelinker issues, and it is an
opportunities for us to look into the implementations of relevant
utilities in Android.  However, I am a bit confused about the
licensing terms of some packages.

libelfcopy[2], derived from some parts in binutils, provides the
facilities about DWARF/ELF, and it is quite obvious that libelfcopy is
licensed under GNU GPL version 2+ as the file MODULE_LICENSE_GPL
denotes.  There are three system tools depending on libelfcopy:
  - isprelinked
  - soslim
  - apriori

build/tools$ grep -r libelfcopy *
apriori/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl #dl
isprelinked/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf
libebl libebl_arm #dl
soslim/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl
libebl_arm #dl

These tools are linking libelfcopy statically, which explicitly
complies with the licensing terms of GNU GPL.  But, after checking the
source files (*.[ch]), no license term is claimed.[3]  The proper
declaration should put file MODULE_LICENSE_GPL into individual
directories at least.

Is my understanding correct?

Sincerely,
Jim Huang
Android Team, Linaro

[1] https://launchpad.net/gcc-linaro
[2] http://android.git.kernel.org/?p=platform/external/elfcopy.git;a=summary
[3] http://android.git.kernel.org/?p=platform/build.git;a=summary

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH] OMAPFB: Reset framebuffer after resume

2011-06-13 Thread Jim Huang
On 9 June 2011 17:58, Kan-Ru Chen ka...@0xlab.org wrote:
 After resume the HDMI/DVI output was still blank. It turns out that
 framebuffers have to be reconfigured so the output is activated again.


Hi Andy,

Can you review Kan-Ru's patch?  Since Android assumes full-functional
PM, it is vital to improve the resuming behavior of OMAP framebuffer.

Thanks,
-jserv

 ---
  drivers/video/omap2/omapfb/omapfb-main.c |   33 
 ++
  1 files changed, 33 insertions(+), 0 deletions(-)

 diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
 b/drivers/video/omap2/omapfb/omapfb-main.c
 index 2bd90ca..a5a0725 100644
 --- a/drivers/video/omap2/omapfb/omapfb-main.c
 +++ b/drivers/video/omap2/omapfb/omapfb-main.c
 @@ -30,6 +30,7 @@
  #include linux/platform_device.h
  #include linux/omapfb.h
  #include linux/console.h
 +#include linux/pm.h

  #include plat/display.h
  #include plat/vram.h
 @@ -2274,6 +2275,37 @@ static int omapfb_parse_def_modes(struct 
 omapfb2_device *fbdev)
        return r;
  }

 +#ifdef CONFIG_PM
 +static int omapfb_suspend(struct device *dev)
 +{
 +       return 0;
 +}
 +
 +static int omapfb_resume(struct device *dev)
 +{
 +       struct platform_device *pdev = to_platform_device(dev);
 +       struct omapfb2_device *fbdev = platform_get_drvdata(pdev);
 +       int i;
 +
 +       if (fbdev != NULL) {
 +               for (i = 0; i  fbdev-num_fbs; i++) {
 +                       omapfb_set_par(fbdev-fbs[i]);
 +               }
 +       }
 +       return 0;
 +}
 +#else
 +#define omapfb_suspend NULL
 +#define omapfb_resume  NULL
 +#endif
 +
 +static const struct dev_pm_ops omapfb_pm_ops = {
 +       .suspend        = omapfb_suspend,
 +       .resume         = omapfb_resume,
 +       .poweroff       = omapfb_suspend,
 +       .restore        = omapfb_resume,
 +};
 +
  static int omapfb_probe(struct platform_device *pdev)
  {
        struct omapfb2_device *fbdev = NULL;
 @@ -2440,6 +2472,7 @@ static struct platform_driver omapfb_driver = {
        .driver         = {
                .name   = omapfb,
                .owner  = THIS_MODULE,
 +               .pm     = omapfb_pm_ops,
        },
  };

 --
 1.7.5.3

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)

2011-06-09 Thread Jim Huang
On 10 June 2011 00:08, Ken Werner ken.wer...@linaro.org wrote:
 Hi there,

 I've got an android build system up and running and had a quick look into
 this. When using the gcc-linaro-4.5-2011.05-0 the bootanimation runs forever
 when compiling the libgui.so using -O[s|1|2]. For me it only works when
 disabling all optimizations (-O0). So, I've started with -O0 and tried to
 bisect the various  optimization switches but I didn't fail. Next I've
 started with -O1 and disabled all the optimizations but it didn't pass. So,
 this approach was a dead end. Then I realized that the build system employs
 some sort of a prelinker called apriori. Adding 'LOCAL_PRELINK_MODULE :=
 false' to the makefile disables the prelink step. And the resulting ELF
 binary finally worked (tested with -O[s|1|2]).

hi Ken,

Thanks for your progress in advance.

Disabling prelinking looks fine, and actually SensorService in
master branch disables prelinking as well:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/sensorservice/Android.mk;hb=HEAD

The library libsensorservice is highly related to SensorService, which
is activated by SystemServer, an essential process to bring up Android
framework functionality.

In directory frameworks/base/services, libsensorservice is the only
library which is attributed as non-prelinked.

 It would be good to understand the root cause of this because the workaround
 probably has drawbacks at run (load) time. Apriori gets two input files. The
 prelink-linux-arm.map which lists the start of the prelink addresses:
  libui.so                0xAB90 # [~1M]
  libgui.so               0xAB80 # [~1M]
  libskia.so              0xAB10 # [~2M]
 and the libgui.so to be prelinked. I'd expect to see the resulting
 PhysAddr's somewhere nearby 0xAB80 but this doesn't seem to be the case
 somehow. In order to exclude a miscompiled apriori, I've prelinked libgui
 using an apriori binary build with the prebuilt gcc44 - no difference.
 Therefore I don't think gcc is miscompiling but something went wrong whith
 the prelink step. But still - the android prelinking remains a mystery to me
 as I don't know what is supposed to be prelinked and what is actually
 failing. However, I think we are one step further.

So, can you verify the behavior difference between prelink maps as well?

Cheers,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)

2011-05-27 Thread Jim Huang
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/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/toolchain/build] Fix host-libbfd installation problem caused by undefined $(INSTALL)

2011-05-26 Thread Jim Huang
While executing target install-host-libbfd, the build system complains:

make -C libbfd-binutils-2.20.1/bfd install \
bfdlibdir=/tmp/android-toolchain-eabi/lib
bfdincludedir=/tmp/android-toolchain-eabi/include  \ -m 644
libbfd-binutils-2.20.1/intl/libintl.a \ /tmp/android-toolchain-eabi/lib
 \ -m 644 libbfd-binutils-2.20.1/libiberty/libiberty.a \
/tmp/android-toolchain-eabi/lib

/bin/sh: line 2: -m: command not found

The problem was caused by undefined $(INSTALL). The patch attempts to
configure `install' program by autotool in order to set $(INSTALL)
properly and replace $(INSTALL) -m 644 with multi-platform friendly
$(INSTALL_DATA).

Code Review:
https://review.source.android.com/#change,23179

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [[PATCH Android device/linaro/pandaboard]] Remove init.ompa4.sh

2011-05-23 Thread Jim Huang
On 23 May 2011 16:54, Patrik Ryd patrik@linaro.org wrote:
 The file init.ompa4.sh only contained one line for setting
 ro.runtime.device. This property is not used so the file
 can be removed.

hi Patrik,

Thanks for cleaning up.  It looks great to me.

So, we are going to be more consistent in device/linaro/common and LEB devices.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/device/linaro/common] Add fake touchscreen daemon for LEB to satisfy some Android applications

2011-04-26 Thread Jim Huang
Otherwise, some applications which expect touchscreen device would crash
due to lacking of related resources.

This change is essential to LEB.
---
 tasks/fake-ts/Android.mk |   29 +
 tasks/fake-ts/fake-ts.c  |   76 ++
 2 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 tasks/fake-ts/Android.mk
 create mode 100644 tasks/fake-ts/fake-ts.c

diff --git a/tasks/fake-ts/Android.mk b/tasks/fake-ts/Android.mk
new file mode 100644
index 000..27a9298
--- /dev/null
+++ b/tasks/fake-ts/Android.mk
@@ -0,0 +1,29 @@
+# Copyright (C) 2011 Linaro Ltd.
+#
+# Licensed under the Apache License, Version 2.0 (the License);
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#  http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an AS IS BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+LOCAL_PATH:= $(call my-dir)
+
+ifneq ($(TARGET_SIMULATOR),true)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := faketsd
+LOCAL_MODULE_TAGS := optional
+
+LOCAL_SRC_FILES := fake-ts.c
+LOCAL_PRELINK_MODULE := false
+
+include $(BUILD_EXECUTABLE)
+
+endif # !TARGET_SIMULATOR
diff --git a/tasks/fake-ts/fake-ts.c b/tasks/fake-ts/fake-ts.c
new file mode 100644
index 000..b5ec551
--- /dev/null
+++ b/tasks/fake-ts/fake-ts.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2009 0xlab - http://0xlab.org/
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
+ * express or implied.
+ * See the License for the specific language governing permissions
+ * and limitations under the License.
+ */
+
+#include stdio.h
+#include fcntl.h
+#include unistd.h
+#include string.h
+
+#include linux/uinput.h
+
+/* look up source file system/core/init/devices.c for exact node */
+#define UINPUT_DEV /dev/uinput
+
+#define DEV_NAME Fake Touchscreen
+
+static int uinput_fd = 0;
+
+static void uinput_touch_init(const char* uinput_dev,
+  const char* dev_name)
+{
+struct uinput_user_dev dev;
+
+uinput_fd = open(uinput_dev, O_WRONLY);
+if (uinput_fd = 0) {
+perror(Error opening uinput device.\n);
+return;
+}
+memset(dev, 0, sizeof(dev));
+strcpy(dev.name, dev_name);
+write(uinput_fd, dev, sizeof(dev));
+
+/* touch screen event */
+ioctl(uinput_fd, UI_SET_EVBIT, EV_ABS);
+ioctl(uinput_fd, UI_SET_ABSBIT, ABS_X);
+ioctl(uinput_fd, UI_SET_ABSBIT, ABS_Y);
+ioctl(uinput_fd, UI_SET_EVBIT, EV_KEY);
+ioctl(uinput_fd, UI_SET_KEYBIT, BTN_TOUCH);
+
+/* register userspace input device */
+ioctl(uinput_fd, UI_DEV_CREATE, 0);
+}
+
+static void uinput_touch_deinit()
+{
+if (uinput_fd  0) {
+close(uinput_fd);
+}
+}
+
+int main(int argc, char* argv[])
+{
+uinput_touch_init(UINPUT_DEV, DEV_NAME);
+
+while (1) {
+sleep(60);
+}
+
+uinput_touch_deinit();
+
+return 0;
+}
+
-- 
1.7.4.1

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/bionic] Add ARM optimized strcmp()

2011-04-20 Thread Jim Huang
Reference results of the experiments on TI OMAP3430 at 600 MHz

$ bench_strcmp -N strcmp_1k -s 1k -I 200

[original C code]
prc thr usecs/call samples errors cnt/samp size
strcmp_1k 1 1 10.38000 102 0 15000 1024

[ARM optimized code]
prc thr usecs/call samples errors cnt/samp size
strcmp_1k 1 1 3.08840 88 0 15000 1024

The work was derived from ARM Ltd, contributed to newlib, and reworked
for Android by Linaro.

Code Review:
https://review.source.android.com/#change,22419
From f50e9be5930a08fa825b0c23353c802e11369b14 Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Wed, 20 Apr 2011 15:35:04 +0800
Subject: [PATCH] bionic: Add ARM optimized strcmp()

Reference results of the experiments on TI OMAP3430 at 600 MHz

$ bench_strcmp -N strcmp_1k -s 1k -I 200

[original C code]
 prc thr   usecs/call  samples   errors cnt/samp size
strcmp_1k  1   1 10.38000  102015000 1024

[ARM optimized code]
 prc thr   usecs/call  samples   errors cnt/samp size
strcmp_1k  1   1  3.08840   88015000 1024

The work was derived from ARM Ltd, contributed to newlib, and reworked
for Android by Linaro.

Change-Id: Ib0d5755e1eb9adb07d80ef0252f57a5c4c57a425
Signed-off-by: Jim Huang js...@0xlab.org
---
 libc/Android.mk   |2 +-
 libc/arch-arm/bionic/strcmp.S |  321 +
 2 files changed, 322 insertions(+), 1 deletions(-)
 create mode 100644 libc/arch-arm/bionic/strcmp.S

diff --git a/libc/Android.mk b/libc/Android.mk
index d940753..2e7cd5a 100644
--- a/libc/Android.mk
+++ b/libc/Android.mk
@@ -360,10 +360,10 @@ libc_common_src_files += \
 	arch-arm/bionic/sigsetjmp.S \
 	arch-arm/bionic/strlen.c.arm \
 	arch-arm/bionic/strcpy.S \
+	arch-arm/bionic/strcmp.S \
 	arch-arm/bionic/syscall.S \
 	string/memmove.c.arm \
 	string/bcopy.c \
-	string/strcmp.c \
 	string/strncmp.c \
 	unistd/socketcalls.c
 
diff --git a/libc/arch-arm/bionic/strcmp.S b/libc/arch-arm/bionic/strcmp.S
new file mode 100644
index 000..9fdbd56
--- /dev/null
+++ b/libc/arch-arm/bionic/strcmp.S
@@ -0,0 +1,321 @@
+/*
+ * Copyright (c) 2011 The Android Open Source Project
+ * Copyright (c) 2008 ARM Ltd
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the company may not be used to endorse or promote
+ *products derived from this software without specific prior written
+ *permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY ARM LTD ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL ARM LTD BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+ * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include machine/cpu-features.h
+
+	.text
+
+	.global strcmp
+	.type strcmp, %function
+	.align 4
+
+#ifdef __ARMEB__
+#define SHFT2LSB lsl
+#define SHFT2LSBEQ lsleq
+#define SHFT2MSB lsr
+#define SHFT2MSBEQ lsreq
+#define MSB 0x00ff
+#define LSB 0xff00
+#else
+#define SHFT2LSB lsr
+#define SHFT2LSBEQ lsreq
+#define SHFT2MSB lsl
+#define SHFT2MSBEQ lsleq
+#define MSB 0xff00
+#define LSB 0x00ff
+#endif
+
+#define magic1(REG) REG
+#define magic2(REG) REG, lsl #7
+
+strcmp:
+	.fnstart
+	PLD(r0, #0)
+	PLD(r1, #0)
+	eor	r2, r0, r1
+	tst	r2, #3
+
+	/* Strings not at same byte offset from a word boundary.  */
+	bne	.Lstrcmp_unaligned
+	ands	r2, r0, #3
+	bic	r0, r0, #3
+	bic	r1, r1, #3
+	ldr	ip, [r0], #4
+	it	eq
+	ldreq	r3, [r1], #4
+	beq	1f
+
+	/* Although s1 and s2 have identical initial alignment, they are
+	 * not currently word aligned.  Rather than comparing bytes,
+	 * make sure that any bytes fetched from before the addressed
+	 * bytes are forced to 0xff.  Then they will always compare
+	 * equal.
+	 */
+	eor	r2, r2, #3
+	lsl	r2, r2, #3
+	mvn	r3, #MSB
+	SHFT2LSB	r2, r3, r2
+	ldr	r3, [r1], #4
+	orr	ip, ip, r2
+	orr	r3, r3, r2
+1:
+	/* Load the 'magic' constant 0x01010101. */
+	str	r4, [sp, #-4]!
+	mov	r4, #1
+	orr	r4, r4, r4, lsl #8
+	orr	r4, r4, r4

Announcement: Linaro ARM Optimized Toolchain for Android platform

2011-04-20 Thread Jim Huang
Hello list,

Today we're announcing a new technical preview of ARM optimized
toolchain for Android platform by Linaro[1].

Linaro is a NFP (Not For Profit) organization that aims to make
embedded open source development easier and faster.  Regardless of
Android release cycle from AOSP, Linaro would like to bring the latest
and ARM optimizing open source technologies to the common software
foundation for software stack, and Linaro toolchain[2] deals with all
aspects of system-level tools - the core development toolchain
(compiler, assembler, linker, debugger).

In this announcement, the technical preview of ARM optimized toolchain
for Android is available for evaluation: (source repository and binary
package)
   https://wiki.linaro.org/Platform/Android/Toolchain

An early activity of the Android Platform Team has been to run the
Android benchmark suite to show the gains possible in going from the
default Google 4.4 based toolchain to the Linaro 4.5 toolchain.  The
experimental benchmarks were run on a 600 MHz Cortex-A8 board running
Android 2.2: (unofficial, for reference only)
   https://wiki.linaro.org/JimHuang/Sandbox/LinaroToolchainAndroidBenchmarking

Developers can utilize the optimization techniques from GNU Toolchain
and Linaro's ARM improvements through Linaro Toolchain for Android and
NDK.  For example, skia benchmark[3] brings 11% performance
improvements after using Linaro Toolchain.

Linaro's Android platform team plans to deliver the final linaro-11.05
release, and you can check out the status of open development:
   https://launchpad.net/linaro-android/

On-going Blueprints:

https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-toolchain-ndk

https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-toolchain-integration

https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-google-benchmark-suite

Sincerely,
Jim Huang,
Android platform team,
Linaro

[1] http://www.linaro.org/
[2] https://wiki.linaro.org/WorkingGroups/ToolChain
[3] Linaro uses the same toolchain benchmark as Google compiler team
does: https://wiki.linaro.org/Platform/Android/UpstreamToolchain

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Announcement: Linaro ARM Optimized Toolchain for Android platform

2011-04-20 Thread Jim Huang
On 21 April 2011 05:54, Michael Hope michael.h...@linaro.org wrote:
 Hi Jim.  Good effort.  The Android patch set will be included in
 gcc-linaro-4.5-2011.04 which is due out today.


hi Michael,

Thanks!
Look forward to new release.

 We need to discuss toolchain build scripts at the summit.  There's a
 want for builds of pretty much every combination of
 {Android,Linux,bare metal?} target, crossed with {Native,Cross}
 builds, crossed with {Ubuntu,Generic Linux,Windows?} hosts.  I'll talk
 with Alexander and Steve and see about a session.

After checking the build scripts of Google compiler team[1] and
NDK[2], the targets are as following:
  (1) arm-eabi : bare metal, used for compiling Android kernel and
(older) userspace
  (2) arm-linux-androideabi : the primary target in Android

We should migrate to use arm-linux-androideabi since
gcc-linaro-2011.04 is expected to include the Android specific patches
such as bionic libc linkage.

In my opinion, Android team of Linaro should follow the
methods/instructions how Google engineers built toolchain and NDK (the
superset of toolchain) and continue sending patches to AOSP for
merging generic features or improvements.

Yes, I agree with ideas to unify build scripts, but it hard to decide
the working items because of uncertainty of AOSP development model.

Sincerely,
-jserv

[1] http://android.git.kernel.org/?p=toolchain/build.git;a=summary
  NOTE: for unknown reasons, I encountered some problems with the
original build script written by Google engineers.  Maybe due to merge
failure between internal tree and AOSP.
[2] http://android.git.kernel.org/?p=platform/ndk.git;a=summary

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


u-boot + Android 'fastboot' protocol/commands support (was: [Android: device/linaro/common] Rename the kernel to uImage for Linaro Android build)

2011-04-19 Thread Jim Huang
On 19 April 2011 14:28, Amit Pundir pundira...@gmail.com wrote:
 On Mon, Apr 18, 2011 at 8:31 PM, Alexander Sack a...@linaro.org wrote:
 On Mon, Apr 18, 2011 at 3:51 PM, Zach Pfeffer pfeff...@gmail.com wrote:
 That would be very nice. There's actually some documentation in u-boot
 about fastboot (a README). I wonder if there's some support already?
 Yes, I was told that someone (TI?) had a public tree with it. If all
 goes well, John (CCed) would review those, clean the patches up,
 upstream and integrate then into our u-boot branches so we can have
 them for our LEB builds as well.

 Rowboat also has a decent Fastboot support in u-boot for OMAP3
 http://gitorious.org/rowboat/u-boot-omap3
 Not all the Fastboot commands are supported though
 http://wiki.tiprocessors.com/index.php/TI-Android-GingerBread-2.3-DevKit-1.0_UserGuide#Fastboot_commands

Hi Amit, Zach, and Alexander,

Thanks for your sharing about u-boot + Android 'fastboot'
protocol/commands support.  At least, patched u-boot works out of box
on TI OMAP platforms.

Can we define the basic boot loader requirements of Linaro Evaluation
Build (LEB) for Android at present?  I think it would be essential for
validation and Android platform verification purpose.

My idea is that we require abstract 'bootloader' component in Android
device/linaro/common, and (patched) 'u-boot' would be the provider of
'bootloader' component in
device/linaro/Linaro-Evaluation-Build-Hardware.  Also, supporting
firmware upgrade through 'fastboot' protocol is the recommend feature
for LEB boot loader.

Does it sound reasonable?

Thanks,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/bionic 0/3] Reduce code size of libc and libm by GCC visibility

2011-04-19 Thread Jim Huang
The following set of Android bionic patches use GCC visibility pragma
to hide the private symbols in bionic. It also lets the optimizer
produce better and smaller machine code.

[PATCH android/bionic 1/3] Hide private symbols using GCC visibility pragma
[PATCH android/bionic 2/3] Hide internal symbol __bionic_brk used by
brk() and sbrk()
[PATCH android/bionic 3/3] Hide libm private symbols using GCC visibility pragma

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/bionic 1/3] Hide private symbols using GCC visibility pragma

2011-04-19 Thread Jim Huang
libc.so should not export all private symbols to reflect Android NDK.
This patch attempts to use GCC visibility pragma to hide the private
symbols in bionic. It also lets the optimizer produce better and
smaller code.

Reference code size measurements for HTC Passion:
$ arm-eabi-size out/target/product/passion/system/lib/libc.so

[before]
   textdata bss dec hex filename
 26   10004   45944  315948   4d22c
out/target/product/passion/system/lib/libc.so

[after]
   textdata bss dec hex filename
 2486559940   45944  304539   4a59b
out/target/product/passion/system/lib/libc.so

Code Review:
https://review.source.android.com/#change,17361
From 74015f0fe72daf8e007298975d6415e0e9ee5e47 Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Wed, 20 Apr 2011 04:28:44 +0800
Subject: [PATCH] Hide private symbols using GCC visibility pragma

libc.so should not export all private symbols to reflect Android NDK.
This patch attempts to use GCC visibility pragma to hide the private
symbols in bionic. It also lets the optimizer produce better and
smaller code.

Reference code size measurements for HTC Passion:
$ arm-eabi-size out/target/product/passion/system/lib/libc.so

[before]
   text	   data	bss	dec	hex	filename
 26	  10004	  45944	 315948	  4d22c	out/target/product/passion/system/lib/libc.so

[after]
   text	   data	bss	dec	hex	filename
 248655	   9940	  45944	 304539	  4a59b	out/target/product/passion/system/lib/libc.so

Change-Id: Id6e845e1cdba19f578a435d796267a8d07c291c3
---
 libc/include/sys/cdefs_hidden_pop.h  |   41 ++
 libc/include/sys/cdefs_hidden_push.h |   41 ++
 libc/netbsd/isc/eventlib_p.h |3 ++
 libc/netbsd/resolv/res_private.h |4 +++
 libc/private/arpa_nameser.h  |4 +++
 libc/private/bionic_tls.h|4 +++
 libc/private/ctype_private.h |3 ++
 libc/private/isc/eventlib.h  |4 +++
 libc/private/logd.h  |4 +++
 libc/private/nsswitch.h  |4 +++
 libc/private/rand48.h|5 
 libc/private/resolv_cache.h  |4 +++
 libc/private/resolv_private.h|4 +++
 libc/private/resolv_static.h |4 +++
 libc/private/thread_private.h|4 +++
 libc/stdio/local.h   |4 +++
 16 files changed, 137 insertions(+), 0 deletions(-)
 create mode 100644 libc/include/sys/cdefs_hidden_pop.h
 create mode 100644 libc/include/sys/cdefs_hidden_push.h

diff --git a/libc/include/sys/cdefs_hidden_pop.h b/libc/include/sys/cdefs_hidden_pop.h
new file mode 100644
index 000..741fede
--- /dev/null
+++ b/libc/include/sys/cdefs_hidden_pop.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2011 The Android Open Source Project
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *  * Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ *  * Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
+ * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/* Ignore GCC visibility if debug build */
+#if !defined(DEBUG) || defined(NDEBUG)
+
+#if !defined(__LIBC_HIDDEN_PUSH_DEFINED)
+#error Unbalanced pair of GCC visibility push/pop
+#endif
+
+#define __LIBC_HIDDEN_POP_DEFINED
+#undef __LIBC_HIDDEN_PUSH_DEFINED
+
+#pragma GCC visibility pop
+
+#endif
diff --git a/libc/include/sys/cdefs_hidden_push.h b/libc/include/sys/cdefs_hidden_push.h
new file mode 100644
index 000..3b12cbd
--- /dev/null
+++ b/libc/include/sys/cdefs_hidden_push.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2011 The Android Open Source Project
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *  * Redistributions

[PATCH android/bionic 2/3] Hide internal symbol __bionic_brk used by brk() and sbrk()

2011-04-19 Thread Jim Huang
__bionic_brk was shared by brk() and sbrk(), which should be implementor
specific and hidden to application developers.

Code Review:
https://review.source.android.com/#change,17364
From 7452bce8defc06a34612b25ace2ef802c0579a83 Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Wed, 20 Apr 2011 04:53:30 +0800
Subject: [PATCH] Hide internal symbol __bionic_brk used by brk() and sbrk()

__bionic_brk was shared by brk() and sbrk(), which should be implementor
specific and hidden to application developers.

Change-Id: Iffe6ab3783e297d919a15812ac4910141a3ff066
---
 libc/unistd/brk.c  |1 +
 libc/unistd/sbrk.c |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/libc/unistd/brk.c b/libc/unistd/brk.c
index bf2f108..5cc28d3 100644
--- a/libc/unistd/brk.c
+++ b/libc/unistd/brk.c
@@ -30,6 +30,7 @@
 #include sys/types.h
 
 /* shared with sbrk.c */
+__LIBC_HIDDEN__
 char *__bionic_brk;
 
 int brk(void*  end_data)
diff --git a/libc/unistd/sbrk.c b/libc/unistd/sbrk.c
index a112b6c..7fc21b9 100644
--- a/libc/unistd/sbrk.c
+++ b/libc/unistd/sbrk.c
@@ -32,7 +32,7 @@
 #define  SBRK_ALIGN  32
 
 /* shared with brk() implementation */
-char*   __bionic_brk;
+extern char*   __bionic_brk;
 
 void *sbrk(ptrdiff_t increment)
 {
-- 
1.7.4.1

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/bionic 3/3] Hide libm private symbols using GCC visibility pragma

2011-04-19 Thread Jim Huang
Following the visibility changes in libc.so, this patch attempts to hide
private symbols in libm.so.

Reference code size measurements for HTC Passion:
$ arm-eabi-size out/target/product/passion/system/lib/libm.so

[before]
   textdata bss dec hex filename
  88423 256  32   88711   15a87
out/target/product/passion/system/lib/libm.so

[after]
   textdata bss dec hex filename
  87950 256  32   88238   158ae
out/target/product/passion/system/lib/libm.so

Code Review:
https://review.source.android.com/#change,17358
From 331af85e9694c4c9247e39716f97ede1a62ee9ce Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Wed, 20 Apr 2011 05:02:10 +0800
Subject: [PATCH] Hide libm private symbols using GCC visibility pragma

Following the visibility changes in libc.so, this patch attempts to hide
private symbols in libm.so.

Reference code size measurements for HTC Passion:
$ arm-eabi-size out/target/product/passion/system/lib/libm.so

[before]
   text	   data	bss	dec	hex	filename
  88423	256	 32	  88711	  15a87	out/target/product/passion/system/lib/libm.so

[after]
   text	   data	bss	dec	hex	filename
  87950	256	 32	  88238	  158ae	out/target/product/passion/system/lib/libm.so

Change-Id: I51841a9f5d7b7663b95ebf5c1bd17d1ec9a6c1b6
---
 libm/src/math_private.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/libm/src/math_private.h b/libm/src/math_private.h
index 5f6e088..8c9f04f 100644
--- a/libm/src/math_private.h
+++ b/libm/src/math_private.h
@@ -20,6 +20,8 @@
 #include sys/types.h
 #include endian.h
 
+#include sys/cdefs_hidden_push.h
+
 /*
  * The original fdlibm code used statements like:
  *	n0 = ((*(int*)one)29)^1;		* index of high word *
@@ -270,4 +272,6 @@ float	__kernel_cosdf(double);
 float	__kernel_tandf(double,int);
 int	__kernel_rem_pio2f(float*,float*,int,int,int,const int*);
 
+#include sys/cdefs_hidden_pop.h
+
 #endif /* !_MATH_PRIVATE_H_ */
-- 
1.7.4.1

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [Android: device/linaro/common] Rename the kernel to uImage for Linaro Android build

2011-04-18 Thread Jim Huang
On 18 April 2011 14:40,  patrik@linaro.org wrote:
 From: Patrik Ryd patrik@linaro.org

 In the Linaro set up u-boot will look for uImage (and not for kernel).
 ---
  tasks/kernel.mk |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

hi Patrik,

Does this imply that we requires u-boot as necessary support for common LEB?

I am not sure if we should introduce an abstract provider for kernel
image, but I prefer to specify in board configurations since we might
migrate to other 'fastboot' compatible boot loader implementations
such as lk (little kernel) used in Qualcomm patform.

Thanks,
-jserv

 diff --git a/tasks/kernel.mk b/tasks/kernel.mk
 index a016d6e..f0ebb93 100644
 --- a/tasks/kernel.mk
 +++ b/tasks/kernel.mk
 @@ -3,5 +3,5 @@ android_kernel:
        make ARCH=arm CROSS_COMPILE=../$(TARGET_TOOLS_PREFIX) defconfig 
 $(KERNEL_CONFIG) \
        make ARCH=arm CROSS_COMPILE=../$(TARGET_TOOLS_PREFIX) uImage

 -$(PRODUCT_OUT)/kernel: android_kernel
 -       ln -sf ../../../../kernel/arch/arm/boot/uImage $(PRODUCT_OUT)/kernel
 \ No newline at end of file
 +$(PRODUCT_OUT)/uImage: android_kernel
 +       ln -sf ../../../../kernel/arch/arm/boot/uImage $(PRODUCT_OUT)/uImage
 \ No newline at end of file
 --
 1.7.1

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [Android: device/linaro/common] Rename the kernel to uImage for Linaro Android build

2011-04-18 Thread Jim Huang
On 18 April 2011 21:01, Zach Pfeffer pfeff...@gmail.com wrote:
 On Mon, Apr 18, 2011 at 1:46 AM, Jim Huang jim.hu...@linaro.org wrote:
 On 18 April 2011 14:40,  patrik@linaro.org wrote:
 From: Patrik Ryd patrik@linaro.org
 In the Linaro set up u-boot will look for uImage (and not for kernel).
 hi Patrik,
 Does this imply that we requires u-boot as necessary support for common LEB?

 I am not sure if we should introduce an abstract provider for kernel
 image, but I prefer to specify in board configurations since we might
 migrate to other 'fastboot' compatible boot loader implementations
 such as lk (little kernel) used in Qualcomm patform.

 I haven't gotten into lk too much (used it and the legacy fastboot),
 but it seems that sticking with u-boot may be a better approach since
 it has wider community support and better cross-platform support. Was
 there a specific reason to move to lk?

hi Zach,

In my opinion, if we can follow the protocol of 'fastboot' in _any_
bootloader, we can ensure the consistent approach to deploy firmware
both in LEB and Android products.

u-boot is a great boot loader, but it lacks of usable 'fastboot'
protocol support.  I would regard it as the present working
implementation instead of de facto standard in LEB for Android.

Thanks,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH android/toolchain/build] Add --enable-graphite option to build script

2011-04-06 Thread Jim Huang
On 29 March 2011 06:34, Jim Huang jim.hu...@linaro.org wrote:
 GCC 4.5 and up supports graphite optimization, and cloog and ppl
 are required. This change attempts to support some combinations
 of ppl and cloog/cloog-ppl libraries. Since cloog and ppl are
 written in C++, it implies we might suffer from C++ ABI breakage
 problems when host environment changes, that is a well-known issue
 in GNU/Linux distributions. Thus, we have to drop runtime libstdc++
 dependency by statically linking libstdc++.

Code Review:
 https://review.source.android.com//#change,22157

Merged in linaro tree.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/frameworks/base] audioflinger: Enable ARMv5TE optimized resampler

2011-04-06 Thread Jim Huang
Previously, the optimized asm option is only enabled when
__ARM_ARCH_5E__ is defined, which is assigned in armv5te.mk
rather than armv7-a series targets. This patch checks the ARM CPU
feature about half-word multiply instructions to enable ARMv5TE
resampler optimization routines properly.

Code Review:
https://review.source.android.com/#change,22158

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH] toolchain/build: Integrate Linaro-GDB in Android toolchain build system

2011-04-06 Thread Jim Huang
On 30 March 2011 15:07, Luse Cheng l...@0xlab.org wrote:
 Integrate Linaro-GDB in Android toolchain build system
 ---
  linaro-build.sh |  126
 ++
  1 files changed, 79 insertions(+), 47 deletions(-)

Thanks!  Merged in Linaro HEAD.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Pathes for Produce boottarball that includes rootfs, kernel and bootloader for Android

2011-04-05 Thread Jim Huang
On 6 April 2011 01:08, Patrik Ryd patrik@linaro.org wrote:
 Hi,
 I will push some patches for review. They are all for Android.

hi Patrik,

Great work!

 For the blueprint
 https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-platform-kernel-boottarball.
 I have had problems setting the subject correctly, but they are for the
 android manifest, linaro/device/common,  linaro/device/beagleboard and build
 gits.

As far as I know, you can use parameter
--subject-prefix=Subject-Prefix (such as PATCH
android/device/common) to 'git format-patch' when you are going to
send patches.
Please check 'git format-patch --help' for details.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH-Android] [android/system/media] File renamed to avoid build errors using GCC 4.5/4.6.

2011-03-30 Thread Jim Huang
On 16 March 2011 13:16, Sachin Kamat sachin.ka...@linaro.org wrote:
  Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

 Change-Id: I39652f14b362c42ebc2ceb37952d8e57cf89692c
 ---
  opensles/libopensles/Android.mk         |    2 +-
  opensles/libopensles/IAndroidEffect.c   |  130 
 ---
  opensles/libopensles/IAndroidEffect.cpp |  130 
 +++
  3 files changed, 131 insertions(+), 131 deletions(-)
  delete mode 100644 opensles/libopensles/IAndroidEffect.c
  create mode 100644 opensles/libopensles/IAndroidEffect.cpp

Alternatively, disabling C++ RTTI can avoid linkage error:
https://review.source.android.com//#change,20439

Thanks,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Libraries with NEON backends

2011-03-27 Thread Jim Huang
On 28 March 2011 05:09, Michael Hope michael.h...@linaro.org wrote:
 Hi there.  I'm looking for areas where the toolchain could generate
 faster code, and a good way of doing that is seeing how compiled code
 does against the best hand-written code.  I know of skia, ffmpeg,
 pixman, Orc, and efl - what others are out there?


hi Michael,

Great motivation to optimize the existing libraries by NEON !

As far as I know, Android depends on several libraries, and some of
them are computing bound:

- libpixelflinger -- a bit like pixman
  There is no official document about PixelFlinger, but you can always
check out its source:
http://android.git.kernel.org/?p=platform/system/core.git;a=summary
  I submitted one NEON optimization patch for libpixelflinger to AOSP before:
https://review.source.android.com//#change,16358

- zlib
  Using SIMD, we can optimize 'copy / repeat an existing sequence' in
LZ-style encoding.
  The reference Intel SSE2 optimization patch is attached in this mail.

Sincerely,
-jserv
diff -urNp zlib-1.2.5-orig/deflate.c zlib-1.2.5/deflate.c
--- zlib-1.2.5-orig/deflate.c   2010-04-20 12:12:21.0 +0800
+++ zlib-1.2.5/deflate.c2010-07-26 03:53:34.0 +0800
@@ -49,6 +49,17 @@
 
 /* @(#) $Id$ */
 
+/* We can use 2-byte chunks only if 'unsigned short' has been defined
+ * appropriately and MAX_MATCH has the default value.
+ */
+#ifdef UNALIGNED_OK
+#  include limits.h
+#  include zutil.h
+#  if (MAX_MATCH != 258) || (USHRT_MAX != 0x)
+#undef UNALIGNED_OK
+#  endif
+#endif
+
 #include deflate.h
 
 const char deflate_copyright[] =
@@ -1119,7 +1130,8 @@ local uInt longest_match(s, cur_match)
  * However the length of the match is limited to the lookahead, so
  * the output of deflate is not affected by the uninitialized values.
  */
-#if (defined(UNALIGNED_OK)  MAX_MATCH == 258)
+#ifdef UNALIGNED_OK
+
 /* This code assumes sizeof(unsigned short) == 2. Do not use
  * UNALIGNED_OK if your compiler uses a different size.
  */
diff -urNp zlib-1.2.5-orig/deflate.h zlib-1.2.5/deflate.h
--- zlib-1.2.5-orig/deflate.h   2010-04-19 12:00:46.0 +0800
+++ zlib-1.2.5/deflate.h2010-07-26 03:53:34.0 +0800
@@ -251,9 +251,12 @@ typedef struct internal_state {
 ulg bits_sent;  /* bit length of compressed data sent mod 2^32 */
 #endif
 
-ush bi_buf;
+ulg bi_buf;
 /* Output buffer. bits are inserted starting at the bottom (least
- * significant bits).
+ * significant bits).  Room for at least two short values to allow
+ * for a simpler overflow handling.  However, if more than 16 bits 
+ * have been buffered, it will be flushed and* and no more then 16 
+ * bits will be in use afterwards.
  */
 int bi_valid;
 /* Number of valid bits in bi_buf.  All bits above the last valid bit
@@ -274,6 +277,20 @@ typedef struct internal_state {
  */
 #define put_byte(s, c) {s-pending_buf[s-pending++] = (c);}
 
+/* Output a short LSB first on the stream.
+ * IN assertion: there is enough room in pendingBuf.
+ */
+#if defined(LITTLE_ENDIAN)  defined(UNALIGNED_OK)
+#  define put_short(s, w) { \
+*(ush*)(s-pending_buf + s-pending) = (ush)(w);\
+s-pending += 2; \
+}
+#else
+#  define put_short(s, w) { \
+put_byte(s, (uch)((w)  0xff)); \
+put_byte(s, (uch)((ush)(w)  8)); \
+}
+#endif
 
 #define MIN_LOOKAHEAD (MAX_MATCH+MIN_MATCH+1)
 /* Minimum amount of lookahead, except at the end of the input file.
diff -urNp zlib-1.2.5-orig/inffast.c zlib-1.2.5/inffast.c
--- zlib-1.2.5-orig/inffast.c   2010-04-19 12:16:23.0 +0800
+++ zlib-1.2.5/inffast.c2010-07-26 03:53:34.0 +0800
@@ -1,5 +1,6 @@
 /* inffast.c -- fast decoding
- * Copyright (C) 1995-2008, 2010 Mark Adler
+ * Copyright (C) 1995-2004, 2010 Mark Adler
+ *   2010 Optimizations by Stefan Fuhrmann
  * For conditions of distribution and use, see copyright notice in zlib.h
  */
 
@@ -10,16 +11,35 @@
 
 #ifndef ASMINF
 
+/* This is a highly optimized implementation of the decoder function for
+ * large code blocks. It cannot be used to decode close to the end of
+ * input nor output buffers (see below).
+ *
+ * Before trying to hand-tune assembly code for your target, you should
+ * make sure that alignment, endianess, word size optimizations etc. have
+ * already been enabled for the respective target platform. 
+ 
+ * For MS VC++ 2008, the performance gain of specialized code against
+ * DISABLE_INFLATE_FAST_OPTIMIZATIONS (base line) is as follows:
+ *
+ * x86 (32 bit):+60% throughput
+ * x64 (64 bit):+70% throughput
+ *
+ * Measurements were taken on a Core i7 CPU with a mix of small and large
+ * buffers (110MB total) or varying content and an average compression rate 
+ * of 2.2 .
+ */
+
 /* Allow machine dependent optimization for post-increment or pre-increment.
-   Based on testing to date,
-   Pre-increment preferred for:
-   - PowerPC G3 (Adler)
-   - MIPS R5000 

Re: [PATCH android/device/linaro/pandaboard] Add vold.fstab

2011-03-24 Thread Jim Huang
On 24 March 2011 01:03, Jeremy Chang jeremy.ch...@linaro.org wrote:
[...]
 Hi, Patrik,
    How should I add the linaro copyright? like below line?

 # Copyright (C) 2011 Linaro - http://linaro.org


hi Jeremy,

Please check the text description:
 https://wiki.linaro.org/Copyright

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH android/device/linaro/beagleboard] Add vold.fstab

2011-03-21 Thread Jim Huang
On 22 March 2011 06:47, Alexander Sack a...@linaro.org wrote:
 On Mon, Mar 21, 2011 at 7:35 PM, Jeremy Chang jeremy.ch...@linaro.org wrote:
[...]
 +dev_mount sdcard /mnt/sdcard 7 
 /devices/platform/mmci-omap-hs.0/mmc_host/mmc0

 from what i understand this hardcodes that our sdcard partition is
 partition 7 right?

Yes, it was hardcoded.

 Remember, that eventually we will move to by-name or by-uuid not
 only because it feels cleaner, but also because the partition offset
 for our validation farm install might be different.

But vold has its own logic and why not keep the same configurations as
Android tends to take?
I mean, we can always prepare the well-defined layout and vold.fstab in advance.

Adding new codes to vold might not be a good idea since Google always
tries to improve user-space utilities and their configurations.

 Is there a way to also express this here? Otherwise, I would think
 that we have to keep the mount in the init.rc. Or would we also work
 on adding by-name here?

In my opinion, providing flexible ways in /init (no visible changes by
each Android release) is good because we have to make sure that we can
always boot from storage, and then we can do something automated such
as adb.  While, it might not be the same if we modify vold (always
changed).

Just my two cents.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH-Android] Patches to build Android using GCC 4.5/4.6.

2011-03-18 Thread Jim Huang
On 17 March 2011 23:35, Patrik Ryd patrik@linaro.org wrote:
 Hi,
 I think your patches are good enough (now after the review) to start pushing
 them to a toolchain_preview branch. That way people can use
 the toolchain_preview branch when working with the toolchain.
 At the same time someone can try to replace some of your patches with
 solutions that solves the problems instead of hiding them. :) The goal is to
 get good patches to the linaro_android branch and in the end get them all
 the way to AOSP if possible.

hi Patrik,

So, it implies that we should have an branch in manifests?
http://git.linaro.org/gitweb?p=android/platform/manifests.git;a=summary

Also, we would take that branch as the testbed for toolchain/NDK benchmarking.

Sincerely,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: Some GL benchmarks for ARM devices

2011-03-18 Thread Jim Huang
On 18 March 2011 23:37, Jesse Barker jesse.bar...@linaro.org wrote:
 Hi all,
 Thought this might be of interest to folks.
 http://www.glbenchmark.com/result.jsp?benchmark=glpro20orderby=405screen-group=truescreen-group-value=1submi=OKscreen=4screen=3screen=2screen=1screen=0os=0os=1os=2os=3os=4version=allcertified_only=1brand=all

 http://www.glbenchmark.com/compare.jsp?benchmark=glpro20showhide=truecertified_only=1D1=Hardkernel%20ODROID-AD2=Apple%20iPad%202

hi Jesse,

Thanks for sharing.  However, I have no idea about the real measuring
methods for GLbenchmark.

Instead, 0xlab developers did the open source benchmarking as well:
http://0xbenchmark.appspot.com/

This service is based on Google AppEngine, and you can login to check
more device comparisons.

 The first is an overall comparison (pretty high level) of available boards,
 and the second is a breakdown of the top 2 results: the Apple iPad2 and the
 Hardkernel ODROID-A (FWIW, according to androidtablets.net, the odroid-a is
 an Orion).  While this can certainly be a red herring, it might be nice to
 see these comparisons with identical screen resolutions (i.e. not all
 performance measurements are sensitive to pixel resolution).

ODROID-A looks promising.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH 2/2 android/device/linaro/common] mount mmc partitions instead of mtd partitions

2011-03-15 Thread Jim Huang
On 15 March 2011 16:29, Alexander Sack a...@linaro.org wrote:
 On Mon, Mar 14, 2011 at 3:37 PM, Jeremy Chang jeremy.ch...@linaro.org wrote:
 All partitions from mmc is expected.
 This depends on Jim Huang's patch init: support mmc device mount in
 android/system/core to work.

 what happened with the by-name approach? Is this something we plan to do 
 next?


hi Alexander,

Yes, that is the next patch I would like to submit.  At present,
Jeremy and I just make sure
the minimal-but-working patches landed in Linaro first.

Sincerely,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: A good skia [was: Re: [RFC] Linaro Toolchain for Android and NDK]

2011-03-11 Thread Jim Huang
On 8 March 2011 02:37, Jim Huang jim.hu...@linaro.org wrote:
 I just updated wiki page about Google's compiler benchmark suite:
    https://wiki.linaro.org/Platform/Android/UpstreamToolchain
 Please check the section, Evaluate Benchmark suite.
 Through adb[1], it is highly convenient to bench generated binary
 files on Android device:
[...]
 time adb  shell 'cd /data/local/perflab; echo
 Android_TIME_STAMP_$(timestamp); /data/local/perflab/skia_bench
 -repeat 15; echo Android_TIME_STAMP_$(timestamp)'

 0.00user 0.00system 4:33.25elapsed 0%CPU (0avgtext+0avgdata 4208maxresident)k
 0inputs+0outputs (0major+325minor)pagefaults 0swaps
 timestamp: not found
[...]
 The function timestamp is broken at the moment, and I am still
 looking for the details.

Here timestamp is an Android command line tool which reports the
current time in seconds.

You can get it from scripts/timestamp/src/timestamp.c

http://android.git.kernel.org/?p=toolchain/benchmark.git;a=blob;f=scripts/timestamp/src/timestamp.c;hb=HEAD

To build the tool, enter the timestamp directory and type

../bench.py --action=build --toolchain=Android toolchain path

adb push out/timestamp to /system/bin on Android device.

Then you are able to call timestamp to report time stamp in seconds.

Sincerely,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH] toolchain/build: Support linaro android toolchain

2011-03-10 Thread Jim Huang
On 9 March 2011 15:35, Meng-Hsuan Cheng l...@0xlab.org wrote:
 Add linaro-build.sh to support linaro android toolchain.

Merged (along with slight syntax tweak) in GIT:
http://git.linaro.org/gitweb?p=android/platform/build.git;a=summary

Thanks for your contribution.

Sincerely,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: A good skia [was: Re: [RFC] Linaro Toolchain for Android and NDK]

2011-03-07 Thread Jim Huang
On 2 March 2011 09:51, Michael Hope michael.h...@linaro.org wrote:
 On Tue, Mar 1, 2011 at 3:53 PM, Jim Huang jim.hu...@linaro.org wrote:
[...]
 The skia maintainer, Mike Reed, made two branches: one is hosted in
 Google Code, and another is
 inside Android source tree:
    http://android.git.kernel.org/?p=platform/external/skia.git;a=summary

 Thanks Jim.  The Android tree doesn't have any build scripts and I'm
 reluctant to stray too far away from upstream by adding my own.  I'll
 stick with the code.google one for now.

 I've updated:
  http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/trunk/view/head:/lib/skiabench.mk

hi Michael,

Great to see more benchmark items.

 with interations so that each sub benchmark runs for approximately
 five seconds.  This reduces the noise in the results, although I
 haven't checked to see if some of the very fast ones like fps_fill are
 dominated by the test harness overhead.

 For example, running:
  bench -rotate -scale -clip -config  -repeat 600 -match fps_blend

 will take around 5 s to complete on a 1 GHz Cortex-A9.

I just updated wiki page about Google's compiler benchmark suite:
https://wiki.linaro.org/Platform/Android/UpstreamToolchain

Please check the section, Evaluate Benchmark suite.

Through adb[1], it is highly convenient to bench generated binary
files on Android device:

$ ../scripts/run_on_android.py
../scripts/bench.py --action=runcmd
echo Android_TIME_STAMP_$(timestamp); /data/local/perflab/skia_bench
-repeat 15; echo Android_TIME_STAMP_$(timestamp)
../scripts/bench.py --action=export
./out/skia_bench
adb  shell mkdir /data/local/perflab

['./out/skia_bench']
adb  push ./out/skia_bench /data/local/perflab
823 KB/s (802944 bytes in 0.951s)

time adb  shell 'cd /data/local/perflab; echo
Android_TIME_STAMP_$(timestamp); /data/local/perflab/skia_bench
-repeat 15; echo Android_TIME_STAMP_$(timestamp)'

0.00user 0.00system 4:33.25elapsed 0%CPU (0avgtext+0avgdata 4208maxresident)k
0inputs+0outputs (0major+325minor)pagefaults 0swaps
timestamp: not found
Android_TIME_STAMP_
running bench decode__(null)  :   0.07   565:   0.00  :
0.00A8:   0.07
running bench decode_565_(null)  :   0.00   565:   0.00  :
0.00A8:   0.07
...

From the above messages, Google introduced the automated approach to deploy
benchmark suite and evaluate it on the fly.

The function timestamp is broken at the moment, and I am still
looking for the details.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [RFC] Linaro Toolchain for Android and NDK

2011-03-01 Thread Jim Huang
On 1 March 2011 18:07, Andrew Stubbs andrew.stu...@linaro.org wrote:
 On 01/03/11 07:00, Jim Huang wrote:
 I think thats fine. however, how do we ensure that we have patches
   that always apply to both release/snapshots? do we maintain branches
   for gcc-patches.git in case you need two versions of patch X if the
   linaro gcc codebase diverged?

 I might need help from toolchain WG.

 I aim to have Android support in Linaro GCC soon, but I lack the ability to
 test it. In fact, I have wanted to have Android support in both February's
 and March's release, but it isn't going to happen now.

hi Andrew,

Thanks for replying.

 I did build a Linaro GCC with the Android patches installed, and it did
 appear to build a lot of the Android tree, but the Android build is broken.
 There are problems with -Werror, but even when you work around those, it
 still won't build. :(

 When somebody gives me a properly patched Android tree, that will build
 out-of-the-box with GCC 4.6, then I will be unblocked, and Linaro GCC will
 have Android support shortly afterwards. :)

Jeremy and I will help you to resolve Android build issue later.  At the moment,
you can safely remove -Werror from Android build system.

Regards,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH v2] device/linaro/beagleboard: Setup network environment during booting

2011-02-28 Thread Jim Huang
On 28 February 2011 20:33, Alexander Sack a...@linaro.org wrote:
 Is there something like a network management service/framework in
 android that could be improved to also consider LAN to achieve
 always-online? I assume it currently reacts on wifi or 3g signal
 becoming available/going away.

hi Alexander,

I don't think Android has such LAN assumption in mind.  In fact, we
need extra patches to enable
Ethernet support in Android.  To make development friendly, the way
Jeremy took might be the most
straightforward.

'netcfg' could detect and apply related configurations for Beagleboard-xM.

Thanks,
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[PATCH android/system/core] init: support mmc device mount (by partition)

2011-02-23 Thread Jim Huang
init.rc usage example:
mount vfat mmc@blk1p3 /mnt/sdcard2
---
 init/builtins.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/init/builtins.c b/init/builtins.c
index e0ccf9f..32d9d7f 100644
--- a/init/builtins.c
+++ b/init/builtins.c
@@ -356,6 +356,16 @@ int do_mount(int nargs, char **args)
 close(fd);
 ERROR(out of loopback devices);
 return -1;
+} else if (!strncmp(source, mmc@blk, 7)) {
+sprintf(tmp, /dev/block/mmcblk%s, source + 7);
+
+if (wait)
+wait_for_file(tmp, COMMAND_RETRY_TIMEOUT);
+if (mount(tmp, target, system, flags, options)  0) {
+return -1;
+}
+
+return 0;
 } else {
 if (wait)
 wait_for_file(source, COMMAND_RETRY_TIMEOUT);
-- 
1.7.2.3

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH android/system/core] init: support mmc device mount (by partition)

2011-02-23 Thread Jim Huang
On 23 February 2011 20:58, Alexander Sack a...@linaro.org wrote:
 On Wed, Feb 23, 2011 at 10:45 AM, Jim Huang jim.hu...@linaro.org wrote:
 init.rc usage example:
    mount vfat mmc@blk1p3 /mnt/sdcard2

 this feels like a weird split of the device name with mmc before and
 blk1 after the @. especially if you look how its used with mtd@FSNAME

 how about using mmcblkX@FSNAME or even mmc@uuid:UUID ?

Initially, I wanted to support find-by-name as
device/samsung/crespo/init.herring.rc does in Android 2.3:

mount ext4 /dev/block/platform/s3c-sdhci.0/by-name/system /system wait ro

So, the naming scheme is followed as mmc@system.  However, I have to
consider the label attribute about
different file system implementations, and the similar functionality
like 'blkid' must exist in order to take care
about find-by-name.  Since /init is statically-linked, no other
libraries should be imported, we should always
keep it compact.

Therefore, considering the backward compatibility, I take mmc@blk1p3
now, and it can become mmc@system
in next patches once the facility is implemented.

Yes, I agree with you.  It looks weird, but we should consider the
consistency: mmc, mtd, loop, etc.
mmcblk has different meaning rather than mmc as far as I know.

I have no idea about the naming, and I would just focus on how to
implement a generic approach to mount
each MMC partition in early Android userspace.

Thanks for your input.

-jserv

 ---
  init/builtins.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/init/builtins.c b/init/builtins.c
 index e0ccf9f..32d9d7f 100644
 --- a/init/builtins.c
 +++ b/init/builtins.c
 @@ -356,6 +356,16 @@ int do_mount(int nargs, char **args)
         close(fd);
         ERROR(out of loopback devices);
         return -1;
 +    } else if (!strncmp(source, mmc@blk, 7)) {
 +        sprintf(tmp, /dev/block/mmcblk%s, source + 7);
 +
 +        if (wait)
 +            wait_for_file(tmp, COMMAND_RETRY_TIMEOUT);
 +        if (mount(tmp, target, system, flags, options)  0) {
 +            return -1;
 +        }
 +
 +        return 0;
     } else {
         if (wait)
             wait_for_file(source, COMMAND_RETRY_TIMEOUT);
 --
 1.7.2.3

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[RFC] Linaro Toolchain for Android and NDK

2011-02-22 Thread Jim Huang
: 4.2.4
 * mpfr: 2.4.1

Only gcc is replaced by gcc-linaro: 4.5-2011.02-0 and others are
checked out from korg GIT.


** Summary of gcc-patches

gcc-patches are used as backport from Google changes into Linaro
gcc base.  Here is the summary at present:

0001-Add-linux-android.patch
Add linux-android

0002-Add-support-for-Bionic-C-library.patch
Add support for Bionic C library

0003-Support-compilation-for-Android-platform.patch
Support compilation for Android platform

0004-Add-multilib-configuration-for-arm-linux-androideabi.patch
Add multilib configuration for arm-linux-androideabi

0005-Fix-gthr-posix.h-to-support-Bionic.patch
Fix gthr-posix.h to support Bionic

0006-Add-untested-support-for-Bionic-to-libstdc.patch
Add [untested] support for Bionic to libstdc++

These patches are taken from Maxim Kuvyrkov of CodeSourcery in gcc-4.6
branch.  Of course, we can always add changes by
Google or other Android specific adaptation by this model.


** Planned improvements over Linaro toolchain for Android

(1) GCC multilib setting
 Default: arm, fpu and thumb.  The prebuilt google toolchain use:
armv5te and mandroid.  We should focus on ARMv7.
(2) HardFP-ABI Support for Android.
(3) Patch management: Better to get the Android patches into
Linaro-GCC tree eventually.
(4) Build system improvement. Don't have to build gmp, mpfr everytime,
and provide option to build without gdb.
(5) Enable LTO (Link Time Optimization, introduced since gcc-4.5) in
Android TARGET_GLOBAL_CFLAGS
(6) Verify the functionality of FDO (Feedback Directed Optimization)
and introduce the approaches to integrate.


** Toward Android NDK

Once Linaro toolchain for Android is ready to use, it is time to
re-package Android NDK by Linaro toolchain.  To do that, extra
build configuration, sysroot, is required.  According to Android
Release Cycle  Phases[5], the repacked NDK should be verified
one moth after Android public release.

Sincerely,
Jim Huang (jserv)

[1] http://developer.android.com/sdk/ndk/index.html
[2] http://android.git.kernel.org/
[3] 
http://android.git.kernel.org/?p=toolchain/gcc.git;a=commit;h=b094d6c4bf572654a031ecc4afe675154c886dc5
[4] Smaller and Faster Android: A talk from a practitioner to fellow
ones, Shih-wei Liao, Google,

http://coscup.wdfiles.com/local--files/schedule-2009/AndroidOptimizationStudies.pdf
[5] Android Release Cycle  Phases Draft,
https://wiki.linaro.org/Platform/Android/ReleaseCycle

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Patch subject for complex project like Android (was: Re: [PATCH v2] device/linaro/beagleboard: Install 0xbench native applications)

2011-02-21 Thread Jim Huang
2011/2/21 Jason Kridner jkrid...@beagleboard.org:
 How about putting it inside the [PATCH xxx], ie. [PATCH v3 android]
 device/linaro/beagleboard: Install 0xbench native applications?  When
 I go to git.linaro.org, this would give me enough information to
 figure out to which tree this patch applied.  For that matter, isn't
 device/linaro/beagleboard redundant as a comment within that tree?
 Why not just do [PATCH v3 android/device/linaro/beagleboard] Install
 0xbench native applications?

hi Jason,

I completely agree with you.  Also, your idea matches the layout of
git.linaro.org .

Thanks a lot!
-jserv

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH v2] device/linaro/beagleboard: Install 0xbench native applications

2011-02-20 Thread Jim Huang
2011/2/20 Jason Kridner jkrid...@beagleboard.org:
 Am I the only one for which the word android before device in the subject 
 would really help?


hi Jason,

I agree with you.  However, if we do git am the patch with subject
prefixing android: , every git
log would start with android: , right?  It sounds a bit annoying.

 On Feb 18, 2011, at 10:18 AM, Jeremy Chang jeremy.ch...@linaro.org wrote:

 Signed-off-by: Jeremy Chang jeremy.ch...@linaro.org
 ---
 ZeroXBenchmark.mk |   96 
 +
 beagleboard.mk    |    6 +++-
 2 files changed, 101 insertions(+), 1 deletions(-)
 create mode 100644 ZeroXBenchmark.mk

 diff --git a/ZeroXBenchmark.mk b/ZeroXBenchmark.mk
 new file mode 100644
 index 000..e78047d
 --- /dev/null
 +++ b/ZeroXBenchmark.mk
 @@ -0,0 +1,96 @@
 +UNIXBENCH_BENCH_APPS :=         \
 +    bench_ubench_hanoi          \
 +    bench_ubench_syscall        \
 +    bench_ubench_context1       \
 +    bench_ubench_pipe           \
 +    bench_ubench_spawn          \
 +    bench_ubench_execl          \
 +    bench_ubench_looper         \
 +    bench_ubench_fstime         \
 +    bench_ubench_arithoh        \
 +    bench_ubench_register       \
 +    bench_ubench_short          \
 +    bench_ubench_int            \
 +    bench_ubench_long           \
 +    bench_ubench_float          \
 +    bench_ubench_double         \
 +    bench_ubench_dhry2          \
 +    bench_ubench_dhry2reg       \
 +    bench_ubench_whetstone-double
 +
 +LIBMICRO_BENCH_APPS :=          \
 +    bench_getpid                \
 +    bench_bind                  \
 +    bench_cascade_mutex         \
 +    bench_cascade_fcntl         \
 +    bench_cascade_flock         \
 +    bench_chdir                 \
 +    bench_close                 \
 +    bench_close_tcp             \
 +    bench_connection            \
 +    bench_dup                   \
 +    bench_exec                  \
 +    bench_exit                  \
 +    bench_exp                   \
 +    bench_fcntl                 \
 +    bench_fcntl_ndelay          \
 +    bench_file_lock             \
 +    bench_fork                  \
 +    bench_getenv                \
 +    bench_gettimeofday          \
 +    bench_getpeername           \
 +    bench_getrusage             \
 +    bench_getsockname           \
 +    bench_isatty                \
 +    bench_listen                \
 +    bench_localtime_r           \
 +    bench_log                   \
 +    bench_longjmp               \
 +    bench_lrand48               \
 +    bench_lseek                 \
 +    bench_malloc                \
 +    bench_memcpy                \
 +    bench_memmove               \
 +    bench_memrand               \
 +    bench_memset                \
 +    bench_mktime                \
 +    bench_mprotect              \
 +    bench_mmap                  \
 +    bench_msync                 \
 +    bench_munmap                \
 +    bench_mutex                 \
 +    bench_nop                   \
 +    bench_open                  \
 +    bench_pipe                  \
 +    bench_poll                  \
 +    bench_pread                 \
 +    bench_pthread_create        \
 +    bench_pwrite                \
 +    bench_read                  \
 +    bench_realpath              \
 +    bench_recurse               \
 +    bench_select                \
 +    bench_setsockopt            \
 +    bench_sigaction             \
 +    bench_siglongjmp            \
 +    bench_signal                \
 +    bench_sigprocmask           \
 +    bench_socket                \
 +    bench_socketpair            \
 +    bench_stat                  \
 +    bench_strcasecmp            \
 +    bench_strchr                \
 +    bench_strcmp                \
 +    bench_strcpy                \
 +    bench_strftime              \
 +    bench_strlen                \
 +    bench_strtol                \
 +    bench_system                \
 +    bench_time                  \
 +    bench_times                 \
 +    bench_write                 \
 +    bench_writev
 +
 +ZEROXBENCHMARK_NATIVE_APPS :=   \
 +    $(UNIXBENCH_BENCH_APPS)     \
 +    $(LIBMICRO_BENCH_APPS)
 diff --git a/beagleboard.mk b/beagleboard.mk
 index c10e0fa..f810f36 100644
 --- a/beagleboard.mk
 +++ b/beagleboard.mk
 @@ -1,5 +1,7 @@
 # The beagleboard product that is specialized for beagleboard.

 +include $(LOCAL_PATH)/ZeroXBenchmark.mk
 +
 PRODUCT_PACKAGES := \
     ZeroXBenchmark \
     libmicro \
 @@ -22,7 +24,9 @@ PRODUCT_PACKAGES := \
     Sync \
     Updater \
     CalendarProvider \
 -    SyncProvider
 +    SyncProvider \
 +    $(ZEROXBENCHMARK_NATIVE_APPS)
 +

 $(call inherit-product, $(SRC_TARGET_DIR)/product/core.mk)

 --
 1.7.1

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [PATCH v2] device/linaro/beagleboard: Setup network environment during booting

2011-02-18 Thread Jim Huang
2011/2/18 Jeremy Chang jeremy.ch...@linaro.org:
 Try to enable network interface and fetch IP via DHCP in boot script.

 This will give the network interface a shot to fetch IP via DHCP.

To be precise, this patch works with Beagleboard-xM only.

 --- a/init.omap3.sh
 +++ b/init.omap3.sh
 @@ -15,3 +15,5 @@ do
             ;;
     esac
  done  /proc/cpuinfo
 +
 +netcfg usb0 dhcp

Beagleboard xM has one Ethernet port connected over USB, and the
driver model makes it usable
as a normal network device on device node, usb0. (Ethernet support for USB )

That is the reason why usb0 is here.

Sincerely,
Jim Huang (jserv)
http://0xlab.org/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


Re: [RFC] agent-based remote validation invocation for LAVA

2011-02-16 Thread Jim Huang
2011/2/16 Mirsad Vojnikovic mirsad.vojniko...@linaro.org:
 Hi all!


hi Mirsad,

 This is very good analysis you have done, and I would just add that Monkey
 is only one simpler example where the test execution using abrek is not an
 option.

True.

 Another example from Android world is CTS:
 http://source.android.com/compatibility/cts-intro.html. Most certainly, all
 test suites and frameworks are not only DUT-based. Some of them have more or
 less dependencies and functions on the PC side as well.


Yes, in fact, Android CTS replies on PC side, too.  The device will
try to reset adb (through USB
gadget) for several times in order to probe the compatibility to host
(Windows/Linux/MacOSX).

 Zygmunt has already identified key points for Job Dispatcher to support
 this, but one thing I would like to comment:

 Another crazy option would be to expose LAVA Job Dispatcher directly and
 allow people to run jobs. In this case one job would use abrek and some
 other tools to invoke tests, process results and send them to the dashboard
 while other job (one for android) would not run abrek at all, instead it
 would call some other helper, while still reusing identical components for
 process results and send to result storage phases. This is still in flux
 but has some advantages:
 0) Jobs are simple text files that can be stored and shared with others
 1) Jobs can encapsulate device information like which android device to
 connect to and how.
 2) Jobs can still call to other parts of the LAVA stack such as result
 submission
 3) Jobs can be extended locally (by LAVA plugins) so that anyone can
 develop specialized use cases for their very specific needs without
 altering the stack or having to write something completely custom.

 I think exposing Job Dispatcher directly would not be a good idea for
 validation farm, where test jobs are queued for execution via Scheduler (see
 LAVA architecture). Bypassing the job queue on the Dispatcher level should
 only be allowed in exceptional cases, i.e. canceling jobs for server/board
 update or similar. There might be scenarios where the unrestricted direct
 control is desirable, but that should be only allowed for local development
 environments.


Thanks for pointing out this.

 It would be good to have this specified/discussed somewhere already now,
 maybe in the Dispatcher blueprint, or maybe we need additional blueprint or
 wiki spec for it?

Yes, it would be great.

Cheers,
Jim Huang (jserv)
http://0xlab.org/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


[RFC] agent-based remote validation invocation for LAVA

2011-02-15 Thread Jim Huang
Hello list,

Regarding integration of LAVA [1] architecture with Android devices,
we would like to reuse the existing
infrastructure and framework design. Abrek [2]  is a great testsuite
framework for running test cases and
benchmarks.  However, due to the restrictions of unusual Android
runtime, we consider to introduce the
agent-based remote validation invocation mechanism for LAVA as the
extension.  Also, the proof-of-concept
implementation is attached.

** Why can't we execute LAVA/Abrek directly on Android devices?

LAVA/Abrek is written in Python, which implies there must be a solid
Python runtime for Android.  CPython is
verified and well-designed, but it is not well tested on Android.  In
fact, Android has its own libc implementation,
bionic, which is the minimal and special libc originally taken from
NetBSD libc.  However, bionic libc only supports
limited set of POSIX C APIs, and it is almost not feasible to maintain
Linaro bionic modifications in early stage
just to satisfy CPython.  The bionic libc is always changed fast by
Google engineers, and we have no idea about
their plans.

Therefore, we prefer the way not to modify Android runtime.  That is,
don't execute LAVA/Abrek directly on
Android environment.

** Yet another agent?

In fact, Android already provide an elegant approach for accessing
target environment, adb (Android Debug
Bridge)[3], which is a versatile tool allowing users to manage the
state of Android-powered device. adb itself
is a client-server program that includes three components:
(1) A client, which runs on your development machine. You can invoke a
client from a shell by issuing an adb command.
(2) A server, which runs as a background process on your development
machine. The server manages communication between the client and the
adb daemon running on the device.
(3) A daemon, which runs as a background process on each device instance.

The adb protocol can be established through USB (device needs to
enable Android USB gadget driver) or
TCP/IP.  adb is very solid and powerful.  For example, if you would
like to test Android UI, you can use the
command on Host side:
$ adb shell monkey -v -p your.package.name 500

The above could be illustrated:

Host commands -- adb protocol (USB or TCP/IP) -- Target receives
the command -- execute monkey

Monkey is a program on Android device that runs on your emulator or
device and generates pseudo-random
streams of user events such as clicks, touches, or gestures, as well
as a number of system-level events.

In this example, your Android application is launched, and 500
pseudo-random events are sent to it.  We call
it as agent-based remote invocation, and it is built-in.

** So, what's agent-based remote validation invocation for LAVA?

There are three key items:
(a) Agent
(b) Remote validation invocation
(c) LAVA

We keep in mind that we make no technical impact to LAVA architecture,
and the Agent is just the helper.
Originally, the client-server communication looks like the following:

LAVA server  LAVA client -- Abrek test suite

Since Python runtime is hard to support, the proposed model would be:

LAVA server -- LAVA client -- Abrek test suite  || adb
extension (host) -- adb (target) - execute command

For integrating test items and benchmarks for Android, this proposal
is running abrek on the host side.
By using Android's standard tool, adb to communicate with the adbd
(adb daemon) on target,  the test case
commands can be issued and the output can return back.  Besides, the
files can be pushed and pull to and
from the target by adb as well.  Sometimes the results may be stored
in certain file on target, and we definitely
could couple with the case.  Thus, running abrek on host side along
with Agent should be a workable approach.

** Show me the use case

The attached patch is just trivial proof-of concept implementation
done by Jeremy Chang that adds a 'monkey'
test definition file for abrek.  Once TCP/IP or USB is ready, for
Android's monkey testing, the procedure is like
as following:
(1) abrek run monkey
(2) abrek dashboard put /anonymous/ monkey1297752359.0

In addition, if we wish to execute certain native application on
Android device, abrek could ask adb to send the
executable files and related data to target first.  Then, execute it
as expected.  The command looks like:
$ adb push my-executable-file /system/bin
$ adb push my-data-file /data
$ adb shell /system/bin/my-executable-file

The above instructions could be refined into adb extension as the
part of LAVA client framework.

That's all.  It could be straightforward and transparent.

Any suggestion is appreciated.  Thank you in advance.

Sincerely,
Jim Huang (jserv)
http://0xlab.org/

[1] https://wiki.linaro.org/Platform/Validation/LAVA/Architecture
[2] https://wiki.linaro.org/Platform/Validation/AbrekTestsuites
[3] http://developer.android.com/guide/developing/tools/adb.html
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: jeremy.ch

Re: Android prelink error by linaro gcc-4.5 + binutils-2.20

2011-02-14 Thread Jim Huang
2011/1/26 Meng-Hsuan Cheng l...@0xlab.org:
 While Android WG was working on integrating Linaro toolchain to Android
 system, we encountered prelink error since there are some empty symbols in
 symtab produced by toolchain linaro gcc-4.5 + binutils-2.20.
[...]
 So I filed a bug in https://bugs.launchpad.net/binutils-linaro/+bug/707487.
[...]

hi luse,

Thanks for reporting.  To clarify, I just make list about the
combination and test results.

Original:
csl-gcc + csl-binutils (binutils-2.20.51) = FAIL

Once the version of linaro-gcc is set to gcc-linaro-4.5-2011.01-1,
binutils tests:
linaro-gcc + binutils-2.19 (FSF) = OK
linaro-gcc + binutils-2.20.1 (FSF) = OK
linaro-gcc + binutils-2.21 (FSF) = FAIL
linaro-gcc + binutils-2.20.51 (CSL) = FAIL
linaro-gcc + binutils-2.20.1 (Google) = OK

Source:
(1) FSF: upstream
(2) CSL: CodeSourcery 2010q3
(3) Google: http://android.git.kernel.org/?p=toolchain/binutils.git;a=summary

Since binutils is not yet maintained by Linaro directly, Android WG
would just take binutils 2.20.1 from Google.

Sincerely,
Jim Huang (jserv)
http://0xlab.org/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev