linaro-dev February 2011

linaro-dev@lists.linaro.org

120 participants
166 discussions

[RFC] Linaro Toolchain for Android and NDK

by Jim Huang

Hello list, I would like to make a proposal about utilizing Linaro toolchain for Android and NDK (Native Development Kit)[1]. ** Motivation There are some different perspectives between Linaro toolchain and Google Android toolchain including technical and non-technical considerations. It doesn't really work if we only replace prebuilt toolchain with Linaro toolchain because of the compatibility of Android system utilities such as ELF prelinker. Also, since Android is developed in relatively closed environment (Google style open source model), a great amount of software components are not always verified by different toolchain or build configurations. This proposal attempts to establish the compact development flow to enable Linaro optimized ARM toolchain to build Android from scratch and verify it transparently. Eventually, Android can be the reference indicator as Linaro toolchain performance and reliability. ** Brief introduction to Google Android toolchain Inside Google, there is a dedicated compiler team working on GNU Toolchain for various purposes including server-side computing, Android, Chrome OS, etc. Google engineers submit patches to upstream for public review and maintain the toolchain for Android. Along with each Android Open Source Prokect (AOSP) release, there is a special branch in korg GIT [2] for hosting the GPL'd toolchain source code modified by Google. Usually, file "README.google" mentioned the summary, but it is not developer friendly because several changes were done within one GIT commit. Please refer to wiki for details: https://wiki.linaro.org/Platform/Android/UpstreamToolchain ** What's wrong with Android upstream Toolchain? In my opinion, list as following: (1) Few information about Google improvement: Sometimes, we have to guess something from implicit GIT commitlog such as "commit gcc-4.4.3 which is used to build gcc-4.4.3 Android toolchain in master"[3]. It is hard to track and get verified carefully. (2) Google specific improvements are absent in recent release, only enabled months later. For example, Google Compiler Team Lead, Dr. Shih-wei Liao, presented the improvements against GNU Toolchain in the middle of 2009.[4]. The report came with several impressive improvements like FDO (Feedback Directed Optimizations) and IPO (Inter-Procedure Optimizations). However, only some of them are public to AOSP and be integrated late in the middle of 2010 (Android Froyo; 2.2). Even FDO was merged in Android Froyo already, but there is few documentation and no robust method to verify by community members such as Linaro engineers. (3) For some reasons, Google tends to deliver stable (old) toolchain plus mainline backport. It is a safe and workable approach, but sometimes developers would expect to use the latest technologies as Linaro aims to bring to the world. (4) Few readable documentation. For example, Google already open its toolchain benchmark suite in early 2010, but there was no document specific to such important components. Furthermore, there was one file gone in public kog GIT, required by automated benchmark process. One year later, Google engineer finally put back the one to public. This implies the unusual way Google developed and delivered software. ** Linaro's Approach to enable latest technologies Linaro android team tries to do: (1) Document Android toolchain and related utilities in korg GIT as possible as we can. (2) Early adaptation of Linaro toolchain to Android build system and verify these output systematically. (3) Backport Google changes to Linaro GCC and review in public. (4) Improve the deployment and validation flow by means of Linaro infrastructure. (5) Build and test Android system with Linaro tools. Then, figure out the regressions caused by Linaro Toolchain and/or aggressive optimizations (6) measure performance gain by Linaro tools The detailed specification in wiki: https://wiki.linaro.org/Platform/Android/Specs/LinaroAndroidToolchain ** Implementation of Linaro toolchain for Android We started from Android style toolchain build and move to Linaro GCC + ARM specific optimizations in mind. The initial work can be obtained by wiki: https://wiki.linaro.org/Platform/Android/Toolchain We plan to maintain the following GIT repositories at least: * android/toolchain/build.git : Linaro-aware build system. Derived from Android toolchain build system, it can handle Linaro-GCC and Linaro snapshot/bzr. * android/toolchain/gcc-patches.git : Patchset to be applied on top of Linaro-GCC release/snapshots The reference builder script output: $ ./linaro-build.sh --help --prefix-dir= Specify where to install (default: /tmp/android-toolchain-eabi) --gcc-src-dir= Specify where linaro gcc source is (in <toolchain>/gcc) --apply-gcc-patch=(yes|no) Apply-patch which in <toolchain>/gcc-patches directory (default: no) Current verified combinations: * gcc-linaro: 4.5-2011.02-0 * binutils: 2.20.1 * gmp: 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=b094d6c4bf572… [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/AndroidOptimizationStu… [5] Android Release Cycle & Phases Draft, https://wiki.linaro.org/Platform/Android/ReleaseCycle

13 years, 7 months

OMAP Cpuidle optimization patches

by Vishwanath Sripathy

Hi Nicole, Could you pls take attached patch set for 2.6.38 Linaro kernel? These are already posted to lo and so far there are no comments. LO Link: https://patchwork.kernel.org/patch/566461/ Attached patches are rebased to latest Linaro .38 kernel. Regards Vishwa

13 years, 7 months

Google Summer of Code

by Loïc Minier

Hey https://wiki.linaro.org/GSoC We're looking at applying as a mentoring organization; we're still working out the details though. If you'd like to act as a *mentor* for a GSoC student this summer, now is the perfect time to add ideas to the list of candidate projects which students will be able to pick from (if we get selected :-) https://wiki.linaro.org/GSoC/IdeasList -- Loïc Minier

13 years, 7 months

[PATCH] ARM: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas

by Dave Martin

Oops, forgot to CC: ----- Forwarded message from Dave Martin <dave.martin(a)linaro.org> ----- Date: Mon, 28 Feb 2011 17:38:12 +0000 From: Dave Martin <dave.martin(a)linaro.org> To: linux-arm-kernel(a)lists.infradead.org Cc: Dave Martin <dave.martin(a)linaro.org> Subject: [PATCH] ARM: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas Various binutils versions can resolve Thumb-2 branches to locally-defined, preemptible global symbols as short-range "b.n" branch instructions. This is a problem, because there's no guarantee the final destination of the symbol, or any candidate locations for a trampoline, are within range of the branch. For this reason, the kernel does not support fixing up the R_ARM_THM_JUMP11 (102) relocation in modules at all, and it makes little sense to add support. The symptom is that the kernel fails with an "unsupported relocation" error when loading some modules. Until fixed tools are available, passing -fno-optimize-sibling-calls to gcc should prevent gcc generating code which hits this problem, at the cost of a bit of extra runtime stack usage in some cases. The problem is described in more detail at: https://bugs.launchpad.net/binutils-linaro/+bug/725126 Only Thumb-2 kernels are affected. This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE when building a Thumb-2 kernel. Signed-off-by: Dave Martin <dave.martin(a)linaro.org> --- arch/arm/Kconfig | 31 +++++++++++++++++++++++++++++++ arch/arm/Makefile | 4 ++++ 2 files changed, 35 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5cff165..196f6d2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1371,6 +1371,37 @@ config THUMB2_KERNEL If unsure, say N. +config THUMB2_AVOID_R_ARM_THM_JUMP11 + bool "Work around buggy Thumb-2 short branch relocations in gas" + depends on THUMB2_KERNEL && MODULES + default y + help + Various binutils versions can resolve Thumb-2 branches to + locally-defined, preemptible global symbols as short-range "b.n" + branch instructions. + + This is a problem, because there's no guarantee the final + destination of the symbol, or any candidate locations for a + trampoline, are within range of the branch. For this reason, the + kernel does not support fixing up the R_ARM_THM_JUMP11 (102) + relocation in modules at all, and it makes little sense to add + support. + + The symptom is that the kernel fails with an "unsupported + relocation" error when loading some modules. + + Until fixed tools are available, passing + -fno-optimize-sibling-calls to gcc should prevent gcc generating + code which hits this problem, at the cost of a bit of extra runtime + stack usage in some cases. + + The problem is described in more detail at: + https://bugs.launchpad.net/binutils-linaro/+bug/725126 + + Only Thumb-2 kernels are affected. + + Unless you are sure your tools don't have this problem, say Y. + config ARM_ASM_UNIFIED bool diff --git a/arch/arm/Makefile b/arch/arm/Makefile index c22c1ad..ef5105a 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -105,6 +105,10 @@ AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mau AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W) CFLAGS_THUMB2 :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN) AFLAGS_THUMB2 :=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb +# Work around buggy relocation from gas if requested: +ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y) +CFLAGS_MODULE +=-fno-optimize-sibling-calls +endif endif # Need -Uarm for gcc < 3.x -- 1.7.1

13 years, 7 months

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

by Jeremy Chang

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. Signed-off-by: Jeremy Chang <jeremy.chang(a)linaro.org> --- init.omap3.sh | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/init.omap3.sh b/init.omap3.sh index 997ee03..a740236 100755 --- a/init.omap3.sh +++ b/init.omap3.sh @@ -15,3 +15,5 @@ do ;; esac done < /proc/cpuinfo + +netcfg usb0 dhcp -- 1.7.1

13 years, 7 months

u-boot overwrites 'bootargs' from dt 'chosen' node

by Shawn Guo

I'm still a little bit new to dt. I thought the bootargs in chosen node will always apply when dt is enabled. It just took me some time to figure out that u-boot 'bootargs' env will anyway overwrite the one from chosen. static int bootm_linux_fdt(int machid, bootm_headers_t *images) { ...... fdt_chosen(*of_flat_tree, 1); ...... } int fdt_chosen(void *fdt, int force) { ...... /* * Create /chosen properites that don't exist in the fdt. * If the property exists, update it only if the "force" parameter * is true. */ str = getenv("bootargs"); if (str != NULL) { path = fdt_getprop(fdt, nodeoffset, "bootargs", NULL); if ((path == NULL) || force) { err = fdt_setprop(fdt, nodeoffset, "bootargs", str, strlen(str)+1); if (err < 0) printf("WARNING: could not set bootargs %s.\n", fdt_strerror(err)); } } ...... } The 'force' is hard-coded as 1, so it always overwrites. Knowing that may save your some time, if you are green hands as me ;) -- Regards, Shawn

13 years, 7 months

Multimedia WG weekly call meeting minutes

by Sachin Gupta

Hi All, Please find enclosed link to minutes and actions for multimedia wg meeting on 22nd Feb 2011. https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-02-22 Summary - pulse audio patch for assembler errors upstreamed - panda boot problems resolved - Jpeg neon optimisations forward port from android libjpeg to libjpeg 8b pushed to git - System metrics app first version pushed to git - ffmpeg AAC encoder not the right target for neon optimisation as doesnot produce right sound quality Thanks Sachin

13 years, 7 months

Important: Reservation details for Linaro Developer Summit in Budapest, 9-13 May

by Stephen Doel

Hi All, I want to bring to your attention some important logistic points around the Developer Summit in Budapest from 9 - 13 May ( https://wiki.linaro.org/Events/2011-05-LDS) 1. Please register your attendance now: https://forms.canonical.com/udsreg/ . I'd like you to do this even if you haven't yet booked your flights and so on, as we're using this attendee list to drive a lot of our planning for the week 2. You must make a room reservation at the hotel before* 8 April* to benefit from our discounted rates, and to ensure you're staying where all the action is happening ( https://wiki.linaro.org/Events/2011-05-LDS#Hotel%20Booking) 3. Bookmark https://wiki.linaro.org/Events/2011-05-LDS and check it regularly, as we will grow the amount of information there to explain what's happening and how to get the most out of the Summit as we get closer to May (I'll also send periodic e-mails to update you all) -- Thx Stephen Doel Linaro Ltd Chief Operating Officer +44 77 66 014 247

13 years, 7 months

Free (as in freedom) website graphics traces

by Alexandros Frantzis

Hi all! Web browsing is one of the most common and important activities performed on modern consumer mobile devices. As such, it receives special attention in our benchmarking blueprint. In order to have reproducible and automatic benchmarking for web browsing, we need to acquire graphics traces for browsing sessions that can be played back at a later time. Both cairo (used in Gecko and WebkitGtk) and Qt provide mechanisms for performing graphics operation capture and playback. Unfortunately, due to copyright restrictions, we are only able to redistribute traces captured from websites that license their content under a Free license. We have set up a wiki page that contains a preliminary list of websites that we can use in this way: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Docs/WebsiteTraces Please feel free to add any other websites that are suitable for this purpose. Furthermore, to assist with website trace capture we have created a set of tools that load and scroll a set of webpages using the most common rendering engines. There is currently support for Gecko, WebkitGtk and QtWebkit. These tools may prove useful for other groups, too. You can find more information in the wiki page linked above. Thanks, Alexandros

13 years, 7 months

Notes & Actions: Linaro Graphics Working Group - Feb 23, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-02-23 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Summary ======= * cairo-gles: Patchset "EGL fixes" accepted in cairo master (last commit: 00ffb09) * cairo-gles: Very compelling proposal for dealing with desktop OpenGL functionality not in OpenGL ES. * kwin: Performance enhancement patch accepted in * kwin: 5 patches out for review by upstream \o/!!! * compiz: remainder of legacy matrix related vertex processing done (all work now in vertex shaders with no built-ins). * DRI/Mali: git repo in progress, bug fixes to build configuration for UMP and device driver. * UDS-O: All but one team member confirmed attending and on internal wiki. Thanks, -- - Alexandros

13 years, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2011