linaro-dev February 2012

linaro-dev@lists.linaro.org

150 participants
147 discussions

Booting linux-linaro-2.6.37 on Beagle Board

by Avik Sil

Hi, I tried booting linux-linaro-2.6.37 kernel on my beagle board C4. I executed following: 1. Installed linaro on a 4 GB SD card using linaro-image-tools 0.4.1 with hwpack daily snapshot hwpack_linaro-omap3_20110125-0_armel_supported.tar.gz and linaro-natty-headless-tar-20101202-1.tar.gz. It was booting properly on my BB. 2. Cloned linux-linaro-2.6.37. Changed to source directory 3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig 4. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig (enabled EARLY_PRINTK) 5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage 6. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules 7. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install INSTALL_MOD_PATH=/media/rootfs 8. cp arch/arm/boot/uImage /media/boot; sync Everything went on smoothly. Then I put the SD card on BB and powered it on. I got a kernel panic: http://paste.ubuntu.com/560562 Please help me figuring out the problem. Is it because I didn't create uInitrd? If so, then how to create it for ARM? Regards, Avik

11 years, 11 months

ARM A9 oprofile

by Dmitry Antipov

Hello Ming, could you please give some pointers to observe an overall status of oprofile support on ARM A9 cores? IIUC, now it doesn't work without oprofile.timer=1 kernel option, at least for Linus' tree; searching gives a lot of discussion/patches fragments and similar stuff, but I was unable to find a complete patch/git tree/whatever else to try. Thanks in advance, Dmitry

12 years, 2 months

[PATCH v5 0/4] Device tree support for regulators

by Rajendra Nayak

v5 is based on 3.2-rc2 and has the following changes -1- Used microvolt/microamp in bindings instead of uV/uA -2- Added more documentation surrounding regulator-consumer mapping in the core bindings -3- Dropped CONFIG_OF_REGULATOR and use just CONFIG_OF -4- Reused core regulator bindings on Fixed regulator bindings -5- Corrected the gpio binding for Fixed regulator The patches can be found here: git://gitorious.org/omap-pm/linux.git for-dt/regulator For the first 2 patches (1/4 and 2/4) I have dropped Acks from Mark, since they have changed to some extent from the last post and retained the Acks recieved on the last 2 patches (3/4 and 4/4) as they remain unchanged. regards, Rajendra Rajendra Nayak (4): regulator: helper routine to extract regulator_init_data regulator: adapt fixed regulator driver to dt regulator: pass additional of_node to regulator_register() regulator: map consumer regulator based on device tree .../bindings/regulator/fixed-regulator.txt | 29 +++++++ .../devicetree/bindings/regulator/regulator.txt | 54 +++++++++++++ drivers/regulator/88pm8607.c | 2 +- drivers/regulator/Makefile | 1 + drivers/regulator/aat2870-regulator.c | 2 +- drivers/regulator/ab3100.c | 2 +- drivers/regulator/ab8500.c | 2 +- drivers/regulator/ad5398.c | 2 +- drivers/regulator/bq24022.c | 2 +- drivers/regulator/core.c | 82 ++++++++++++++++--- drivers/regulator/da903x.c | 2 +- drivers/regulator/db8500-prcmu.c | 2 +- drivers/regulator/dummy.c | 2 +- drivers/regulator/fixed.c | 62 +++++++++++++++- drivers/regulator/isl6271a-regulator.c | 2 +- drivers/regulator/lp3971.c | 2 +- drivers/regulator/lp3972.c | 2 +- drivers/regulator/max1586.c | 2 +- drivers/regulator/max8649.c | 2 +- drivers/regulator/max8660.c | 2 +- drivers/regulator/max8925-regulator.c | 2 +- drivers/regulator/max8952.c | 2 +- drivers/regulator/max8997.c | 2 +- drivers/regulator/max8998.c | 2 +- drivers/regulator/mc13783-regulator.c | 2 +- drivers/regulator/mc13892-regulator.c | 2 +- drivers/regulator/of_regulator.c | 81 +++++++++++++++++++ drivers/regulator/pcap-regulator.c | 2 +- drivers/regulator/pcf50633-regulator.c | 2 +- drivers/regulator/tps6105x-regulator.c | 3 +- drivers/regulator/tps65023-regulator.c | 2 +- drivers/regulator/tps6507x-regulator.c | 2 +- drivers/regulator/tps6524x-regulator.c | 2 +- drivers/regulator/tps6586x-regulator.c | 2 +- drivers/regulator/tps65910-regulator.c | 2 +- drivers/regulator/tps65912-regulator.c | 2 +- drivers/regulator/twl-regulator.c | 2 +- drivers/regulator/wm831x-dcdc.c | 8 +- drivers/regulator/wm831x-isink.c | 2 +- drivers/regulator/wm831x-ldo.c | 6 +- drivers/regulator/wm8350-regulator.c | 2 +- drivers/regulator/wm8400-regulator.c | 2 +- drivers/regulator/wm8994-regulator.c | 2 +- include/linux/regulator/driver.h | 4 +- include/linux/regulator/of_regulator.h | 20 +++++ sound/soc/codecs/sgtl5000.c | 2 +- 46 files changed, 362 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt create mode 100644 drivers/regulator/of_regulator.c create mode 100644 include/linux/regulator/of_regulator.h

12 years, 7 months

Optimized kernel memcpy/memset

by Christian Robottom Reis

Hey there, I was asked today in the board meeting about the use of NEON routines in the kernel; I said we had looked into this but hadn't done it because a) it wasn't conclusively better and b) if better, it would need to be done conditionally per-platform. But I wanted to double-check that's actually true (and I'm copying Vijay to keep me honest). I have some references: http://lists.linaro.org/pipermail/linaro-toolchain/2011-January/000722.html http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fb… http://www.spinics.net/lists/arm-kernel/msg106503.html http://dev.gentoo.org/~armin76/arm/memcpy-neon_result.txt https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/InitialMemcpy?hi… https://wiki.linaro.org/WorkingGroups/ToolChain/StringRoutines?highlight=%2… Incidentally, this ties into the question sent earlier this week which had to do with Nico's work item in: https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-thumb2 Which IIRC Nico says probably isn't worth it, right? -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

12 years, 7 months

[RFC PATCH] hrtimers: system-wide and per-task hrtimer slacks

by Dmitry Antipov

This patch proposes a system-wide sysctl-aware default for the high-resolution timer slack value, which may be changed from 0 to HRTIMER_MAX_SLACK nanoseconds. Default system-wide and per-task values are HRTIMER_DEFAULT_SLACK. Per-task value isn't inherited across fork(); instead, newborn task uses system-wide value by default, and newborn thread uses it's group leader value. Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org> --- Documentation/sysctl/kernel.txt | 8 ++++++++ include/linux/hrtimer.h | 11 +++++++++++ include/linux/init_task.h | 2 +- include/linux/sched.h | 11 ++++++++--- kernel/fork.c | 9 +++++++-- kernel/futex.c | 4 ++-- kernel/hrtimer.c | 10 +++++++--- kernel/sys.c | 9 ++++----- kernel/sysctl.c | 10 ++++++++++ 9 files changed, 58 insertions(+), 16 deletions(-) diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 6d78841..83b63ed 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -606,6 +606,14 @@ can be ORed together: ============================================================== +timer_slack: + +This value can be used to query and set the default slack for +high-resolution timers, in nanoseconds. The default value is 50 +microseconds, and can be changed from 0 nanoseconds to 1 millisecond. + +============================================================== + unknown_nmi_panic: The value in this file affects behavior of handling NMI. When the diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h index fd0dc30..77169b7 100644 --- a/include/linux/hrtimer.h +++ b/include/linux/hrtimer.h @@ -24,6 +24,16 @@ #include <linux/timer.h> #include <linux/timerqueue.h> +/* + * Default system-wide and per-task hrtimer slack, in nanoseconds. + */ +#define HRTIMER_DEFAULT_SLACK 50000 + +/* + * Reasonable limit for hrtimer slack. + */ +#define HRTIMER_MAX_SLACK 1000000 + struct hrtimer_clock_base; struct hrtimer_cpu_base; @@ -323,6 +333,7 @@ extern ktime_t ktime_get_monotonic_offset(void); DECLARE_PER_CPU(struct tick_device, tick_cpu_device); +extern int default_timer_slack_ns; /* Exported timer functions: */ diff --git a/include/linux/init_task.h b/include/linux/init_task.h index 9c66b1a..b29be0d 100644 --- a/include/linux/init_task.h +++ b/include/linux/init_task.h @@ -178,7 +178,7 @@ extern struct cred init_cred; .journal_info = NULL, \ .cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers), \ .pi_lock = __RAW_SPIN_LOCK_UNLOCKED(tsk.pi_lock), \ - .timer_slack_ns = 50000, /* 50 usec default slack */ \ + .timer_slack_ns = HRTIMER_DEFAULT_SLACK, \ .pids = { \ [PIDTYPE_PID] = INIT_PID_LINK(PIDTYPE_PID), \ [PIDTYPE_PGID] = INIT_PID_LINK(PIDTYPE_PGID), \ diff --git a/include/linux/sched.h b/include/linux/sched.h index 9b13f79..811e034 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1551,11 +1551,11 @@ struct task_struct { struct latency_record latency_record[LT_SAVECOUNT]; #endif /* - * time slack values; these are used to round up poll() and - * select() etc timeout values. These are in nanoseconds. + * High-resolution timer slack value, in nanoseconds. + * Used to round up poll()/select(), nanosleep, futex + * waiting, etc. timeout values of non-realtime tasks. */ unsigned long timer_slack_ns; - unsigned long default_timer_slack_ns; struct list_head *scm_work_list; #ifdef CONFIG_FUNCTION_GRAPH_TRACER @@ -2631,6 +2631,11 @@ static inline int spin_needbreak(spinlock_t *lock) #endif } +static inline unsigned long task_timer_slack(struct task_struct *tsk) +{ + return rt_task(tsk) ? 0 : tsk->timer_slack_ns; +} + /* * Thread group CPU time accounting. */ diff --git a/kernel/fork.c b/kernel/fork.c index b77fd55..6aaff93 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1164,8 +1164,13 @@ static struct task_struct *copy_process(unsigned long clone_flags, #if defined(SPLIT_RSS_COUNTING) memset(&p->rss_stat, 0, sizeof(p->rss_stat)); #endif - - p->default_timer_slack_ns = current->timer_slack_ns; + /* + * New thread inherits the slack from the group + * leader. New process uses system-default slack. + */ + p->timer_slack_ns = (clone_flags & CLONE_THREAD) ? + current->group_leader->timer_slack_ns : + default_timer_slack_ns; task_io_accounting_init(&p->ioac); acct_clear_integrals(p); diff --git a/kernel/futex.c b/kernel/futex.c index 1614be2..a0d302d 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1887,7 +1887,7 @@ static int futex_wait(u32 __user *uaddr, unsigned int flags, u32 val, HRTIMER_MODE_ABS); hrtimer_init_sleeper(to, current); hrtimer_set_expires_range_ns(&to->timer, *abs_time, - current->timer_slack_ns); + task_timer_slack(current)); } retry: @@ -2281,7 +2281,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, HRTIMER_MODE_ABS); hrtimer_init_sleeper(to, current); hrtimer_set_expires_range_ns(&to->timer, *abs_time, - current->timer_slack_ns); + task_timer_slack(current)); } /* diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index ae34bf5..0c56fec 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -51,6 +51,12 @@ #include <trace/events/timer.h> /* + * Default hrtimer slack value, in nanoseconds. May be changed in + * [0..HRTIMER_MAX_SLACK] range through kernel.timer_slack sysctl. + */ +__read_mostly int default_timer_slack_ns = HRTIMER_DEFAULT_SLACK; + +/* * The timer bases: * * There are more clockids then hrtimer bases. Thus, we index @@ -1564,9 +1570,7 @@ long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp, int ret = 0; unsigned long slack; - slack = current->timer_slack_ns; - if (rt_task(current)) - slack = 0; + slack = task_timer_slack(current); hrtimer_init_on_stack(&t.timer, clockid, mode); hrtimer_set_expires_range_ns(&t.timer, timespec_to_ktime(*rqtp), slack); diff --git a/kernel/sys.c b/kernel/sys.c index 4070153..ac32846 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -22,6 +22,7 @@ #include <linux/device.h> #include <linux/key.h> #include <linux/times.h> +#include <linux/hrtimer.h> #include <linux/posix-timers.h> #include <linux/security.h> #include <linux/dcookies.h> @@ -1917,12 +1918,10 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, error = current->timer_slack_ns; break; case PR_SET_TIMERSLACK: - if (arg2 <= 0) - current->timer_slack_ns = - current->default_timer_slack_ns; - else + if (arg2 <= HRTIMER_MAX_SLACK) current->timer_slack_ns = arg2; - error = 0; + else + error = -EINVAL; break; case PR_MCE_KILL: if (arg4 | arg5) diff --git a/kernel/sysctl.c b/kernel/sysctl.c index f487f25..2cd42c6 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -136,6 +136,7 @@ static int min_percpu_pagelist_fract = 8; static int ngroups_max = NGROUPS_MAX; static const int cap_last_cap = CAP_LAST_CAP; +static const int slack_max = HRTIMER_MAX_SLACK; #ifdef CONFIG_INOTIFY_USER #include <linux/inotify.h> @@ -1004,6 +1005,15 @@ static struct ctl_table kern_table[] = { .proc_handler = proc_dointvec, }, #endif + { + .procname = "timer_slack", + .data = &default_timer_slack_ns, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec_minmax, + .extra1 = &zero, + .extra2 = &slack_max, + }, { } }; -- 1.7.7.6

12 years, 8 months

Linaro embedded Linux distro?

by Zach Pfeffer

During ELC a few people asked me if Linaro had something bigger than nano and smaller than Ubuntu that they could use to build stuff. Of course I said Android, but a lot of people actually want a regular Linux platform where they can easily recompile what they need to hack on, add their own libs and scripts and generally work in an "embedded, cross build way." I know there's OpenEmbedded and I've heard of something called "livebuild." Does anyone have anymore info? This class of users is arguably the largest class of people using these boards so creating something targeted at them would allow them to get all the benefits of Linaro in a easy to use fashion. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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

12 years, 8 months

[PATCH v3 0/4] OMAP serial device tree support

by Rajendra Nayak

v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. Patches can be found here.. git://gitorious.org/omap-pm/linux.git for-dt/serial I also had to pull in a fix[2] for DT testing (already in linux-omap master) which was missing as the serial runtime branch[1] was based on an older master commit. Changes in v3: -1- Rebased on latest serial runtime patches -2- Minor typr fixes Changes in v2: -1- Got rid of binding to define which uart is console -2- Added checks to default clock speed to 48Mhz -3- Added compatible for each OMAP family -4- Used of_alias_get_id to populate port.line [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2] http://www.spinics.net/lists/arm-kernel/msg150751.html Rajendra Nayak (4): omap-serial: Get rid of all pdev->id usage omap-serial: Use default clock speed (48Mhz) if not specified omap-serial: Add minimal device tree support ARM: omap: pass minimal SoC/board data for UART from dt .../devicetree/bindings/serial/omap_serial.txt | 10 +++ arch/arm/boot/dts/omap3.dtsi | 31 ++++++++ arch/arm/boot/dts/omap4.dtsi | 28 +++++++ arch/arm/mach-omap2/board-generic.c | 1 - drivers/tty/serial/omap-serial.c | 80 +++++++++++++++---- 5 files changed, 132 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

12 years, 8 months

Re: Wanted: superstar hacker to complete Mono port to armhf

by Hector Oron

Hello Jo, I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI. 2012/2/2 Jo Shields <directhex(a)apebox.org>: > Right now, Mono is available in Debian armhf. This is a hack - what > we're actually doing is building Mono as an armhf binary, but built to > emit soft VFP instructions and using calling conventions and ABI for > armel. This hack works well enough for pure cross-platform code (like > the C# compiler) to run, but dies in a heap for anything complex. > > This situation is a bit on the crappy side of crap. > > In order for Mono on armhf not to be a waste of time, a "true" port > needs to be completed. If I were to make a not-remotely-educated guess, > I'd say it needs about 550 lines of changes, primarily the addition of > code to emit the correct instructions feeling the correct registers in > mono/mini/mini-arm.c plus a couple of tweaks to related headers. > > Upstream have also indicated that they're happy to provide guidance and > pointers on how to implement this port, although they're unable to > provide the requisite code themselves. > > Sadly, unless someone in the community is able to step forward and > contribute here, it's only a matter of time before the armhf packages > are rightfully marked RC-buggy, and 100+ packages need to be axed from > armhf. This would make me sad. -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.

12 years, 8 months

[PATCH 0/4] thermal: Adding generic cpu cooling devices

by Amit Daniel Kachhap

Changes since RFC: *Changed the cpu cooling registration/unregistration API's to instance based *Changed the STATE_ACTIVE trip type to pass correct instance id *Adding support to restore back the policy->max_freq after doing frequency clipping. *Moved the trip cooling stats from sysfs node to debugfs node as suggested by Greg KH greg(a)kroah.com *Incorporated several review comments from eduardo.valentin(a)ti.com Todo: *Report time spent in each trip point along with the cooling statistics *Add opp library support in cpufreq cooling api's Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. 2) This patchset adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes cooling device instance number and may be helpful for cpufreq cooling devices to take the correct cooling action. 3) This patchset adds generic cpu cooling low level implementation through frequency clipping and cpu hotplug. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c). But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. 4)This patchset provides a simple way of reporting cooling achieved in a trip type. This will help in fine cooling the cooling devices attached. Amit Daniel Kachhap (4): thermal: Add a new trip type to use cooling device instance number thermal: Add generic cpufreq cooling implementation thermal: Add generic cpuhotplug cooling implementation thermal: Add support to report cooling statistics achieved by cooling devices Documentation/thermal/cpu-cooling-api.txt | 57 ++++ Documentation/thermal/sysfs-api.txt | 4 +- drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 484 +++++++++++++++++++++++++++++ drivers/thermal/thermal_sys.c | 165 ++++++++++- include/linux/cpu_cooling.h | 71 +++++ include/linux/thermal.h | 14 + 8 files changed, 802 insertions(+), 5 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h

12 years, 8 months

Building Linaro Android from source and replacing the kernel in an Linaro Android build

by Zach Pfeffer

I get these questions a lot so I wrote some blog posts with the exact steps I used. http://www.linaro.org/linaro-blog/2011/09/15/switching-out-a-pre-built-andr… http://www.linaro.org/linaro-blog/2011/09/15/%EF%BB%BFbuilding-a-linaro-and… Enjoy! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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

12 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2012