Hi,
The Android team weekly report for 2011-03-17 is now available and can
be found at:
https://wiki.linaro.org/Platform/Android/Status/2011-03-17
The report is also reproduced in full below.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
--
* Period: (20110310-20110316)
* PM: JamieBennett <jamie.bennett(a)linaro.org>
* Past reports : https://wiki.linaro.org/Platform/Android/Status
== Key Points for wider discussion ==
* Are there Android related requirements from the Landing and Working
Group teams for next cycle?
== Team Highlights ==
* Noritsuna demonstrated a linaro-android powered robot. A video of it
in action can be see at:
http://www.youtube.com/watch?v=8EgfAk5RBVo
* More details on the robot can be found at:
http://www.siprop.org/ja/2.0/index.php?product/AutoChasingTurtle
* Most of the Android related Blueprints were triaged and split up
where necessary. A full list can be found at:
https://blueprints.launchpad.net/linaro-android
* Some benchmarking of Linaro GCC 4.5 with Android has been done with
positive results. The full results can be found at:
https://wiki.linaro.org/Platform/Android/Toolchain
* The Linaro Evaluation Build of Android now fully supports the Beagle
XM platform. More work is being done for the ST-E U8500 and TI Panda
boards.
* Work on the toolchain build system based on Googles own continues.
Bug:731477 was fixed and code pushed upstream at
https://review.source.android.com//#change,21761
* The consolidation of common code is being reviewed. Jeremy Chang sent
several patches to the linaro-dev list which are now being merged.
== Upcoming Deliverables ==
* None.
== Risks / Issues ==
* '''HIGH IMPACT''': The recent earthquake and Tsunami in Japan has
meant that work has stalled for some of the engineers. All are reported
to be OK but KJ-nabe & An were worst affected as their company premises
were badly hit. They may not be back for a couple of months (1 week).
* '''HIGH IMPACT''': Currently the Linaro Android efforts are based on
2.6.37 but with Linaro moving to 2.6.38 and the upstream Android 2.6.38
kernel being available some rebasing efforts will be needed. John
Stultz, Patrik Ryd and others need to discuss how this can be done in
the smoothest way (4 weeks). Some amount of effort will be needed but
that effort is unclear at this point. Will lower level after initial
investigations if necessary. Investigations have started.
* '''MEDIUM IMPACT''': Contribution agreements with Google for AOSP
development still waiting to be approved for Alexander Sack and Patrik
Ryd (2 weeks).
* '''MEDIUM IMPACT''': Patrik’s Panda board is lost in the postal
system atm. Sent by Mounir from IBM, Patrik is chasing tracking numbers
(2 weeks).
== Miscellaneous ==
* Wiki pages of note this week:
* https://wiki.linaro.org/Platform/Android/Toolchain
* http://wiki.linaro.org/Platform/Android/UpstreamNDK
* https://wiki.linaro.org/Platform/Android/UpstreamToolchain
Hi,
The Developer Platform team weekly report for 2011-03-17 is now
available and can be found at:
https://wiki.linaro.org/Platform/DevPlatform/Status/2011-03-17
The report is also reproduced in full below.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
--
* Period: (20110310-20110316)
* PM: JamieBennett <jamie.bennett(a)linaro.org>
* Past reports : https://wiki.linaro.org/Platform/DevPlatform/Status
* Burndown information : http://status.linaro.org/linaro-foundations.html
== Key Points for wider discussion ==
* lttng changes to the kernel currently break OMAP4, a fix is needed soon.
== Team Highlights ==
* lttng has been packaged into the kernel tree. It is reported working
on on i.MX51 and OMAP3 but fails on OMAP4, in fact it breaks OMAP4 even
when not enabled. Avik Sil is investigating.
* Temporary 2.6.38 kernel has been created as John Rigby stages some
changes before they go into Nicolas' tree. This can be found at:
http://git.linaro.org/gitweb?p=people/jcrigby/linux-linaro-2.6.38-alt.git;a…
* Support for the ST-E U8500 HREF board has been enabled in
u-boot-linaro-next. After a round of feedback from the ST-E Landing Team
this work will be pushed upstream.
* linaro-graphical-engineering and linaro-multimedia-engineering are
being built again.
* Work continues on xdeb with some dependency graphing issues fixed.
* Cross-toolchain glibc patches sent to the debian-glibc mailing list
for review.
* Initial multiarch support has landed in the Ubuntu archive.
/lib/libc.so.6 is no more! dpkg, apt, gcc, eglibc, debhelper,
pkg-config, cdbs all got pushed.
* The latest upstream branch of ltrace has been merged into
ubuntu/natty/ltrace to enable Thumb-2 support.
== Upcoming Deliverables ==
* Beta Freeze 2011-03-24
* New build of Linaro Linux kernel
* systemtap v1.3 + cherry-picked fixes
* apt fixes to Ubuntu
* New dpkg to Ubuntu that implements support for the final multi-arch
library paths
== Risks / Issues ==
* '''MEDIUM IMPACT''': Peter Pearce reports that bootstrapping & making
cross-compile patches upstreamable are slowing the rate of package
fixing. The (current) alip package list will not be complete for beta
freeze
* '''LOW IMPACT''': Multiarch has broken a few unexpected packages such
as cmake, apt and linaro-image-tools. These are being worked on.
* '''LOW IMPACT''': There is not much manual test coverage for U8500,
Samsung Orion, iGEPv2, iMX51, Overo hardware.
== Miscellaneous ==
* None.
This patch set is to support sdhci-esdhc-imx as an OF device. As
there is already powerpc based esdhc OF support, it chose to add OF
support for imx esdhc driver in a different way from what sdhci-tegra
did.
It consolidates sdhci_pltfm_data sdhci_of_data into sdhci_data and get
sdhci-esdhc-imx work with both platform bus and OF.
The first patch is not related to imx esdhc OF support, but we need it
to fix the following show-stopper issue.
https://bugs.launchpad.net/bugs/723159
Hi Nicolas,
The fix has already been merged by Sascha, so you may want to apply it
on Linaro tree to get rid of the problem.
Regards,
Shawn
Richard Zhu (1):
mx51 enchance the sd/mmc HW timing compatibility on mx51 boards.
Shawn Guo (6):
arm/dt: add pad configurations for mx51 babbage
mmc: make the reference to sdhci_tegra_dt_pdata conditional
mmc: consolidate sdhci_pltfm_data and sdhci_of_data into one
mmc: support sdhci-esdhc-imx as an OF device
arm/dts: babbage: add device nodes for esdhc
dt: update fsl-esdhc bindings for imx esdhc OF support
.../devicetree/bindings/mmc/fsl-esdhc.txt | 5 +-
arch/arm/boot/dts/babbage.dts | 14 +++
arch/arm/mach-mx5/board-dt.c | 94 ++++++++++++++++++++
arch/arm/plat-mxc/include/mach/iomux-mx51.h | 40 ++++----
drivers/mmc/host/Kconfig | 7 +-
drivers/mmc/host/Makefile | 3 +-
drivers/mmc/host/sdhci-cns3xxx.c | 3 +-
drivers/mmc/host/sdhci-dove.c | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 19 ++--
drivers/mmc/host/sdhci-of-core.c | 53 +++++++----
drivers/mmc/host/sdhci-of-esdhc.c | 28 +++---
drivers/mmc/host/sdhci-of-hlwd.c | 20 +++--
drivers/mmc/host/sdhci-of.h | 10 +--
drivers/mmc/host/sdhci-pltfm.c | 49 +++++-----
drivers/mmc/host/sdhci-pltfm.h | 18 ++--
drivers/mmc/host/sdhci-tegra.c | 10 +-
drivers/mmc/host/sdhci.h | 15 +++
include/linux/mmc/sdhci-pltfm.h | 35 -------
18 files changed, 267 insertions(+), 158 deletions(-)
Some time ago I looked at cross toolchain packages to find how they
handle installation of several versions at same time. It was done by
using 'update-alternatives' tool and was broken. We fixed it during
Ubuntu/Maverick cycle but "u-a" is still in use (just versions are used
now to take care of priority so latest gcc is default one).
But this is different then native gcc which is selected by gcc-defaults
package - /usr/bin/gcc is symlink to /usr/bin/gcc-DEFAULTVERSION (where
DEFAULTVERSION value depends on architecture and distribution). Ok, we
have gcc-defaults-armel-cross in Ubuntu but it takes care only of
depending on default versions of cross toolchain components.
I filled a bug [1] about it and discussed it with Matthias Klose. The
proper way would consists those steps:
- new cross packages will use "u-a remove" to get rid of old alternative
stuff (in
postinst and prerm)
- new gcc-defaults-armel-cross package will
provide /usr/bin/arm-linux-gnueabi-APP
symlinks
- new gcc-defaults-armel-cross will also conflicts with older versions
of cross toolchain
packages
Getting rid of symlinks was accepted during Emdebian sprint so such
change will be done in gcc-4.[3456] source packages. gcc-defaults for
other cross architectures then armel will need to be done for Emdebian.
What do you think about such plan?
1. https://bugs.launchpad.net/bugs/676454
Ash Charles of Gumstix recently noted that the Linaro image for Overo
seemed to perform slower than the one they create.
I've spent a little time investigating this. I'm not familiar with
this type of code and apologize if my terminology is off. However, I
think there's an issue in the Linaro uboot and/or kernel preventing my
Overo Tide from running at a higher clock rate. (We are running at
500mhz but its capable of 720mhz)
I first tried passing "mpurate=720" as a kernel command line option, but
I noticed /proc/cpuinfo was not showing 499.92 BogoMips. I then started
looking at dmesg traces and noticed this difference:
= Overo Kernel:
Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
= Linaro Kernel:
Clocking rate (Crystal/Core/MPU): 26.0/224/500 MHz
Reprogramming SDRC clock to 224791666 Hz
dpll3_m2_clk rate change failed: -22
So I believe the first problem is that the kernel tries the wrong core
clock rate. On a hunch I replaced my Linaro u-boot with the Overo
u-boot. That corrected the "clocking rate" message from the kernel.
However, I still was showing 499.92 BogoMips. I looked at dmesg again
and noticed this message difference:
= Overo Kernel:
Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/332 MHz
= Linaro Kernel:
Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/720 MHz
This leads me to believe the mpurate parameter isn't works differently
in the two kernels. I grepped around for other parameters I might be
able to pass our kernel and didn't really find anything.
So I think there may be two Linaro issues here:
1) u-boot setting up or passing incorrect clock rate
2) kernel not handling mpurate parameter correctly
I'll try and dig around some more, but any pointers would be much
appreciated.
-andy
Hi all,
I am trying to get the network to work with qemu-system-arm -M beaglexm
but without success.
I followed the instructions at
https://wiki.linaro.org/Releases/MilestoneBuilds and booted a virtual
machine for a beagle XM. But there is not network interface.
After googling it appears the network card needs the smsc95xx driver.
This is fine, it is present in the hwpacks. I am able to load the module
but no usb0 interface appears. I am wondering if the ehci module is not
needed too, but this one is not present in any hwpacks.
I am wrong or did I missed something ?
Thanks
-- Daniel
This patch set provides enough to demo how the Kconfig fragment
based defconfigs could be used to simplify both generating and
managing the configs used to build Linaro kernels.
This is for the kernel config managment tool and dependent bluprints:
https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-config-man…
The basic idea is to use a Kconfig fragment to generate the
per-board defconfigs. The Kconfig fragments contain a meta-option
that defaults to yes, which then selects the needed config values
to enable a system.
This has been proposed by others, and we're using Stephen
Rothwell's initial patch to start things off.
Once we have the infrasturcture to use Kconfig fragments for
defconfigs we had to overcome some limitations:
1) We cannot select items from a choice block
2) We need a way to select for values and modules.
Limitation #1 is resolved by a patch to the kbuild system I
made.
Limitation #2 is unsolved, but Jason Hui found a workaround that
is sufficient. Basically we can just redefine the default with a
short declaration:
config VAL
default 256
or
config VAL
default m
With these two solutions, I went forward generating basic Kconfig
fragments for omap3, imx51 and vexpress.
Getting per-board defconfigs is only of limited value, because
we also want to be able to have a common policy settings for
Linaro kernels. Many distros run into this problem, and use
.config fragments which are then assembled at package build
time.
My solution is to have a Kconfig.distro file, which is patched
with Distro specific policy config, such as which filesystems
should be enabled, networking policy, debug options, or periphrial
driver modules that should be enabled. Basically anything that
isn't hardware specific (by that I mean, part of the architecture
or wired on the board).
>From there, I add in as much of the generic Linaro config policy
as I could, utilizing the config files that were used to build
the omap3, imx51 and vexpress hardware packs.
Since the Linaro config polciy is not unified at this point
(in other words, each board has totally different set of generic
policy options configured). I added the per target differences
into the board kconfig fragments.
Ideally we can review and settle down on specific linaro config
policy and this generic per-board stuff can go away.
These are initial and rough patches, but are the result of lots
of painful manual labor to match the Linaro .configs as closely
as possible.
There are a few remaining issues, but these can probably be
worked around:
1) Omap has a strange tristate choice option for the usb gadget
options. So you can only pick one, or you can pick multiple items
as modules. My choice selection patch doesn't yet address this.
I need to see how common this style of choice is and see if we
can either just make it a non-choice options block or if other
fixes are needed.
2) Not having a module selction is a little painful, as the
module "default m" entries are numerous and annoyingly separate
from the meta-config selects.
3) The Kconfig.distro file should be probably broken up into
policy topics, like networking, filesystems, peripherials, etc.
4) The current board Kconfig fragments are named slightly
differently from the standard defconfigs to allow testing
with both. That will need to be fixed, and the old defconfigs
removed prior to submitting.
5) The igep, overo, and panda configs all use the same omap3
config according to the hwpacks. I'm not sure I believe that,
but went along with it to get this out the door.
Many thanks to Jason for his help figuring out an approach here.
Feedback and thoughts would be greatly appreciated.
thanks
-john
CC: Grant Likely <grant.likely(a)secretlab.ca>
CC: Jason Hui <jason.hui(a)linaro.org>
CC: patches(a)linaro.org
John Stultz (11):
kbuild: Allow configs from choice blocks to be selected.
kbuild: Use kconfig defaults as defconfig starting point
kbuild: Avoid kconfig fragment defconfigs from having odd config
order
Add blank Kconfig.distro fragment file
Initial omap3 Kconfig fragment
Initial imx51 defconfig fragment
Add initial vexpress defconfig fragment
Add Linaro config policy to Kconfig.distro
omap3 kconfig fragment changes to align with linaro build
Update imx51 to better match linaro configs
Update vexpress to be closer to linaro config
Stephen Rothwell (1):
kbuild: Enable building defconfigs from Kconfig files
Kconfig.distro | 1754 +++++++++++++++++++++++++++++
arch/arm/configs/Kconfig.imx51 | 503 +++++++++
arch/arm/configs/Kconfig.omap3 | 2430 ++++++++++++++++++++++++++++++++++++++++
arch/arm/configs/Kconfig.vexp | 234 ++++
scripts/kconfig/Makefile | 16 +-
scripts/kconfig/symbol.c | 15 +-
6 files changed, 4949 insertions(+), 3 deletions(-)
create mode 100644 Kconfig.distro
create mode 100644 arch/arm/configs/Kconfig.imx51
create mode 100644 arch/arm/configs/Kconfig.omap3
create mode 100644 arch/arm/configs/Kconfig.vexp
--
1.7.3.2.146.gca209
