linaro-dev July 2011

linaro-dev@lists.linaro.org

107 participants
163 discussions

Break in gcc-linaro tarball naming conventions, was: Re: Bug 809768 integration into gcc 4.6 for Linaro Android 1107 release

by Paul Sokolovsky

Hello, Well, before proceeding further, there seems that tarball naming convention has changed. For example, now it's gcc-linaro-4.6-2011.07.tar.bz2 whereas before it was gcc-linaro-4.6-2011.06-0.tar.bz2 . What's worse is that inside it's still gcc-linaro-4.6-2011.07-0 top-level directory. The build script uses tarball basename to find out uncompressed dir name, so builds fail now. This can be worked around on build script level, but is example of random inconsistency, and if let such will proliferate, there will be more and more workarounds everywhere, so would be nice if toolchain WG fixed tarball name on their side. Thanks, Paul On Thu, 21 Jul 2011 10:18:21 +0300 Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote: > On Wed, 20 Jul 2011 21:44:10 +0100 > Chao Yang <chao.yang(a)linaro.org> wrote: > > > Hi Paul, > > > > Just a reminder that the bug was found in gcc 4.6, to which, I > > think, the patch should apply, not 4.5 only. > > Oops, sure, I just copied the wrong link, it should be > http://launchpad.net/gcc-linaro/4.6/4.6-2011.07/+download/gcc-linaro-4.6-20… > instead. > > > > > Thanks and regards > > On 20 Jul 2011 21:12, "Paul Sokolovsky" <paul.sokolovsky(a)linaro.org> > > wrote: > > > Hello Ulrich, > > > > > > On Wed, 20 Jul 2011 21:07:50 +0200 > > > Ulrich Weigand <Ulrich.Weigand(a)de.ibm.com> wrote: > > > > > >> Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote on 07/20/2011 > > >> 08:56:32 PM: > > >> > Michael Hope <michael.hope(a)linaro.org> wrote: > > >> > > Hey, we're getting ahead of ourselves here. The patch clears > > >> > > the problem but it hasn't landed upstream and may not be > > >> > > correct. We also haven't laid the ground work for triaging > > >> > > the problem including: > > >> > > * Describing the compiler involved (mainly how it's built) > > >> > > * Reducing to a test case (normally preprocessed source) > > >> > > * Reproducing and reducing the fault > > >> > > > > >> > > Any fix can introduce other bugs, so it's generally best to > > >> > > work around a last minute issue and then test it properly for > > >> > > the next release. We have a range of options: > > >> > > * Work around it in the packaging (such as changing the > > >> > > optimisation level, turning of debug, etc) > > >> > > * Work around it in the source > > >> > > * Carry a local patch to GCC > > >> > > * Use an earlier release (say 2011.05) > > >> > > > > >> > > We should talk about this in Cambourne especially in > > >> > > untangling what the Android compiler is, how it's built, and > > >> > > adding it as a test case for our releases. > > >> > > > >> > Michael, > > >> > > > >> > Thanks for the feedback. Lets chat at Cambourne. For right now, > > >> > can we reference Ken's tree to build a WIP Android to > > >> > facilitate debugging? Could Ken continue to work with Chao to > > >> > create a testcase that shows the bug? I have our session on > > >> > Wednesday at 11:00 AM now where we can sort out some more > > >> > structural issues. > > >> > > >> [Pulling in Richard on CC as well.] > > >> > > >> Note that by now Richard has done a proper fix of the underlying > > >> compiler problem, which has now landed upstream: > > >> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html > > >> > > >> So my recommendation would be to use this month's Linaro GCC > > >> release with Richard's patch on top as the basis for the Android > > >> compiler. (By next month, I'd assume Linaro GCC will contain > > >> Richard's patch to start with.) > > > > > > That sounds like good plan. So, what process the toolchain team > > > would suggest for this? I can imagine few choices: > > > > > > 1. Toolchain team prepares a tarball for Android team, which is > > > > > http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-20… > > > + http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html > > > 2. Toolchain team creates a bzr branch withich is 2011.07 release > > > (with any possible bugfix releases) + that patch applied. > > > 3. I just add support for applying patches to android-build and > > > build > > > > > http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-20… > > > with the patch applied. > > > > > > My own preference probably would be even p.3, as it doesn't create > > > extra entities, but as we want more people try and adopt Linaro > > > tools, p.1 would be still preferable I guess. > > > > > >> > > >> > > >> Mit freundlichen Gruessen / Best Regards > > >> > > >> Ulrich Weigand > > >> > > >> -- > > >> Dr. Ulrich Weigand | Phone: +49-7031/16-3727 > > >> STSM, GNU compiler and toolchain for Linux on System z and > > >> Cell/B.E. IBM Deutschland Research & Development GmbH > > >> Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: > > >> Dirk Wittkopp > > >> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht > > >> Stuttgart, HRB 243294 > > >> > > > > > > > > > > > > -- > > > Best Regards, > > > Paul > > > > > > Linaro.org | Open source software for ARM SoCs > > > Follow Linaro: http://www.facebook.com/pages/Linaro > > > http://twitter.com/#!/linaroorg - > > > http://www.linaro.org/linaro-blog > > > -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

14 years, 10 months

[PATCH V2] ARM: EXYNOS4: Add support for ORIGEN board

by Tushar Behera

From: JeongHyeon Kim <jhkim(a)insignal.co.kr> Insignal's ORIGEN board is based Samsung EXYNOS4210 SoC. Signed-off-by: JeongHyeon Kim <jhkim(a)insignal.co.kr> Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org> --- Changes for V2: - Reworked based on Kukjin's comments and rebased to kgene/for-next arch/arm/mach-exynos4/Kconfig | 10 +++ arch/arm/mach-exynos4/Makefile | 1 + arch/arm/mach-exynos4/mach-origen.c | 108 +++++++++++++++++++++++++++++++++++ 3 files changed, 119 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos4/mach-origen.c diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index 52fc172..012c034 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -205,6 +205,16 @@ config MACH_NURI help Machine support for Samsung Mobile NURI Board. +config MACH_ORIGEN + bool "ORIGEN" + select CPU_EXYNOS4210 + select S3C_DEV_RTC + select S3C_DEV_WDT + select S3C_DEV_HSMMC2 + select EXYNOS4_SETUP_SDHCI + help + Machine support for ORIGEN based on Samsung S5PV310 + endmenu comment "Configuration for HSMMC bus width" diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile index 2a0b682..ebec49c 100644 --- a/arch/arm/mach-exynos4/Makefile +++ b/arch/arm/mach-exynos4/Makefile @@ -31,6 +31,7 @@ obj-$(CONFIG_MACH_SMDKV310) += mach-smdkv310.o obj-$(CONFIG_MACH_ARMLEX4210) += mach-armlex4210.o obj-$(CONFIG_MACH_UNIVERSAL_C210) += mach-universal_c210.o obj-$(CONFIG_MACH_NURI) += mach-nuri.o +obj-$(CONFIG_MACH_ORIGEN) += mach-origen.o # device support diff --git a/arch/arm/mach-exynos4/mach-origen.c b/arch/arm/mach-exynos4/mach-origen.c new file mode 100644 index 0000000..ed59f86 --- /dev/null +++ b/arch/arm/mach-exynos4/mach-origen.c @@ -0,0 +1,108 @@ +/* linux/arch/arm/mach-exynos4/mach-origen.c + * + * Copyright (c) 2011 Insignal Co., Ltd. + * http://www.insignal.co.kr/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include <linux/serial_core.h> +#include <linux/gpio.h> +#include <linux/mmc/host.h> +#include <linux/platform_device.h> +#include <linux/io.h> +#include <linux/input.h> + +#include <asm/mach/arch.h> +#include <asm/mach-types.h> + +#include <plat/regs-serial.h> +#include <plat/exynos4.h> +#include <plat/cpu.h> +#include <plat/devs.h> +#include <plat/sdhci.h> +#include <plat/iic.h> + +#include <mach/map.h> + +/* Following are default values for UCON, ULCON and UFCON UART registers */ +#define ORIGEN_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \ + S3C2410_UCON_RXILEVEL | \ + S3C2410_UCON_TXIRQMODE | \ + S3C2410_UCON_RXIRQMODE | \ + S3C2410_UCON_RXFIFO_TOI | \ + S3C2443_UCON_RXERR_IRQEN) + +#define ORIGEN_ULCON_DEFAULT S3C2410_LCON_CS8 + +#define ORIGEN_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \ + S5PV210_UFCON_TXTRIG4 | \ + S5PV210_UFCON_RXTRIG4) + +static struct s3c2410_uartcfg origen_uartcfgs[] __initdata = { + [0] = { + .hwport = 0, + .flags = 0, + .ucon = ORIGEN_UCON_DEFAULT, + .ulcon = ORIGEN_ULCON_DEFAULT, + .ufcon = ORIGEN_UFCON_DEFAULT, + }, + [1] = { + .hwport = 1, + .flags = 0, + .ucon = ORIGEN_UCON_DEFAULT, + .ulcon = ORIGEN_ULCON_DEFAULT, + .ufcon = ORIGEN_UFCON_DEFAULT, + }, + [2] = { + .hwport = 2, + .flags = 0, + .ucon = ORIGEN_UCON_DEFAULT, + .ulcon = ORIGEN_ULCON_DEFAULT, + .ufcon = ORIGEN_UFCON_DEFAULT, + }, + [3] = { + .hwport = 3, + .flags = 0, + .ucon = ORIGEN_UCON_DEFAULT, + .ulcon = ORIGEN_ULCON_DEFAULT, + .ufcon = ORIGEN_UFCON_DEFAULT, + }, +}; + +static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = { + .cd_type = S3C_SDHCI_CD_GPIO, + .ext_cd_gpio = EXYNOS4_GPK2(2), + .ext_cd_gpio_invert = 1, + .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL, +}; + +static struct platform_device *origen_devices[] __initdata = { + &s3c_device_hsmmc2, + &s3c_device_rtc, + &s3c_device_wdt, +}; + +static void __init origen_map_io(void) +{ + s5p_init_io(NULL, 0, S5P_VA_CHIPID); + s3c24xx_init_clocks(24000000); + s3c24xx_init_uarts(origen_uartcfgs, ARRAY_SIZE(origen_uartcfgs)); +} + +static void __init origen_machine_init(void) +{ + s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata); + platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices)); +} + +MACHINE_START(ORIGEN, "ORIGEN") + /* Maintainer: JeongHyeon Kim <jhkim(a)insignal.co.kr> */ + .boot_params = S5P_PA_SDRAM + 0x100, + .init_irq = exynos4_init_irq, + .map_io = origen_map_io, + .init_machine = origen_machine_init, + .timer = &exynos4_timer, +MACHINE_END -- 1.7.4.1

14 years, 10 months

IMX53 loco SATA, how to use it?

by Zygmunt Krynicki

Hello everyone. I was wondering if anyone is using the SATA port on IMX53 loco (aka the quick start). The obvious issue is that of no power to drive the hard disk or SSD. Unless you have an eSATA enclosure and an appropriate SATA -> eSATA cable, how would you (or how are you) using this port. Three things come to my mind: 1) Purchase a random ATX power supply unit, connect the 12V rail to the disk, connect the SATA cable to the disk and the board. Short the appropriate cable on the ATX power supply to turn this on. (risky, looks ugly, unsafe). 2) Purchase a USB-SATA dongle, especially the bare-bone model, get a SATA power extender cable, connect one to the USB-SATA board, connect the other to the disk. This way we can power the disk from USB via the adapter and still use the SATA port on IMX. 3) Variant of 2) that could drive 3.25" disks. Purchase a 3.5HDD enclosure, take it apart, assuming it still has cables (not like most 2.5" enclosures that have cable-less connection to the disk) connect just the power cable to the disk and discard the rest. Each solution seems hacky and ugly to me, perhaps one of you has found a better way. Thanks ZK

14 years, 10 months

Creating and Awesome Linaro Android Demo on August 8th

by Zach Pfeffer

Team, George and Stephen have requested a side-by-side Panda demo by August 8th that can be loaded onto 2 SD cards and runs automatically when the Panda boards boot up and features the great work that Linaro has done. Some ideas (thanks to John for a lot of these): Power saving measurements libjpeg-turbo Software decode Software 3-D Hardware 3-D Software decode with power savings Additional functionality in Linaro's builds Music mixing In essence, we'll take a stock Android (Pandroid) and run it against a sooped up Android. We have some time to get this done so hopefully we'll be able to throw something together. Please send out some ideas, I'll get a meeting together to chat more. These things may also be good for TSC drivers. -Zach

14 years, 10 months

[PATCH v2 0/3] Make fault injection available for MMC IO

by Per Forlin

The first version of this patch is a part of mmc non-blocking v9 patchset: [PATCH v9 11/12] mmc: core: add random fault injection change log: v2 - Resolve build issue in mmc core.c due to multiple init_module by removing the fault inject module. - Export fault injection functions to make them available for modules - Update fault injection documentation on MMC IO Per Forlin (3): fault-inject: make fault injection available for modules mmc: core: add random fault injection fault injection: add documentation on MMC IO fault injection Documentation/fault-injection/fault-injection.txt | 5 ++ drivers/mmc/core/core.c | 58 +++++++++++++++++++++ drivers/mmc/core/debugfs.c | 5 ++ include/linux/mmc/host.h | 3 + lib/Kconfig.debug | 11 ++++ lib/fault-inject.c | 2 + 6 files changed, 84 insertions(+), 0 deletions(-) -- 1.7.4.1

14 years, 10 months

[PATCH 0/1] PMWG consolidation tree pull-request

by Amit Kucheria

From: Amit Kucheria <amit.kucheria(a)verdurent.com> (Please bear with pull-request for a single patch, but we're creating a consolidation tree through which we will offer various topic branches for merge into the Linaro kernel in the future) The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc: Linux 3.0-rc7 (2011-07-11 16:51:52 -0700) are available in the git repository at: git://git.linaro.org/people/amitk/linux-linaro-pmwg.git smp Vincent Guittot (1): Add ARM cpu topology definition arch/arm/Kconfig | 25 +++++++ arch/arm/include/asm/cputype.h | 6 ++ arch/arm/include/asm/topology.h | 33 +++++++++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/smp.c | 5 ++ arch/arm/kernel/topology.c | 148 +++++++++++++++++++++++++++++++++++++++ 6 files changed, 218 insertions(+), 0 deletions(-) create mode 100644 arch/arm/kernel/topology.c -- 1.7.4.1

14 years, 10 months

ARM Porting Jam today (14:00 - 18:00 UTC)

by Riku Voipio

Dear ARM fans, Linaro Developer Platform team organises every week (Wednesday 14:00 - 18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to fix userspace portability issues across the board. The list of bugs being worked on is at launchpad: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby… Interested in making the software in Ubuntu run better on ARM? Join us on the #linaro channel on irc.linaro.org today! Cheers, Riku

14 years, 10 months

Please test Android RC builds

by Zach Pfeffer

We've got some RC builds available to test: Android Panda LEB https://android-build.linaro.org/builds/~patrik-ryd/dev1106lebp/ Android Generic Panda https://android-build.linaro.org/builds/~patrik-ryd/dev1106genericp/ Beagle does not boot. I have attached a little script that makes this easy. Go to the build page and copy the start of the boot image's URL. Plug in an SD card and the serial terminal and run: trybuild.sh https://android-build.linaro.org/jenkins/job/patrik-ryd_dev1106lebp/6/artif… /dev/sdd Once its done it'll drop you into a minicom session. For those who test would you mind updating: https://bugs.launchpad.net/bugs/803014 with the type of monitor you used? The build works with some monitors, but not others. Paul, Would you manually test these in validation? Fathi, Please copy these builds as the rc. There's no beagle board build since it doesn't boot. -Zach

14 years, 10 months

Django 1.3 and openid

by Zygmunt Krynicki

Hi. While I was trying to get our docs published on readthedocs.org I stumbled on a odd thing. Apparently they use django 1.3 internally and our requirement on django << 1.3 conflicts with that. I have quickly upgraded lava-server to use 1.3 and (surprisingly) all tests passed. I will play around with 1.3 to see if there are any issues that test suite does not spot. Apart from staticfiles transition (which I just realized can happen in parallel, as we can keep using staticfiles 0.3.4 and django 1.3 (and only transition to contrib.staticfiles or staticfiles 1.x when we wish) I found one issue: openid It seems that the openid backend we are using is somewhat outdated and does not implement the required interfaces. For 1.3 that's okay but 1.4 will not be compatible with that API any more. This causes three tests to be skipped, and a warning message to be logged. I was wondering how we should proceed: 1) Upgrade to latest django-openid-auth/openid in hopes that it works better. 2) Ignore the problem 3) Upgrade as in 1) and fix any missing issues. What do you guys think? ZK

14 years, 10 months

[REMINDER] Linaro Release Meeting Thursday (16:00 - 17:00 UTC)

by Mounir Bsaibes

Meeting Location: on freenode #linaro-meeting Important dates: Thursday 2011-07-21 Freeze date Friday 2011-07-22 Release Candidate & Call for testing. Thursday 2011-07-28 is release date for 11.07 release. Subscribe Linaro Release Team ('linaro-release') to bugs that you think are release blockers. Regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years, 10 months

← Newer
1
...
4
5
6
7
8
9
10
...
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev July 2011