linaro-dev August 2010

linaro-dev@lists.linaro.org

62 participants
82 discussions

by James Westby

Hi all, Scott asked me to take a look at the hwpack spec: https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks I took the liberty of editing it somewhat to make the definition of a hardware pack clearer, and remove some contradiction in the implementation suggestions. I have some questions about the goals of the spec though: 1. Do we support installing more than one hardware pack on an image? 2. What is the purpose of the hwpack.deb that is mentioned in places? 3. Do we want to be able to pull in new versions of a hwpack on request, or should it just be a case of updating the image, with a hwpack-install call if you want to install a newer version that pulls in new packages? 4. Do we want to support cross-installation in any way? 5. What are the use cases for tags? I can only see X/no X in the spec. 6. What are the use cases for support information? There is also one larger question, which is that I disagree that we shouldn't provide anything that will go in a hardware pack in the linaro images. I think that having the images be useful by themselves has lots of benefits. - Being able to quickly spin up an image in QEMU makes for easier testing. - Requiring a hardware pack for every operation will make some things more tedious. - If everything in a hardware pack becomes more consolidated then hardware packs probably become less useful. Thanks, James

14 years, 3 months

Re: Hardware pack questions

by James Westby

[ resending with the correct address ] On Fri, 27 Aug 2010 14:03:32 -0400, James Westby <james.westby(a)canonical.com> wrote: > On Fri, 20 Aug 2010 16:26:46 -0400, James Westby <james.westby(a)linaro.org> wrote: > > There is also one larger question, which is that I disagree that we > > shouldn't provide anything that will go in a hardware pack in the linaro > > images. I think that having the images be useful by themselves has lots > > of benefits. > > > > - Being able to quickly spin up an image in QEMU makes for easier > > testing. > > - Requiring a hardware pack for every operation will make some things > > more tedious. > > - If everything in a hardware pack becomes more consolidated then > > hardware packs probably become less useful. > - Not having a flag day where suddenly our images aren't installable > and hwpack-install has to work well, and before that date we can't > test hwpack-install on the images we produce. > > Having not had anyone convince me that stripping our images is the right > thing to do I have carried on attempting to write the spec without > requiring this. There will be a few issues, such as ensuring that the > kernel we want is the one that boots, but we have that problem on hwpack > upgrades anyway, so it doesn't go away by stripping the images. > > I have > > https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks > > to a state where I am happy to start implementation now. Feedback on the > spec is still welcome, and things will still be subject to change. In > particular there are still a number of TODOs in the spec where I don't > know how to proceed, but I believe that none of those block us starting > implementation of other parts. > > Is the current status quo to create specs under the "linaro" project on > Launchpad? I'll create a spec for this so that we can track work items > for it. > > Thanks, > > James >

14 years, 3 months

[PATCH] OMAP CPUIDLE: CPU Idle latency measurement

by vishwanath.sripathy＠linaro.org

From: Vishwanath BS <vishwanath.sripathy(a)linaro.org> This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/state<n>/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/state<n>/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/state<n>/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS <vishwanath.sripathy(a)linaro.org> Cc: linaro-dev(a)lists.linaro.org --- arch/arm/mach-omap2/cpuidle34xx.c | 58 ++++++++++++++++-- arch/arm/mach-omap2/pm.h | 5 ++ arch/arm/mach-omap2/sleep34xx.S | 121 +++++++++++++++++++++++++++++++++++++ drivers/cpuidle/Kconfig | 5 ++ drivers/cpuidle/sysfs.c | 16 +++++- include/linux/cpuidle.h | 3 + 6 files changed, 202 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 3d3d035..398bef8 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -25,6 +25,7 @@ #include <linux/sched.h> #include <linux/cpuidle.h> +#include <linux/clk.h> #include <plat/prcm.h> #include <plat/irqs.h> #include <plat/powerdomain.h> @@ -86,6 +87,11 @@ static struct cpuidle_params cpuidle_params_table[] = { {1, 10000, 30000, 300000}, }; +#ifdef CONFIG_CPU_IDLE_PROF +static struct clk *clk_32k; +#define CONVERT_32K_USEC(lat) (lat * (USEC_PER_SEC/clk_get_rate(clk_32k))) +#endif + static int omap3_idle_bm_check(void) { if (!omap3_can_sleep()) @@ -115,21 +121,28 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm, * Called from the CPUidle framework to program the device to the * specified target state selected by the governor. */ + static int omap3_enter_idle(struct cpuidle_device *dev, struct cpuidle_state *state) { struct omap3_processor_cx *cx = cpuidle_get_statedata(state); struct timespec ts_preidle, ts_postidle, ts_idle; u32 mpu_state = cx->mpu_state, core_state = cx->core_state; +#ifdef CONFIG_CPU_IDLE_PROF + int idle_time, latency; + long sleep_time, wkup_time, total_sleep_time; + long preidle_time, postidle_time; +#endif current_cx_state = *cx; - /* Used to keep track of the total time in idle */ - getnstimeofday(&ts_preidle); - local_irq_disable(); local_fiq_disable(); - + /* Used to keep track of the total time in idle */ + getnstimeofday(&ts_preidle); +#ifdef CONFIG_CPU_IDLE_PROF + preidle_time = omap3_sram_get_32k_tick(); +#endif pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); @@ -153,9 +166,39 @@ return_sleep_time: getnstimeofday(&ts_postidle); ts_idle = timespec_sub(ts_postidle, ts_preidle); +#ifdef CONFIG_CPU_IDLE_PROF + postidle_time = omap3_sram_get_32k_tick(); +#endif local_irq_enable(); local_fiq_enable(); +#ifdef CONFIG_CPU_IDLE_PROF + sleep_time = omap3_sram_get_sleep_time(); + wkup_time = omap3_sram_get_wkup_time(); + + /* take care of overflow */ + if (postidle_time < preidle_time) + postidle_time += (u32) 0xffffffff; + if (wkup_time < sleep_time) + wkup_time += (u32) 0xffffffff; + + idle_time = postidle_time - preidle_time; + total_sleep_time = wkup_time - sleep_time; + latency = idle_time - total_sleep_time; + sleep_time = omap3_sram_get_sleep_time(); + wkup_time = omap3_sram_get_wkup_time(); + + /* calculate average latency after ignoring sprious ones */ + if ((total_sleep_time > 0) && (latency > state->actual_latency) + && (latency >= 0)) { + state->actual_latency = CONVERT_32K_USEC(latency); + latency = (sleep_time - preidle_time); + state->sleep_latency = CONVERT_32K_USEC(latency); + latency = postidle_time - wkup_time; + state->wkup_latency = CONVERT_32K_USEC(latency); + } +#endif + return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC; } @@ -423,7 +466,9 @@ int __init omap3_idle_init(void) struct omap3_processor_cx *cx; struct cpuidle_state *state; struct cpuidle_device *dev; - +#ifdef CONFIG_CPU_IDLE_PROF + static struct device dummy_device; +#endif mpu_pd = pwrdm_lookup("mpu_pwrdm"); core_pd = pwrdm_lookup("core_pwrdm"); @@ -456,6 +501,9 @@ int __init omap3_idle_init(void) omap3_cpuidle_update_states(); +#ifdef CONFIG_CPU_IDLE_PROF + clk_32k = clk_get(&dummy_device, "wkup_32k_fck"); +#endif if (cpuidle_register_device(dev)) { printk(KERN_ERR "%s: CPUidle register device failed\n", __func__); diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 3de6ece..e62e87d 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -82,4 +82,9 @@ extern unsigned int save_secure_ram_context_sz; extern unsigned int omap24xx_cpu_suspend_sz; extern unsigned int omap34xx_cpu_suspend_sz; +#ifdef CONFIG_CPU_IDLE_PROF +extern u32 omap3_sram_get_wkup_time(); +extern u32 omap3_sram_get_sleep_time(); +extern u32 omap3_sram_get_32k_tick(); +#endif #endif diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index d522cd7..8dec5ef 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -59,6 +59,20 @@ #define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) +#define TIMER_32K_SYNC_P 0x48320010 +#define TIMER_32K_SYNC OMAP2_L4_IO_ADDRESS(TIMER_32K_SYNC_P) + +#define SCRATCHPAD_SLEEP_TIME_OFFSET 0x9f8 +#define SCRATCHPAD_WKUP_TIME_OFFSET 0x9fc +#define SCRATCHPAD_SLEEP_TIME OMAP343X_CTRL_REGADDR(SCRATCHPAD_SLEEP_TIME_OFFSET) +#define SCRATCHPAD_WKUP_TIME OMAP343X_CTRL_REGADDR(SCRATCHPAD_WKUP_TIME_OFFSET) +#define SCRATCHPAD_WKUP_TIME_P OMAP343X_CTRL_BASE + SCRATCHPAD_WKUP_TIME_OFFSET + +#define CM_ICLKEN_WKUP OMAP34XX_CM_REGADDR(WKUP_MOD, CM_ICLKEN) +#define CM_ICLKEN_WKUP_P OMAP3430_CM_BASE + WKUP_MOD + CM_ICLKEN +#define CM_IDLEST_WKUP OMAP34XX_CM_REGADDR(WKUP_MOD, CM_IDLEST) +#define CM_IDLEST_WKUP_P OMAP3430_CM_BASE + WKUP_MOD + CM_IDLEST + .text /* Function to aquire the semaphore in scratchpad */ ENTRY(lock_scratchpad_sem) @@ -183,7 +197,31 @@ api_params: .word 0x4, 0x0, 0x0, 0x1, 0x1 ENTRY(save_secure_ram_context_sz) .word . - save_secure_ram_context +#ifdef CONFIG_CPU_IDLE_PROF +ENTRY(omap3_sram_get_wkup_time) + stmfd sp!, {lr} @ save registers on stack + ldr r0, wkup_time + ldr r0, [r0] + ldmfd sp!, {pc} @ restore regs and return +ENTRY(omap3_sram_get_wkup_time_sz) + .word . - omap3_sram_get_wkup_time + +ENTRY(omap3_sram_get_sleep_time) + stmfd sp!, {lr} @ save registers on stack + ldr r0, sleep_time + ldr r0, [r0] + ldmfd sp!, {pc} @ restore regs and return +ENTRY(omap3_sram_get_sleep_time_sz) + .word . - omap3_sram_get_sleep_time +ENTRY(omap3_sram_get_32k_tick) + stmfd sp!, {lr} @ save registers on stack + ldr r0, sync_32k_timer + ldr r0, [r0] + ldmfd sp!, {pc} @ restore regs and return +ENTRY(omap3_sram_get_32k_tick_sz) + .word . - omap3_sram_get_32k_tick +#endif /* * Forces OMAP into idle state * @@ -207,6 +245,13 @@ loop: cmp r1, #0x0 /* If context save is required, do that and execute wfi */ bne save_context_wfi + +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, sleep_time + str r5, [r6] +#endif /* Data memory barrier and Data sync barrier */ mov r1, #0 mcr p15, 0, r1, c7, c10, 4 @@ -224,8 +269,25 @@ loop: nop nop nop +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, iclken_wkup + ldr r5, [r4] + orr r5, r5, #0x4 + str r5, [r4] + ldr r4, idlest_wkup +wait_idlest: + ldr r5, [r4] + and r5, r5, #0x4 + cmp r5, #0x0 + bne wait_idlest + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, wkup_time + str r5, [r6] +#endif bl wait_sdrc_ok + ldmfd sp!, {r0-r12, pc} @ restore regs and return restore_es3: /*b restore_es3*/ @ Enable to debug restore code @@ -247,6 +309,23 @@ copy_to_sram: blx r1 restore: /* b restore*/ @ Enable to debug restore code +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, iclken_wkup_p + ldr r5, [r4] + orr r5, r5, #0x4 + str r5, [r4] + ldr r4, idlest_wkup_p +wait_idlest1: + ldr r5, [r4] + and r5, r5, #0x4 + cmp r5, #0x0 + bne wait_idlest1 + ldr r4, sync_32k_timer_p + ldr r5, [r4] + ldr r6, wkup_time_p + str r5, [r6] +#endif + /* Check what was the reason for mpu reset and store the reason in r9*/ /* 1 - Only L1 and logic lost */ /* 2 - Only L2 lost - In this case, we wont be here */ @@ -587,6 +666,12 @@ finished: mcr p15, 2, r10, c0, c0, 0 isb skip_l2_inval: +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, sleep_time + str r5, [r6] +#endif /* Data memory barrier and Data sync barrier */ mov r1, #0 mcr p15, 0, r1, c7, c10, 4 @@ -603,6 +688,22 @@ skip_l2_inval: nop nop nop +#ifdef CONFIG_CPU_IDLE_PROF + ldr r4, iclken_wkup + ldr r5, [r4] + orr r5, r5, #0x4 + str r5, [r4] + ldr r4, idlest_wkup +wait_idlest2: + ldr r5, [r4] + and r5, r5, #0x4 + cmp r5, #0x0 + bne wait_idlest2 + ldr r4, sync_32k_timer + ldr r5, [r4] + ldr r6, wkup_time + str r5, [r6] +#endif bl wait_sdrc_ok /* restore regs and return */ ldmfd sp!, {r0-r12, pc} @@ -668,5 +769,25 @@ cache_pred_disable_mask: .word 0xFFFFE7FB control_stat: .word CONTROL_STAT +#ifdef CONFIG_CPU_IDLE_PROF +sync_32k_timer: + .word TIMER_32K_SYNC +sync_32k_timer_p: + .word TIMER_32K_SYNC_P +sleep_time: + .word SCRATCHPAD_SLEEP_TIME +wkup_time: + .word SCRATCHPAD_WKUP_TIME +wkup_time_p: + .word SCRATCHPAD_WKUP_TIME_P +iclken_wkup: + .word CM_ICLKEN_WKUP +iclken_wkup_p: + .word CM_ICLKEN_WKUP_P +idlest_wkup: + .word CM_IDLEST_WKUP +idlest_wkup_p: + .word CM_IDLEST_WKUP_P +#endif ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig index 7dbc4a8..147456d 100644 --- a/drivers/cpuidle/Kconfig +++ b/drivers/cpuidle/Kconfig @@ -18,3 +18,8 @@ config CPU_IDLE_GOV_MENU bool depends on CPU_IDLE && NO_HZ default y + +config CPU_IDLE_PROF + bool + depends on CPU_IDLE + default n diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c index 0310ffa..a3e9db1 100644 --- a/drivers/cpuidle/sysfs.c +++ b/drivers/cpuidle/sysfs.c @@ -249,6 +249,11 @@ define_show_state_ull_function(usage) define_show_state_ull_function(time) define_show_state_str_function(name) define_show_state_str_function(desc) +#ifdef CONFIG_CPU_IDLE_PROF +define_show_state_function(actual_latency) +define_show_state_function(sleep_latency) +define_show_state_function(wkup_latency) +#endif define_one_state_ro(name, show_state_name); define_one_state_ro(desc, show_state_desc); @@ -256,7 +261,11 @@ define_one_state_ro(latency, show_state_exit_latency); define_one_state_ro(power, show_state_power_usage); define_one_state_ro(usage, show_state_usage); define_one_state_ro(time, show_state_time); - +#ifdef CONFIG_CPU_IDLE_PROF +define_one_state_ro(actual_latency, show_state_actual_latency); +define_one_state_ro(sleep_latency, show_state_sleep_latency); +define_one_state_ro(wkup_latency, show_state_wkup_latency); +#endif static struct attribute *cpuidle_state_default_attrs[] = { &attr_name.attr, &attr_desc.attr, @@ -264,6 +273,11 @@ static struct attribute *cpuidle_state_default_attrs[] = { &attr_power.attr, &attr_usage.attr, &attr_time.attr, +#ifdef CONFIG_CPU_IDLE_PROF + &attr_actual_latency.attr, + &attr_sleep_latency.attr, + &attr_wkup_latency.attr, +#endif NULL }; diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h index 55215cc..6474f6a 100644 --- a/include/linux/cpuidle.h +++ b/include/linux/cpuidle.h @@ -43,6 +43,9 @@ struct cpuidle_state { int (*enter) (struct cpuidle_device *dev, struct cpuidle_state *state); +#ifdef CONFIG_CPU_IDLE_PROF + u32 actual_latency, sleep_latency, wkup_latency; +#endif }; /* Idle State Flags */ -- 1.7.0.4

14 years, 3 months

[PM] 25/08/10 - Minutes for the Power Management WG weekly call

by Amit Kucheria

The minutes of the weekly call can be found at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-25 The minutes and actions are copied below. Regards, Amit Attendees: Linaro: Amit Kucheria, Amit Arora, Yong Shen ARM: Robin Randhawa, Bobby Batacharia, Srinivas Kalaga == Action Items from this Meeting == * ACTION: Yong to work with John Rigby and Ubuntu kernel team to make sure the Linaro kernel contains powertop kernel patches * ACTION: Vishwa to verify powertop on 2.6.35 * ACTION: Vishwa to check with cpuidle/cpufreq experts in TI for verifying cpufreq behavior on multi-core OMAP * ACTION: Amit A to get the powertop patch integrated into Linaro/Ubuntu packages * ACTION: Yong to test common clk API patches on imx5 and help get it booting on babbage 3.0 == Action Items from Previous Meeting == * ACTIVE (Immediate): * ACTION: Amit A to test on pm enabled OMAP3 board: DONE on 2.6.32 on zoom3 board * New ACTION: Vishwa to verify on 2.6.35 * ACTION: Amit A to document details on power supply class (battery info) to PowerTOP internal wiki page: DONE * ACTION: Yong to look into getting powertop kernel patches applied to Linaro kernel tree: Not DONE * New ACTION: Yong to work with John Rigby and make sure the Linaro kernel contains it * ACTION: Robin to send links to patches sent to linux-pm: DONE * http://www.spinics.net/lists/cpufreq/msg01740.html * It was a pointer to a discussion on having different governors on different cores * ACTION: Amit K to spend some time on usecase to reproduce ondemand governor problems: POSTPONED * ACTION: Yong to look at common clock FW, find out if debug info being exported (usage count, clk rate, dependencies): DONE * DORMANT : * ACTION: ARM to share internal instrumentation flow (BAB: we might also align with Linaro on workload discussions) * Might take couple of months * ACTION: Amit K to talk to jeremy about power domain framework: DONE * Jeremy needs help, will revisit in a few weeks * ACTION: Srinivas to provide details of where he believes userspace - kernel interaction is required. (low prio) * ACTION: Bobby to check on multi-core boards availability (request open) * ACTION: ARM to discuss giving out internal Eclipse based tool (similar to powertop) (no ETA as of now) * ACTION: Amit Kucheria and Vishwa to get inputs from community on the issues related to CPUIDLE governor: POSTPONED until instrumentation work == Minutes == * Discussion on http://www.spinics.net/lists/cpufreq/msg01740.html * For ARM, both cores run at same frequency (CMP) * Does it make sense for them to run different governors on each core? * The consensus currently is NO * TI uses ondemand governor + policy manager * One core is kept OFF, all processing happens on the other one. * If load on one core goes above a threshold, they turn ON other core * Both cores run at same Operating Point once ON * Debug info in common clk API being discussed upstream by Jeremy * There is currently no debug info * clock name is not part of the common struct clk to keep size down * Need to engage with Jeremy * Yong will test the patches from Jeremy on imx5 and report back * Powerdebug: should we visualise the clock and power dependencies using information from /sys or debugfs? * No immediate horror expressed at the idea * Freescale and TI already do it to a certain extent by dumping the clock tree and rates into a table * The entire tree is too complex to depict * We could represent it in parts e.g. start at a peripheral and plot it's clock and power dependencies all the way up

14 years, 3 months

Restricting architectures

by Michael Hope

Hi there. We've been having a discussion in the Toolchain WG regarding Thumb-1 improvements. I want to decline doing them as I've assumed that Linaro is focused on the Cortex-A series, but I can't find that written down anywhere. May I limit the Toolchain WG to currently or nearly shipping Cortex-A implementations? This means: * Cortex-A profile only * ARMv7 only * ARM and Thumb-2 instruction sets * With or without NEON * With either VFPv3 D16 or D32 * With or without SMP We will try to do no harm to other architectures or earlier ARM versions. The Thumb-2 routines may be applicable to the Cortex-M and Cortex-R series but we will not optimise for them. I'd like Linaro to state this explicitly in the next round. https://wiki.linaro.org/Linaro1011/TechnicalRequirements defines a 'Standard ARMv7 Configuration' but there's no higher level statement justifying it, no statement restricting us to it, and it includes ARM, Thumb-2, and Thumb-1. -- Michael

14 years, 3 months

imx51 and CONFIG_NEON

by John Rigby

Amit, Bryan: Do you know what the correct setting for CONFIG_NEON is for MX51? In a discussion on IRC there was mention that there is a patch that makes it safe to turn on. Do you know if that patch has made it upstream? Thanks, John

14 years, 3 months

Packaging problems with armel-cross-toolchain-base

by Marcin Juszkiewicz

Hi First some informations. "armel-cross-toolchain" is a package which will generate armel cross toolchain for x86(-64) machines (but nothing keeps from building powerpc->armel one etc). Do to that I am building several stages of linux/eglibc/gcc-4.5/binutils in proper order. This is called 'bootstrap' way of building cross compiler and can be automated (which can not be done with Embedian way which we used before). In last week I did a split of package into 2 steps: - armel-cross-toolchain-base - armel-cross-toolchain Where first one provides binutils, linux headers, libc6 and libgcc packages. Second provides final gcc. My armel-cross-toolchain-base package got to the moment when it builds out of box on Ubuntu maverick. But build != upload ;( And here I need some help. As you can see on page [1] package got built [2] but then was rejected to be uploaded [3]. Here my Debian/Ubuntu packaging skills ends as I never imported any package to those systems. According to people from #launchpad my package is buggy as it is producing a binutils binary which expects to be built from a binutils source. Whereas mine source package is neither named binutils nor does it have that version. So problem is how to get it done... So far I tried ugly hacks like: sed -i -e "s/^binutils/armel-cross-toolchain-base/g" debian/changelog; \ sed -i -e "s/^Source: binutils/Source: armel-cross-toolchain-base/g" debian/control.in; \ sed -i -e "s/^Source: binutils/Source: armel-cross-toolchain-base/g" debian/control; \ But this does not look right for me and require more changes in linux packaging as it uses changelog name as base for package names. So help me please if you have ideas. 1. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler/+build/1940050 2. http://launchpadlibrarian.net/54624642/buildlog_ubuntu-maverick-i386.armel-… 3. http://launchpadlibrarian.net/54624644/upload_1942031_log.txt Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

14 years, 3 months

Vexpress mtdparts question

by Matt Waddel

I am trying to map the nor flash on the Versatile Express platform to an mtd partition. I have tried a bunch of variations with the kernel command line "mtdparts" directive, without success. Here is the last one I tried: mtdparts=armflash-1.0:1M(uboot),9M(linux),16M(uInitrd) The kernel seems to detect the flash parts correctly: ... armflash-0: Found 2 x16 devices at 0x0 in 32-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled armflash-1: Found 2 x16 devices at 0x0 in 32-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Concatenating MTD devices: (0): "armflash-0" (1): "armflash-1" into device "armflash" RedBoot partition parsing not available ... $ cat /proc/mtd dev: size erasesize name <nothing listed> Any ideas? Thanks, Matt

14 years, 3 months

Call for testing: Linaro 10.11 Beta Candidate

by Jamie Bennett

Hi, According to the schedule [1], the Beta release [2] is due in two days. The release team have selected a beta candidate and would like your helping in testing the images to ensure that they are of Beta quality. If you have the hardware available, currently OMAP Beagleboard and ARM Versatile Express (ca9x4_ct_vxp) then you could help. The steps involved in testing are: 1) Download the correct image for your board, OMAP [3] or Versatile Express [4]. 2) Install the image on your device (instructions can be found on the Beta release page [2]). 3) Log in or create an account at http://qatracker.linaro.org. 4) Test according to the test cases for your board by following the instructions on qatracker. 5) Submit your results to qatracker, file bugs, come joins us on the irc channel [5] to ask questions. Hopefully with your help, we can make the Beta release rock. Regards, Jamie. -- Linaro Release Manager [1] http://wiki.linaro.org/Releases/1011#Linaro10.11Schedule [2] http://wiki.linaro.org/Releases/1011/Beta [3] OMAP - http://snapshots.linaro.org/10.11-daily/linaro-headless/20100831/1/images/t… [4] Versatile Express - http://snapshots.linaro.org/10.11-daily/linaro-headless-vexpress/20100831/2… [5] #linaro on irc.freenode.net

14 years, 3 months

Linaro and ARMv5

by Pedro I. Sanchez

Hello, I'm looking for some advice on the feasibility of using Linaro on one of my projects based on an AT91SAM9260 Atmel processor, which has an ARM926EJ-S ARMv5 processor core. I see that the Linaro builds do not support v5 and I wonder, what would be involved in "recompiling" Linaro with v5 support? Is there anyone else looking at this possibility? Any suggestions? Thanks, -- Pedro

14 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2010