linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

NOTES] 3/23 Linaro Developer Platform Weekly Status Meeting

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on March 23rd in #linaro-meeting on irc.freenode.net at 16:00 UTC. http://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-03-23 Actions from the meeting where as follows: * slangasek to get dpkg-shlibdeps (and other fixes) uploaded to natty * kunal to publish FTBFS kdebase-workspace to ppa for multiarch debugging Regards, Tom (tgall_foo) Developer Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 10 months

Office of the CTO meeting minutes

by David Rusling

All, the notes can be found here - https://wiki.linaro.org/OfficeofCTO/2011-03-29 Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH

14 years, 10 months

Device Tree on ARM status report - Mar 20

by Grant Likely

I had great hopes of doing these status reports once a week; but it turns out to take more effort to get together that I estimated. Here's the status of ARM device tree support as of today. As always, let me know if you have any corrections or additional information. 1 - Latest news --------------- - The last vestiges of of_platform_bus_type are gone from Linus' tree as of the 2.6.39 merge window. Everything should be using platform_device now. - devicetree/arm on git://git.secretlab.ca/git/linux-2.6 has everything needed to turn on basic device tree support for any platform. - Support has been added for Versatile and Tegra in devicetree/arm - Support for Samsung s5pv310 and Freescale mx5 are in devicetree/test - Similarly, u-boot needs to have the CONFIG_OF_LIBFDT and CONFIG_SYS_BOOTMAPSZ defined to turn on device tree support. - I've also got patches that eliminate the need for CONFIG_SYS_BOOTMAPSZ which I'll post shortly, but they're not quite working yet. - I've also got a trivial patch that should enabled CONFIG_OF_LIBFDT on a large set of boards, but it has had pretty much zero testing. :-) - Jason Hui has been making awesome progress on mx5, and some of their patches are in devicetree/test. Hopefully to move over to devicetree/arm soon. - Shawn Guo has also been making good progress on adding the clock bindings to the mx5 support. There are still questions up in the air about the best way to handle clocks though. While all the clocks /can/ be converted to device tree data, there is also value in sharing clock initialization data between DT and non-DT board support. The of_platform_device_prepare() work mentioned below will help with that. It will also be easier to work on the clock support when the common struct clk patch series from Jeremy gets merged. Until then there ends up being a lot of duplication of code. - Lennert has a series of virq patches for ARM patches completed. He is currently working on cleaning them up to get them posted. - Patches posted for of_platform_prepare() which makes it easier for static platform_device registrations to co-exist with device tree data. Patches are currently in devicetree/test, and will move to devicetree/arm shortly. - Basic DT support has been merged into Nicolas' Linaro kernel tree. - DT is also working on Versatile Express, OMAP, and the new Xilinx platform, but I don't have patches for either of those platforms in my tree. - Rob Herring's work on the early dtb mmu maping is mainlined and makes it much nicer to work with dtbs. Next steps: -------------- At this point I'm putting on my Linaro hat. Feel free to tune out past this point if you're not interested how DT support will materialize in the next release. There are a number of very specific tasks that need to be completed for the 11.05 release. The goal is to have basic device tree support turned on and working on all of the platforms supported in the release. There isn't a lot of time to get this pulled together, but all the infrastructure is in places, so most of the work is turning on the configuration options and testing the platforms. For each board, I need an engineer to do the following: 1) Enable CONFIG_OF_LIBFDT and CONFIG_SYS_BOOTMAPSZ against the Linaro u-boot tree. 2) Enable CONFIG_OF and CONFIG_PROC_DEVICETREE in the kernel 3) Add something like the following to the *existing* machine definition. For initial basic support, you don't need to create a separate <soc>-dt.c board support file yet. +static const char *omap4_panda_dt_match[] __initdata = { + "ti,omap4-panda", + NULL +}; + MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") [...] + .dt_compat = omap4_panda_dt_match, MACHINE_END The string in the match table should be in the form "<vendor>,<board-name>" 4) Add a template .dts file for the board in arch/arm/boot/dts/<board>.dts. The following should be sufficient: /dts-v1/; / { model = "TI OMAP4 PandaBoard"; compatible = "ti,omap4-panda"; #address-cells = <1>; #size-cells = <1>; aliases { }; memory { device_type = "memory"; reg = <0x80000000 0x08000000>; }; chosen { }; }; 5) test it :-) 6) send patches to me for inclusion in the Linaro U-Boot and Kernel trees. I'll collect them to start and ask John and Nicolas to pull them into their trees when they're ready. This is enough for very basic device tree support and I expect it will only take a day or so of effort to get completed. It won't be particularly useful, but it ensures that the infrastructure is enabled and working. Bonus points if you're also able to provide patches that add of_platform_device_probe() and of_platform_bus_populate() calls to the board support so that device nodes get attached to the devices and can be used for attaching things like gpios, spi devices, and i2c devices. This is a nice to have for 11.05, but it isn't a requirement to have it working on all boards. Here is the list of hwpacks that should be supported to the best of my knowledge. Please reply with the hwpacks you can take responsibility for: efikamx igep imx51 omap3-x11-base omap3 overo panda s5pv310 vexpress There are also some specific cross-platform tasks that need some love. Let me know if you can take responsibility for any of these items. - Eliminate CONFIG_SYS_BOOTMAPSZ dependency from U-Boot. I've got a patch series that does this, but it is untested. I'll post the series tomorrow. - Add packaging of .dtb files into linux-image-linaro-* packages. Loic and I discussed putting them under /lib/dtb/`uname -r`/, but thinking about it more, it might make more sense to share the modules directory and use /lib/modules/`uname -r`/dtbs. The dtc tool needed to build the .dtbs is included with the kernel tree. - Add relevant dtb files to boot partition in linaro-image tools - Add boot script which passes dtb as 3rd argument to 'bootm' For purposes of tracking, I'll register bugs for the above items in the Linaro bug tracker tomorrow. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

14 years, 10 months

[PATCH] arm/dt: Add basic device tree support for mx51 babbage board

by Jason Liu

--- No uboot patch since uboot patch already in linaro uboot git Signed-off-by: Jason Liu <jason.hui(a)linaro.org> --- arch/arm/boot/dts/mx51-babbage.dts | 30 ++++++++++++++++++++++++++++++ arch/arm/mach-mx5/Kconfig | 6 ++++++ arch/arm/mach-mx5/board-mx51_babbage.c | 6 ++++++ 3 files changed, 42 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/mx51-babbage.dts b/arch/arm/boot/dts/mx51-babbage.dts new file mode 100644 index 0000000..179f745 --- /dev/null +++ b/arch/arm/boot/dts/mx51-babbage.dts @@ -0,0 +1,30 @@ +/* + * Copyright 2011 Linaro Ltd. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/dts-v1/; + +/ { + model = "Freescale i.MX51 Babbage"; + compatible = "fsl,mx51-babbage"; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + }; + + memory { + device_type = "memory"; + reg = <0x90000000 0x20000000>; + }; + + chosen { + }; +}; diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig index 83ee088..aae51ee 100644 --- a/arch/arm/mach-mx5/Kconfig +++ b/arch/arm/mach-mx5/Kconfig @@ -38,6 +38,7 @@ comment "MX5 platforms:" config MACH_MX51_BABBAGE bool "Support MX51 BABBAGE platforms" select SOC_IMX51 + select MX5_DT_COMMON select IMX_HAVE_PLATFORM_IMX2_WDT select IMX_HAVE_PLATFORM_IMX_I2C select IMX_HAVE_PLATFORM_IMX_UART @@ -114,6 +115,11 @@ config MACH_EUKREA_MBIMXSD51_BASEBOARD endchoice +config MX5_DT_COMMON + bool + select USE_OF + select PROC_DEVICETREE + config MX51_EFIKA_COMMON bool select SOC_IMX51 diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c index b2ecd19..30b92ca 100644 --- a/arch/arm/mach-mx5/board-mx51_babbage.c +++ b/arch/arm/mach-mx5/board-mx51_babbage.c @@ -399,6 +399,11 @@ static struct sys_timer mx51_babbage_timer = { .init = mx51_babbage_timer_init, }; +static const char *mx51_babbage_dt_match[] __initdata = { + "fsl,mx51-babbage", + NULL +}; + MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") /* Maintainer: Amit Kucheria <amit.kucheria(a)canonical.com> */ .boot_params = MX51_PHYS_OFFSET + 0x100, @@ -407,4 +412,5 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .init_irq = mx51_init_irq, .timer = &mx51_babbage_timer, .init_machine = mx51_babbage_init, + .dt_compat = mx51_babbage_dt_match, MACHINE_END -- 1.7.1

14 years, 10 months

[PATCH] ARM: device-tree: Add basic device tree support for Beagleboad

by Tixy

[PATCH] ARM: device-tree: Add basic device tree support for Beagleboad Note, no corresponding U-Boot changes to U-Boot are required as the Linaro version already has these.

14 years, 10 months

Android Build Farm

by Dechesne, Nicolas

Hi there, i have seen what you've started to implement with the Android Build service. I am wondering if: - all the source code / tools you've put in place is available (source code) - how easy (or not) would that be to deploy this infrastructure 'internally' so that we can use it for private builds for example? - what are the requirements on the 'server/host' to be able to replicate this setup? thx, nicolas

14 years, 10 months

Status of the linaro-2.6.38 kernel

by Nicolas Pitre

Hello everyone, As I've been working on the integration of the latest developments and fixes from upstream into the linaro-2.6.38 kernel lately, it became quickly evident that major merge conflicts were to be expected. The problem stems from the fact that we opened the 2.6.38 branch early i.e. around the 2.6.38-rc5 kernel. Many patches that were merged into the Linaro kernel have been subsequently modified by their respective maintainers until they were merged upstream, meaning that what we have now in mainline is different from what the Linaro kernel tree has. This creates several issues: - It is hard to verify that what is in the Linaro tree is actually the latest and the best version of a patch. - Merging additional fixes from upstream often ends up in merge conflicts requiring manual resolution, sometimes non-trivial ones, which is in itself a bug hazard. - People wanting to contribute patches to the Linaro kernel potentially have to create a different patch than what they would submit upstream. Given those issues, I decided to rebuild the linaro-2.6.38 branch from scratch to see where that would bring me. And as could be expected, the result looks nicer and it is much easier to work with than the current tree. For example, this allowed me to merge the latest OMAP support from mainline as is, including the latest fixes, without any need for backport work nor major conflict resolution. Another advantage is that the commit SHA1 references are now identical in most cases to what can be found into mainline. So... my question is: should we switch to this rebuilt tree or not? There are drawbacks with such a move of course: - All the testing done so far would be void. This is however not as bad as this may look as the rebuilt kernel contains fixes for existing bugs in the current tree, and the rebuilt kernel is using patches that have and still are being tested by a wider community. - I didn't forward port a couple series of patches that are available in the current Linaro tree and not in mainline yet, including: * DT support (Grant Likely) * DVFS and PM for OMAP (Vishwanath Sripathy, Vishwanath BS) * Some ux500 fixups (Linus Walleij) * clock debug information (Yong Shen) * Samsung CPUIDLE (Amit Kachhap) So I would prefer if the people responsible for those patches did resubmit their patches once they apply to the new tree (that should be even easier now to apply patches that were meant for mainline). - The history of the rebuilt tree is obviously different from the current tree's. This means special care when updating to the new tree with Git. But overall I think there are more advantages than disadvantages for such a move. What other people think? The current rebuilt tree can be seen at: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.38.git;a=shortlog;h=… or obtained from: git://git.linaro.org/kernel/linux-linaro-2.6.38.git (the "rebuilt" branch) Nicolas

14 years, 10 months

[PATCH] toolchain/build: Fix Linaro Android toolchain linking fail with FDO

by Luse Cheng

Add --with-sysroot to fix Linaro Android toolchain linking fail with FDO --- linaro-build.sh | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/linaro-build.sh b/linaro-build.sh index f238ba8..97da183 100755 --- a/linaro-build.sh +++ b/linaro-build.sh @@ -20,6 +20,7 @@ ARG_WGET_LINARO_GCC_SRC= ARG_BZR_LINARO_GCC_SRC= ARG_WITH_GCC= +ARG_WITH_SYSROOT= ARG_APPLY_PATCH=no @@ -53,6 +54,7 @@ usage() { echo " --prefix=<path> Specify installation path [/tmp/android-toolchain-eabi]" echo " --toolchain-src=<path> Toolchain source directory [`dirname $PWD`]" echo " --with-gcc=<path> Specify GCC source (support: directory, bzr, url)" + echo " --with-sysroot=<path> Specify SYSROOT directory" echo " --apply-gcc-patch=<yes|no> Apply Linaro's extra gcc-patches [no]" echo " --help Print this help message" echo @@ -134,6 +136,9 @@ while [ $# -gt 0 ]; do --with-gcc=*) ARG_WITH_GCC="${ARG#*=}" ;; + --with-sysroot=*) + ARG_WITH_SYSROOT="${ARG#*=}" + ;; --apply-gcc-patch=yes | --apply-gcc-patch=no) ARG_APPLY_PATCH="${ARG#*=}" ;; @@ -149,6 +154,7 @@ done BUILD_ARCH=`uname -m` BUILD_WITH_LOCAL= BUILD_HOST= +BUILD_SYSROOT= if [ "${ARG_TOOLCHAIN_SRC_DIR}" = "" ] || [ ! -f "${ARG_TOOLCHAIN_SRC_DIR}/build/configure" ] ; then error "--toolchain-src-dir is not set or ${ARG_TOOLCHAIN_SRC_DIR} is not ANDROID_TOOLCHAIN_ROOT" @@ -158,6 +164,13 @@ if [ "${ARG_WITH_GCC}" = "" ]; then error "Must specify --with-gcc to build toolchain" fi +if [ "${ARG_WITH_SYSROOT}" != "" ]; then + if [ ! -d "${ARG_WITH_SYSROOT}" ]; then + error "SYSROOT ${ARG_WITH_SYSROOT} not exist" + fi + BUILD_SYSROOT="--with-sysroot=${ARG_WITH_SYSROOT}" +fi + getGCCFrom $ARG_WITH_GCC if [ "x${ARG_APPLY_PATCH}" = "xyes" ]; then @@ -172,7 +185,6 @@ if [ "x${ARG_APPLY_PATCH}" = "xyes" ]; then cd - fi - GCC_VARIANT=`basename ${ARG_LINARO_GCC_SRC_DIR}` GCC_VARIANT=${GCC_VARIANT#gcc-*} @@ -190,6 +202,7 @@ ${ARG_TOOLCHAIN_SRC_DIR}/build/configure \ --prefix=${ARG_PREFIX_DIR} --target=arm-eabi \ --disable-docs --disable-nls \ --host=${BUILD_HOST} --build=${BUILD_HOST} \ + ${BUILD_SYSROOT} \ --with-gcc-version=${GCC_VARIANT} \ --with-binutils-version=2.20.1 \ --with-gmp-version=4.2.4 \ -- 1.7.2.5

14 years, 10 months

Demo at the technical showcase at LDS?

by Michael Opdenacker

Hi, We are looking for volunteers who could run demos and short tutorials at the technical showcase we are organizing at LDS. In particular, we hope that the landing teams will be able to show the newest community boards in action, which almost nobody has seen in real life yet. Here are suggestions: * Power management demos, showing suspend/resume/hibernation and the time they take, measuring power on the board, using powerdebug... * Debugging quick tutorial * perf demos * Toolchain performance benchmarks * Video codec performance benchmarks * Demos of new QEMU targets * linaro-media-create quick tutorial * Device tree demo * Linaro Android Build Service * ... and anything useful you could think of, typically advertising for your contributions to Linaro! The main goal would be to advertise our work, both internally and externally, and then start interesting discussions, and hopefully end up with improvements and new ideas. We will try to videotape some demos and publish them on YouTube if appropriate. There should also be a vote for the best demos and prizes will be given away. I let Kiko and others add their own suggestions. See https://wiki.linaro.org/Events/2011-05-LDS/Showcase/ for details about the event. Thanks in advance, Cheers, Michael. -- Michael Opdenacker, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com + 33 621 604 642

14 years, 10 months

Any DS-5 users out there?

by Pawel Moll

Hi Folks, As some of you may remember, Linaro engineers have access to free DS-5 licenses. If you don't know what DS-5 is, you can stop reading now ;-) If you know what DS-5 is, you may also use it, either on daily basis or just occasionally? I'd be most grateful for letting me know about it. It's nearly 5 months since I presented it at UDS, so I'd love to know whether you found it useful by now. I know that at least some of you tried it, so simple "yes, use it every day, love it" or "well, sometimes, if there's nothing better to do" or maybe "naaah, it's absolutely rubbish" will do. Of course don't hesitate to elaborate more :-) Cheers! Paweł

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev