linaro-dev March 2011

linaro-dev@lists.linaro.org

123 participants
172 discussions

[PATCH] Include support for the new u8500 hardware pack

by Lee Jones

linaro-media-create dies whilst looking for ux500 based files. This amendment allows it to work with old and new hardware packs alike. --- boards.py 2011-03-04 09:02:00.000000000 +0000 +++ boards.py~ 2011-02-01 16:51:45.000000000 +0000 @@ -264,7 +264,7 @@ class Ux500Config(BoardConfig): kernel_addr = '0x00100000' initrd_addr = '0x08000000' load_addr = '0x00008000' - kernel_suffix = 'u*500' + kernel_suffix = 'ux500' boot_script = 'flash.scr' extra_boot_args_options = ( 'earlyprintk rootdelay=1 fixrtc nocompcache '

13 years, 9 months

[PATCH 0/7] support sdhci-esdhc-imx as an OF device

by Shawn Guo

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(-)

13 years, 9 months

Getting rid of update-alternative in cross toolchain packages

by Marcin Juszkiewicz

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

13 years, 9 months

Overo Clock Rate

by Andy Doan

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

13 years, 9 months

beagleXM, hwpacks : a newbie question

by Daniel Lezcano

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

13 years, 9 months

[PATCH 00/12][RFC] Intial Kconfig Fragment Demo

by John Stultz

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

13 years, 9 months

[PATCH] ARM: Samsung: Basic CPUIDLE Support

by Amit Daniel Kachhap

This patch supports cpuidle framework for samsung S5PV310. Currently, Only one idle state is possible to use, but more idle states can be added followed by this patch. Signed-off-by: Jaecheol Lee <jc.lee(a)samsung.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap(a)linaro.org> --- Rebasing the patch for linaro 2.6.38 kernel. This patch adds basic cpuidle infrastructure and fixes the launchpad bug(bug id: 723543). This patch is under review in samsung mailing list. http://www.spinics.net/lists/linux-samsung-soc/msg04268.html arch/arm/mach-s5pv310/Makefile | 1 + arch/arm/mach-s5pv310/cpuidle.c | 87 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-s5pv310/cpuidle.c diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile index 036fb38..c5db0fa 100644 --- a/arch/arm/mach-s5pv310/Makefile +++ b/arch/arm/mach-s5pv310/Makefile @@ -15,6 +15,7 @@ obj- := obj-$(CONFIG_CPU_S5PV310) += cpu.o init.o clock.o irq-combiner.o obj-$(CONFIG_CPU_S5PV310) += setup-i2c0.o time.o gpiolib.o irq-eint.o dma.o obj-$(CONFIG_CPU_FREQ) += cpufreq.o +obj-$(CONFIG_CPU_IDLE) += cpuidle.o obj-$(CONFIG_SMP) += platsmp.o headsmp.o obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o diff --git a/arch/arm/mach-s5pv310/cpuidle.c b/arch/arm/mach-s5pv310/cpuidle.c new file mode 100644 index 0000000..f35b537 --- /dev/null +++ b/arch/arm/mach-s5pv310/cpuidle.c @@ -0,0 +1,87 @@ +/* linux/arch/arm/mach-s5pv310/cpuidle.c + * + * Copyright (c) 2011 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * 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/kernel.h> +#include <linux/init.h> +#include <linux/cpuidle.h> +#include <linux/io.h> + +#include <asm/proc-fns.h> + +static int s5pv310_enter_idle(struct cpuidle_device *dev, + struct cpuidle_state *state); + +static struct cpuidle_state s5pv310_cpuidle_set[] = { + [0] = { + .enter = s5pv310_enter_idle, + .exit_latency = 1, + .target_residency = 100000, + .flags = CPUIDLE_FLAG_TIME_VALID, + .name = "IDLE", + .desc = "ARM clock gating(WFI)", + }, +}; + +static DEFINE_PER_CPU(struct cpuidle_device, s5pv310_cpuidle_device); + +static struct cpuidle_driver s5pv310_idle_driver = { + .name = "s5pv310_idle", + .owner = THIS_MODULE, +}; + +static int s5pv310_enter_idle(struct cpuidle_device *dev, + struct cpuidle_state *state) +{ + struct timeval before, after; + int idle_time; + + local_irq_disable(); + do_gettimeofday(&before); + + cpu_do_idle(); + + do_gettimeofday(&after); + local_irq_enable(); + idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC + + (after.tv_usec - before.tv_usec); + + return idle_time; +} + +static int __init s5pv310_init_cpuidle(void) +{ + int i, max_cpuidle_state, cpu_id; + struct cpuidle_device *device; + + cpuidle_register_driver(&s5pv310_idle_driver); + + for_each_cpu(cpu_id, cpu_online_mask) { + device = &per_cpu(s5pv310_cpuidle_device, cpu_id); + device->cpu = cpu_id; + + device->state_count = (sizeof(s5pv310_cpuidle_set) / + sizeof(struct cpuidle_state)); + + max_cpuidle_state = device->state_count; + + for (i = 0; i < max_cpuidle_state; i++) { + memcpy(&device->states[i], &s5pv310_cpuidle_set[i], + sizeof(struct cpuidle_state)); + } + + if (cpuidle_register_device(device)) { + printk(KERN_ERR "CPUidle register device failed\n,"); + return -EIO; + } + } + return 0; +} + +device_initcall(s5pv310_init_cpuidle); -- 1.7.1

13 years, 9 months

[PATCH V4 0/5] Add MX51 basic DT support

by Jason Liu

From: Jason Liu <Jason Liu jason.hui(a)linaro.org> This patchset adds Freescale i.mx51 device tree support. This is based on git://git.secretlab.ca/git/linux-2.6 devicetree/test This patch has been tested on MX51 babbage board and can boot up succesfully to linux console with DT enabled. Grant, I think it's almost ready for you to merge it. V4: - Add Linaro sign off and copyrightt V3: - prefix the property name with the vendor name as like: "fsl,has-rts-cts" and "fsl,irda-mode" - use the ttymxc0 as the console - add FEC support, nfs can be used now Jason Liu (5): arm/dt: add basic mx51 device tree support arm/dt: add very basic dts file for babbage board serial/imx: parse from device tree support net/fec: check id_entry pointer before using it net/fec: add device tree matching support arch/arm/boot/dts/babbage.dts | 122 +++++++++++++++++++++++++++++++ arch/arm/mach-mx5/Kconfig | 8 ++ arch/arm/mach-mx5/Makefile | 1 + arch/arm/mach-mx5/board-dt.c | 65 ++++++++++++++++ arch/arm/mach-mx5/clock-mx51-mx53.c | 43 +++++++++++- arch/arm/plat-mxc/include/mach/common.h | 1 + drivers/net/fec.c | 25 +++++-- drivers/tty/serial/imx.c | 79 +++++++++++++++++--- 8 files changed, 327 insertions(+), 17 deletions(-) create mode 100644 arch/arm/boot/dts/babbage.dts create mode 100644 arch/arm/mach-mx5/board-dt.c

13 years, 9 months

Linaro 11.05 weekly testing 2011-03-17

by Jamie Bennett

Hi, This is a message sent out once per week to call on our community to help test the Linaro evaluation builds we produce. If you have supported hardware, as found on: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/ please help our initiative by testing the official Linaro Evaluation Build (LEB): Ubuntu Desktop: http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/ and our Community images: Nano: http://snapshots.linaro.org/11.05-daily/linaro-nano/ ALIP: http://snapshots.linaro.org/11.05-daily/linaro-alip/ Developer Tools: http://snapshots.linaro.org/11.05-daily/linaro-developer/ Make your way to: http://wiki.linaro.org/Releases/DailyBuilds for an explanation on how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Regards, Jamie. -- Linaro Release Manager | Platform Project Manager

13 years, 9 months

linaro android build system issues

by Michael Hudson-Doyle

Hi all, For some reason the jenkins instance that powers the android build system isn't auto provisioning slaves from ec2, so builds are being queued but not executed. If you notice this happen and it's blocking you, get an admin (asac, loic, patryk) to go to https://android-build.linaro.org/jenkins/computer/ and click the "provision via ec2" button, and a slave will be started and run the builds. You can click it more than once to get multiple slaves to clear the queue more quickly. The slaves will be de-provisioned after they have been idle for a little while, so we don't need to manually clean up after ourselves. I'll try and figure out what's going on and fix it next week. Cheers, mwh

13 years, 9 months

← Newer
1
...
7
8
9
10
11
12
13
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev March 2011