Hi. On snapshots.linaro.org/11.05-daily/ there are now the
following different kinds of snapshot image:
linaro-alip/
linaro-developer/
linaro-graphical-engineering/
linaro-handset-plasma/
linaro-headless/
linaro-multimedia-engineering/
linaro-nano/
linaro-netbook-efl/
...but I can't find anything on the wiki which documents
what each of these images is actually for, which makes it
hard to know which one to choose.
https://wiki.linaro.org/Releases/DailyBuilds
suggests using linaro-headless, but that doesn't seem
to have built since the 18th February. Mail to this list
on the 8th Feb said:
> Please note that the headless and netbook-efl images
> will be replaced by the Nano and Evaluation Ubuntu
> Desktop builds soon
but there hasn't been an official announcement that this
happened -- is linaro-headless now gone, or has it just
failed to build for the past fortnight?
(If it has been obsoleted, how about a readme in
11.05-daily/linaro-headless/ saying "try $elsewhere
instead" ?)
thanks
-- PMM
Hi,
You can see them at
https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-03-01
or below.
Thanks,
James
=== Attendees ===
* Mattias Backman
* Guilherme Salgado
* Deepti Kalakeri
* James Westby
* Jamie Bennett
* Alexander Sack
=== Agenda ===
* Actions from last meeting
* Team status
* Reporting days
* AOB
=== Action Items ===
* james_w to co-ordinate deployment of salgado's patchwork tree in his absence
* james_w to email salgado about patch metrics
* james_w to get deepti a machine to host jenkins
* mabac to request reviews for some svammel changes, and review some code from other team members
* salgado to send deployment docs to the patchwork RT ticket when ready
* james_w to request status reports on Monday
=== Action Items from previous meeting ===
* James to Cc Guilherme on RT for patchwork: DONE
* James to email Guilherme with info on patches(a)linaro.org account: DONE
=== Minutes ===
* Team status reports
* Deepti Kalakeri
* Got hudson/jenkins build and tests of linaro-gcc on her local instance
* Needs access to a hosted instance to make the work public and have it run reliably.
* Mattias Backman
* Project created for BuildFailureBugFiling: https://launchpad.net/svammel. Good progress on the implementation.
* Will create a blueprint for tracking the work
* Will be refactoring to add more unit tests, and add more of the features requested by Steve.
* Will also request some reviews from others for some of the changes, and will also review other people's code in other projects.
* Guilherme Salgado
* Good progress on PatchTracking. Using stgit to manage the patches he has on top of patchwork.
* Got some more positive upstream feedback on patchwork patches.
* Some patches are still awaiting review though, and most have not actually been merged despite favourable review.
* Away for most of 10 days after this week. James will co-ordinate getting a patchwork instance in his absence. There is nothing urgent that should be handled in his absence, but patch tracking implementation will pause for a while.
* Has written some further documentation on deployment, which he will put in the RT ticket to aid IS.
* James will send information that he has on the metrics that management want to see this month.
* James Westby
* Continued excellent response to status.linaro.org. Most urgent requests are dealt with, one still in review. Hopefully the project can be put in to maintainence soon, until the next round of improvements are scheduled.
* Reporting days
* It has been requested that we include our individual weekly reports in the meeting notes, and have them prepared before the meeting for discussion.
* With the timing of our meeting this is a few days before the team status report on Thursday. It's not a big issue to have slightly stale information for that, but it may be that we want to change the day of our meeting anyway.
* Nobody had any problem with the day of the meeting, so we will keep that as it is, and send in status reports before the meeting. James will send reminders appropriately from next week on.
Forwarded for interest; a number of ARM / Linaro folks were involved
last week.
----- Forwarded message from Hector Oron <zumbi(a)debian.org> -----
From: Hector Oron <zumbi(a)debian.org>
Date: Tue, 1 Mar 2011 11:03:02 +0000
To: debian-devel-announce(a)lists.debian.org
Cc: bbrv(a)genesi-usa.com, david(a)toby-churchill.com
Reply-To: debian-embedded(a)lists.debian.org
Subject: Bits from ARM and Embedded Sprint
Mail-Followup-To: debian-devel(a)lists.debian.org
Hello,
During the Debian ARM and Embedded Sprint, we had the opportunity to discuss
and work on the following areas:
ARM ports
---------
* 'armel'
Several FTBFS RC bugs were fixed.
* 'armhf' [0]
Debian package management system (dpkg) assumes that a new ABI is a new Debian
architecture, and that there is a one-to-one mapping between Debian architectures
and triplet names. Upstream GNU tools assume that 'armel' and 'armhf' share the
same GNU triplet. That would make armhf and armel the first Debian architectures
which shared a triplet.
There are several proposals to fix this problem:
* Modify upstream GNU GCC triplets to allow different triplets per ABI
* Introduce a new tuple naming scheme, as detailed in multiarch proposal and
use it as the canonical name in dpkg
We had the opportunity to discuss with GCC upstream engineer (Ramana) about our
distribution problem. The problem was posted to the GCC mailing list [1] and it
looks like there are no major objections against it. A new triplet name might be
adopted for Debian 'armhf', likely to be arm-linux-gnueabi_hf, but discussion it
is still going on between `dpkg' maintainers and GCC upstream folks.
Several NMU uploads were done into the archive adding support for armhf [3].
* Thumb-2 Kernel
Some progress on kernels built in Thumb-2 (continuing Linaro work).
Thumb-2 kernel now seen to boot on efikamx and Freescale mx51evk boards, as
well as OMAP3/4.
[0] http://wiki.debian.org/ArmHardFloatPort
[1] http://gcc.gnu.org/ml/gcc/2011-02/msg00408.html
[2] http://lists.debian.org/debian-devel/2011/02/msg00351.html
[3] http://wiki.debian.org/ArmHardFloatTodo
Please direct any queries about ARM ports to: debian-arm(a)lists.debian.org
Multiarch [0][1][2]
-------------------
* MultiarchCross Wiki page [3] was updated to reflect current status and describe
the creation of a new patch for pkg-config [4] which implements the --host option
described by upstream.
* A phone conference with Steve Lanagsek, Rafael Hertzog and Loic Minier attending
was held to get the team, and ARM engineers, up to speed on Multiarch and the armhf
triplet/tuple naming issue.
* A possible patch for debhelper [5] was created to implement DEB_HOST_MULTIARCH
substitution support in install files. This allows libraries, header files, symlinks
and binaries to be relocated into multiarch-compatible paths when building the package,
using a value passed from dpkg-architecture. A variable needs to be added into
the install location in each install file, together with a small change debian/rules.
Simple tests indicated that ${DEB_HOST_MULTIARCH} should be a suitable placeholder
for the substitution. The change probably needs to be part of a new debhelper
compatibility - compat 9. Packages which do not currently use debhelper would
need to use sed or equivalents to perform the substitution.
* Test packages for this method have been hosted as patches in Emdebian SVN [6],
including the patched version of debhelper, possible patch for gcc-4.5 (via armhf
port development), the patched version of pkg-config and patches for popt and
pcre3. Certain packages are also hosted in an experimental repository [7].
e.g. debian/tmp/usr/lib/libpopt.so.*
lib/ changes to debian/tmp/usr/libx/${DEB_HOST_MULTIARCH}/libpopt.so.*
lib/${DEB_HOST_MULTIARCH}. Binary packages built using this method are available
but ONLY for use within chroots [9]. Please read the README [10] before trying
to use these binaries, it is very easy to completely break your system with the
current test packages. (It is, for example, completely non-trivial to remove
Multi-Arch packages of a foreign architecture which have been force-installed.)
* Some of the notes taken during the meeting can be reviewed at Debian wiki site [8].
[0] http://wiki.debian.org/Multiarch
[1] https://wiki.ubuntu.com/MultiarchSpec
[2] http://wiki.debian.org/Multiarch/LibraryPathOverview
[3] https://wiki.ubuntu.com/MultiarchCross
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217902#28
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614731
[6] http://www.emdebian.org/trac/browser/current/multiarch
[7] http://ftp.uk.debian.org/emdebian-multiarch/
[8] http://wiki.debian.org/MultiarchEmdebianSprint2011
[9] http://ftp.uk.debian.org/emdebian-multiarch/
[10] http://www.emdebian.org/trac/browser/current/multiarch/README
Please direct any query about Multi-Arch to: debian-dpkg(a)lists.debian.org
Bootstrapping a.k.a. Cyclic dependencies issues
-----------------------------------------------
* A discussion session was held to explain the current bootstrapping issues and
proposals. There was lively discussion and lots of good feedback on mechanism
plus ideas on how to develop it into a qa service. Notes of the discussion are
here [4]
* A Debian Bootstrap wiki page has been updated to prepare a specification for
work on breaking cyclic build-dependency loops [0], and making Debian
auto-bootstrappable.
* Patches were created for (debian versions of) poppler, gtk+2.0 and qt4-x11 [1],
and (natty versions of) krb5, poppler, cyrus-sasl, and openldap [2] to implement
Bootstrap dependency support to break circular dependencies when bootstrapping
new and existing architectures. Support is implemented using an environment variable:
DEB_BOOTSTRAP=1. The patches use the existing upstream support in the relevant
packages to turn off functionality and then disable certain binary packages from
being built, so that the temporary bootstrap build can be built without the full
set of build dependencies. The smaller set of build-dependencies is defined in
debian/control as Build-Depends-BootstrapN. Later bootstraps can turn on more of
the functionality until the final build restores the original Debian configuration.
Bootstrap packages are made available to the build process only, via temporary
repositories. All reverse dependencies which managed to build against the bootstrap
packages are rebuilt against the final version before being uploaded to the full
archive. Packages which failed to build against the bootstrap are built against
the full version of the dependency. Typical changes include disabling LDAP
support, turning off CUPS support etc.
Patches are in Emdebian SVN and in Launchpad PPA / bazaar branches
* patch for natty version of dpkg, to
1) make dpkg-checkbuildeps use Build-Depends-BootstrapN when --bootstrap=N is
passed.
2) make dpkg-buildpackage pass --bootstrap=N when env var DEB_BOOTSTRAP=N is
set.
* Alternate patch implementing the scheme using DEB_BUILD_OPTS 'bootstrap=N',
instead of DEB_BOOTSTRAP=N
* Circular bootstrap loops were identified using xdeb [3], which also got improved
when some loops were identified as false positives. The new design aims to prevent
false loops being identified by considering only binary build-deps that are
actually needed, not all the binaries built by a particular source package. This
means that the existing analysis of all 900 packages in maverick base will need
to be re-run to get a more realistic picture.
* xdeb is gaining logic for setting DEB_BOOTSTRAP=N when a bootstrap option is
available.
* Work on getting the same version of xdeb into Debian and Ubuntu was done.
[0] http://wiki.debian.org/DebianBootstrap
[1] http://www.emdebian.org/trac/browser/current/bootstrap
[2] https://code.launchpad.net/~peter-pearse
[3] http://emdebian.org/bootstrap/examples/
[4] http://wiki.debian.org/DebianBootstrap/EmdebianSprint2011
Please direct any queries about bootstrapping to: debian-embedded(a)lists.debian.org
FreedomBox
----------
* A presentation on Freedom Box was made during the sprint [0]
* `Boxer' [1] is a framework to generate optimized images for Freedom Box project
as well as encouraging flexible hacking for developers was started during the
sprint. Boxer contains a list of Debian packages split by sections (at the moment
debug, httpd-apache, httpd-lua, ipv4ll, webchat, xmpp-erlang, xmpp-lua) which can
be enabled and disabled at wish. It is planned to add preseed information as well,
so packages can be tuned to fit Freedom Box requirements in a generic way. Boxer
generates the metadata to be fed into other tools. For example, there are already
hooks acting as git submodules into `live-build' and `multistrap', and potentially
more hooks could be created to support other frameworks.
* Hand drawn drafts for visualizing "The stream of Debian software development"
were done and eventually those might be published at freedombox-discuss mailing
list.
* Other random hacking on sd-installer (a tool to ease Debian installation into
SD/MMC cards) happen.
* Some research for Freedombox User Interface was also done.
[0] http://dr.jones.dk/emdebian/fb/
[1] http://git.emdebian.org/?p=upstream/boxer.git;a=blob;f=README
Please direct any queries about FreedomBox to: freedombox-discuss(a)lists.alioth.debian.org
Flash-kernel
------------
A discussion was held on flash-kernel's issues, the main issues being scalability
to more and more boards, and usage of board-specific data across tools. Various
affected tools were brought up and the proposed improvements to flash-kernel were
discussed, as well as some WIP cleanups [1]. The most important outcome is that
the board data should be split out of flash-kernel entirely and carefully versioned.
The project's wiki page [2] was updated to match the discussion.
[1] http://git.debian.org/?p=users/lool/d-i/flash-kernel.git
[2] http://wiki.debian.org/FlashKernelRework
Please direct any query about flash kernels to: debian-arm(a)lists.debian.org
Cross toolchain support
-----------------------
A group was created on alioth [1] to improve cross toolchain support within Debian
merging efforts from both Emdebian and Linaro packages, some notes were taken
during discussion now summarized in a wiki site [2]. In sumary it was decided to
upload something along the lines of the armel cross-toolchain that was in Ubuntu
maverick for the time being, until a cleaner solution can be acheived once
cross-architecture dependencies are introduced via Multiarch.
[1] https://alioth.debian.org/projects/crosstoolchain/
[2] http://wiki.debian.org/ToolChain/Cross
Please direct any queries about cross toolchain support to: debian-embedded(a)lists.debian.org
The power of grouping and teaming up
------------------------------------
We had the opportunity to watch a documentary by Sugata Mitra: 'The child-driven
education' [0], which shows a bunch of experiments done in children education
environment and showing that they perform much better when they team up. We
would like to share the link to it.
[0] http://www.ted.com/talks/lang/eng/sugata_mitra_the_child_driven_education.h…
References
----------
* http://wiki.debian.org/Sprints/2011/EmdebianSprint
Thanks to
---------
All the attendees being physically at the Sprint Venue, all the remote attendees
via phone or IRC, nice people working at ARM offices, all the wider Debian
community and sponsors collaborating with the event.
Sponsors
--------
* ARM - http://www.arm.com/ - providing hacking room space and lunch.
* Genesi USA - http://www.genesi-usa.com/ - providing dinner for attendees
* Toby Churchill Ltd - http://www.toby-churchill.com/ - providing dinner for attendees
* Debian - http://www.debian.org/ - providing coolest operative system to hack on
We would also like to thank the above companies for letting their employees being
part of the Sprint, as well as Linaro, Canonical, hands.com, dr.jones.dk, and simtec.co.uk.
The sprint worked really well, with lots of input from a good range of people,
with cross-pollination between people's interests, and plenty of concrete outputs
in the form of useful patches and repositories. The balance between hacking an
discussion worked well. ARM's facilities worked really well. Hopefuly we will be
able to run another similar event in the not too distant future.
List of Participants
--------------------
Hector Oron
Neil Williams
Nick Bane
Wookey
Konstantinos Margaritis
SteveMcIntyre
Philip Hands
Daniel Silverstone
Dave Martin
Oliver Grawert
Jonas Smedegaard
David Rusling
Marcin Juszkiewicz
Loïc Minier
Jonathan Austin
Peter Pearse
Jesse Barker
... and random ARM hackers and visitors: Ramana Radhakrishnan, Leif Lindholm,
Javi Merino, Colin Tuckley, Anna Valiente, Siri Reiter, Steve Wiseman, ..
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar System,
which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
----- End forwarded message -----
--
Steve McIntyre, Cambridge, UK. steve(a)einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
Hi All,
In Multimedia WG we have been posed with a question regarding best way
to expose low level API for camera.so this a questions mainly about pros and
cons of v4l2 and omx over each other.So to involve a wider community to
discuss this topic I am floating this mail on linaro-dev.Please share your
view/experiences.Also please involve any body else in this mail who can
provide valuable inputs on this.
Thanks
Sachin
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
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
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
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
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
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
