linaro-dev August 2010

linaro-dev@lists.linaro.org

62 participants
82 discussions

by Christian Robottom Reis

Hi there! I unpacked our minimal release image and ran an xdiskusage on it, mostly to see what we're shipping -- and I was surprised to see that a fourth of the image is actually apt package caches and lists. Can we put into the image generation script something to strip them out before generating the image? The untarring also suggests a number of places where we could further trim the image, some of which are probably pretty hard to do: * stripping /usr/share/doc out (but everybody knew that) * dropping charmaps, zones and locale info that will never really be used * stripping out modules for devices that won't ever be on this ARM device * stripping out firmware for peripherals that won't ever be on this ARM device I've included the xdiskusage output so you can see what I mean. And good job on the release! -- Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko Linaro.org | [+55 16] 9112 6430 | http://async.com.br/~kiko

14 years, 4 months

RE: New "Linaro kernel merge result of the moment" aka "arm_next"

by Nicolas Pitre

On Wed, 11 Aug 2010, Will Deacon wrote: > Hi Nicolas, > > > The Linaro freeze is imminent, and at that point a stable branch that > > won't be rebased anymore will be forked. The stable branch should only > > see bug fixes and no new features. Therefore I'd like to know if there > > is anything that should be added or removed from this tree before the > > freeze is in place. Please tell me ASAP. > > The only thing I can think of from my end is the hardware breakpoint patches > I have: > > http://www.linux-arm.org/git?p=linux-2.6-wd.git;a=shortlog;h=refs/heads/hw-… > > I've not merged these into my Linaro branch because I'm not happy with the > amount of testing they've received [it's a bit of a catch 22 because one > good way to get them tested is to merge them!]. My criteria would be: 1) Could their addition break something else even when not used? If there is no risk for regression then we could as well just include them and add fixes later if need be. 2) Is there some ABI implied with gdb or the like? If there are ABI issues then I'd prefer having the assurance that it won't change by the time this gets merged into the mainline kernel. Nicolas

14 years, 4 months

A quick toolchain benchmark

by Michael Hope

I had a quick go at benchmarking the Linaro GCC compiler and was presently surprised. The workload was decoding 10 s of h.264 video using ffmpeg with assembly optimisations disabled. This gives the compiler a good workout. Compared to FSF GCC 4.4.4, Linaro GCC 4.4 is 6 % faster, FSF GCC 4.5.0 is 12 % faster, and Linaro GCC 4.5 is 24 % faster. Now this is with a sample size of one so the results are not statistically valid, and I haven't told you how to reproduce it so they're not scientifically valid, but the numbers are pleasing none the less. -- Michael

14 years, 4 months

[RFC] OMAP CPUIDLE: CPU Idle latency measurement

by vishwanath.sripathy＠linaro.org

From: Vishwanath.sripathy(a)linaro.org This patch has instrumentation code for measuring CPUIdle C states for OMAP. THis is still under development and not completely tested yet. 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. Signed-off-by: Vishwanath BS <vishwanath.sripathy(a)linaro.org> --- diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 3d3d035..30120cb --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -25,6 +25,8 @@ #include <linux/sched.h> #include <linux/cpuidle.h> +#include <linux/clk.h> +#include <linux/jiffies.h> #include <plat/prcm.h> #include <plat/irqs.h> #include <plat/powerdomain.h> @@ -33,6 +35,7 @@ #include <plat/serial.h> #include "pm.h" +#include <plat/common.h> #ifdef CONFIG_CPU_IDLE @@ -86,6 +89,13 @@ 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))) +u32 omap3_sram_get_wkup_time(); +u32 omap3_sram_get_sleep_time(); +#endif + static int omap3_idle_bm_check(void) { if (!omap3_can_sleep()) @@ -115,21 +125,26 @@ 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; + int idle_time, latency; + long sleep_time, wkup_time, total_sleep_time, preidle_time, postidle_time; 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 = omap_32k_read(); +#endif pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); @@ -153,9 +168,27 @@ return_sleep_time: getnstimeofday(&ts_postidle); ts_idle = timespec_sub(ts_postidle, ts_preidle); +#ifdef CONFIG_CPU_IDLE_PROF + postidle_time = omap_32k_read(); +#endif local_irq_enable(); local_fiq_enable(); +#ifdef CONFIG_CPU_IDLE_PROF + /* TODO: take care of overflow */ + idle_time = postidle_time - preidle_time; + sleep_time = omap3_sram_get_sleep_time(); + wkup_time = omap3_sram_get_wkup_time(); + + /* TODO: take care of overflow */ + total_sleep_time = wkup_time - sleep_time; + latency = idle_time - total_sleep_time; + /* TODO: calculate average */ + state->actual_latency = CONVERT_32K_USEC(latency); + state->sleep_latency = CONVERT_32K_USEC(sleep_time - preidle_time); + state->wkup_latency = CONVERT_32K_USEC(postidle_time - wkup_time); +#endif + return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC; } @@ -419,6 +452,7 @@ struct cpuidle_driver omap3_idle_driver = { */ int __init omap3_idle_init(void) { + static struct device dummy_device; int i, count = 0; struct omap3_processor_cx *cx; struct cpuidle_state *state; @@ -456,6 +490,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/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index d522cd7..448f1ba --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -58,6 +58,9 @@ #define SDRC_MANUAL_1_P (OMAP343X_SDRC_BASE + SDRC_MANUAL_1) #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 0xfa320010 +#define SCRATCHPAD_SLEEP_TIME 0xfa0029f8 +#define SCRATCHPAD_WKUP_TIME 0xfa0029fc .text /* Function to aquire the semaphore in scratchpad */ @@ -184,6 +187,22 @@ api_params: ENTRY(save_secure_ram_context_sz) .word . - save_secure_ram_context +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 + /* * Forces OMAP into idle state * @@ -207,6 +226,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 +250,15 @@ loop: nop nop nop +#ifdef CONFIG_CPU_IDLE_PROF + 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 @@ -587,6 +620,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 +642,13 @@ skip_l2_inval: nop nop nop + +#ifdef CONFIG_CPU_IDLE_PROF + 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 +714,14 @@ cache_pred_disable_mask: .word 0xFFFFE7FB control_stat: .word CONTROL_STAT +sync_32k_timer: + .word TIMER_32K_SYNC +sleep_time: + .word SCRATCHPAD_SLEEP_TIME +wkup_time: + .word SCRATCHPAD_WKUP_TIME + ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend + + diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig index 7dbc4a8..b8f1e07 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 y diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c index 0310ffa..a3e9db1 --- 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 */

14 years, 4 months

[PATCH] Launch Control: Add new utils package with large json module

by Zygmunt Bazyli Krynicki

Hello everyone. To stick to good open-source development standards I'd like to announce Launch Control code reviews on the mailing list. This is just a public ping of the following merge request: https://code.edge.launchpad.net/~zkrynicki/launch-control/utils_package/+me… Anyone interested in Launch Control development is welcome to review this and post comments on the launchpad merge request page (they get forwarded as emails to all participants). Best regards Zygmunt Krynicki -- Zygmunt Bazyli Krynicki <zygmunt.krynicki(a)linaro.org> Linaro

14 years, 4 months

linux-linaro kernel package available

by John Rigby

The long awaited first linux-linaro kernel package is available in the linaro-maintainers kernel ppa: ppa:linaro-maintainers/kernel https://launchpad.net/~linaro-maintainers/+archive/kernel

14 years, 4 months

[RFC] Making PowerTOP generic - Call for Testing and Review

by Amit Arora

Background: --------------- PowerTOP is a tool used to provide information related to power consumption, from various sources, into one screen. One of the issues with PowerTOP is that the number of C and P states are hardcoded and thus it doesn't provide complete information on systems which may have more states than the hardcoded ones. Thus, though it works well on intel platforms, it may not on some of the ARM boards. Changes being suggested: --------------------------------- These are couple of simple patches which try to make PowerTOP generic enough to run on almost any platform, which is plugged into the cpufreq and cpuidle framework. Thus the number of C and P states will no longer be hardcoded (though, the MAX values will be, to allocate enough memory for data structures). Most of the changes required is to make the display be aware of the ACTUAL number of these states and not just depend on some hard coded values. Where to get the source and patches: ----------------------------------------------- You can get it from the git repo located at git://git.linaro.org/amitarora/powertop.git The "master" branch has the PowerTOP code in sync with latest upstream powertop git tree. The "linaro" branch has my patches, which need testing. So, once you clone the tree, please do not forget to checkout the "linaro" branch (git checkout -b linaro remotes/origin/linaro)! Note: If you had cloned it before, please clone a fresh tree, since I have re-written the history for "linaro" branch, to get patches in shape for upstream submission. Something, which I know should be avoided in future. What to review: -------------------- Once you checkout the "linaro" branch, as suggested above. You can review the two patches with commit id "09049b42e3" and "783a3e6bbe". What to test: ---------------- Some of the things which could be tested is, o Compile and test on any ARM board that you may have. You can also test on any x86 / x86_64 systems, to check if nothing has been broken. o Compare the output from "master" and "linaro" branches ("-d" dump option may help, if you wish to take a diff) o Check if the number of C states is correct (/sys/devices/system/cpu/cpu0/cpuidle/) o Check if the number of P states is correct (/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies) o Check if the % values makes sense (say, if total doesn't add to 100! Or, if its a very huge value [1] ). o If number of Wakeups-per-second [1] looks reasonable. o Top causes for wakeups is shown properly o Suggestions are shown properly. Some of the suggestions may show a hot key on the status bar (at bottom). [1] There is a known issue of %age values and Wakeups-per-sec number being shown very high (in the order of thousands), if some key is hit (say, 'r' to refresh or any other key). This problem can be seen in "master" branch (upstream) too, and hence is not introduced by the new patches. Since the goal of these patches is different, I haven't addressed this issue here. Note: Thanks a ton to people who tested my initial patches and provided their valuable feedback. Thanks ! Regards, Amit Arora

14 years, 4 months

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

by Amit Kucheria

The minutes of the weekly call fresh-off-the-oven can be found at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-04 Attendees: Linaro: Amit Kucheria, Amit Arora, Vishwanath Sripathy, Yong Shen ARM: Srinivas Kalaga, Robin Randhawa Action Items from this Meeting * Action: Robin and Srinivas to send mail to team, to target the ftrace patches for upstream. * Action: Amit K to send email regarding power aware scheduling by Intel (CONFIG_SCHED_MC & CONFIG_SCHED_SMT ?) Yes! * ACTION: Yong Shen to test Amit Arora's powertop patches and powerdebug tool. * ACTION: Yong Shen to investigate plugging in cpufreq framework for freescale boards * ACTION: Amit Arora to creat a new wiki page for instructions on how to setup your own git repo on git.linaro.org * ACTION: Amit K to talk to jeremy about power domain framework * ACTION: Amit Arora and Yong to discuss about reporting sensor information (hwmon, or some other source for ARM?) Action Items from Previous Meeting * ACTIVE (Immediate): o ACTION: Bobby to investigate android contraints (e.g. display keep-alive): CLOSED + Bobby sent a mail. Considering closed. o ACTION: Srinivas to add ftrace item to task list and send patches to linaro: CLOSED + Srinivas has emailed the patches to team. Needed to get time-stamps when system is entering low power state with various workloads o ACTION: Vishwa to create a new blue print for the instrumentation of cpuidle related work: CLOSED + Blue print created and assigned to Vishwa. o ACTION: Amit Arora to create tarballs of his current work and share it internally for testing: CLOSED + considered done, git tree now available on git.linaro.org o ACTION: Amit Kucheria and Vishwa to get inputs from community on the issues related to CPUIDLE governor: POSTPONED until instrumentation work * ACTIVE (Long Term) : o ACTION: Srinivas to provide details of where he believes userspace - kernel interaction is required. (low prio) o ACTION: Bobby to check on multi-core boards availability (request open) o ACTION: ARM to discuss giving out internal Eclipse based tool (similar to powertop) (no ETA as of now) * DORMANT : o ACTION: ARM to share internal instrumentation flow (BAB: we might also align with Linaro on workload discussions) + Might take couple of months Minutes * ftrace patches part of larger tool work inside ARM, perhaps the ftrace patch doesn't need to wait for the entire tool and can be sent upstream * power aware scheduling using perf counters, cache misses/hits, TLB hits/misses? o ties into instrumentation work for cpuidle being done by Vishwa * Discussion regarding power domain framework o Similar to clock framework o Does SRF replacement handle it? No, according to Vishwa. * displaying sensors information - is it duplicating work done by lm-sensors tool? o figure out what drivers are using hwmon o perhaps it would make sense to use the lm-sensor library (is there any?) to grab this info? * API to read performance counters o arch/arm/kernel/pmu.h perf_event.c o No documentation? (Perhaps we should provide docs?)

14 years, 4 months

New "Linaro kernel merge result of the moment" aka "arm_next"

by Nicolas Pitre

I just made available a new Linaro kernel merge result at the following location: http://git.linaro.org/?p=linux/arm_next.git;a=summary This is the merge result from the following branches: Linus' tree at v2.6.35 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 Greg KH's stable branch at v2.6.35.1 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.35.y.git RMK's "devel" branch at commit 7b70c427 (merged into mainline with commit be82ae02) Catalin Marinas' "stable-2.6.35" branch at commit 2d73da46 git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-2.6-cm.git Will Deacon's "for-linaro" branch at commit 7987abe4 git://repo.or.cz/linux-2.6/linux-wd.git Tony Lindgren's "omap-for-linus" branch at commit d21872b3 (merged into mainline with commit d71048e2) Uwe Kleine-König's "arm/booting" branch has been dropped as it is now included in RMK's "devel" branch. This has been tagged with "linaro_merge_100811" and the tag message also has the above info. This is also available through the following gitweb link: http://git.linaro.org/gitweb?p=linux/arm_next.git;a=tag;h=linaro_merge_1008… The previous merge result is still available through the tag "linaro_merge_100716" for reference. The Linaro freeze is imminent, and at that point a stable branch that won't be rebased anymore will be forked. The stable branch should only see bug fixes and no new features. Therefore I'd like to know if there is anything that should be added or removed from this tree before the freeze is in place. Please tell me ASAP. Nicolas

14 years, 4 months

Toolchain WG - 2010-08-09 meeting minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-09 A copy follows, along with activity reports for the different members. -- Michael Attendees • Name Email IRC Nick Yao Qi yao.qi(a)linaro.org yao Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Scott Bambrough scott.bambrough(a)linaro.org scottb Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw Peter Maydell peter.maydell(a)linaro.org pm215 Michael Hope michael.hope(a)linaro.org michaelh Marcin Juszkiewicz marcin.juszkiewicz(a)linaro.org hrw Loïc Minier loic.minier(a)linaro.org lool Julian Brown julian(a)codesourcery.com jbrown Dave Martin dave.martin(a)linaro.org dmart Chung-Lin Tang cltang(a)codesourcery.com cltang Andrew Stubbs andrew.stubbs(a)linaro.org ams Agenda • Review action items from last meeting • New public call-in number: code 263 441 7169 • Release status □ 4.4 at http://ex.seabright.co.nz/build/gcc-linaro-4.4-2010.08-0/ □ 4.5 at http://ex.seabright.co.nz/build/gcc-linaro-4.5-2010.08-0/ □ Ubuntu toolchain would prefer 4.5.1 • Next focus □ Merging patches upstream □ Prioritising GDB features • Future focus □ Emphasise performance, neutral on correctness □ Topics to investigate ☆ Vectoriser ☆ Pipeline ☆ PGO ☆ Upstream research topics □ Topics for UDS □ Benchmarks Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • TBD Action Items from Previous Meeting • DONE: Michael to organise and spread next Monday's call in number • ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5 is • DONE: 500524 Ulrich to backport to Linaro 4.4 • DONE: Test failures: Michael to build FSF 4.4.4 as a baseline • DONE: Test failures: Michael to compare FSF and Linaro GCC failures • DONE: Test failures: All Linaro GCC failures to be ticketed • DONE: LTO check on ARM: Michael to reproduce. check-lto fails with no Makefile target • DONE: Ulrich to write up known GDB work • DONE: 598147: Michael to reproduce the test failures • DONE: 398403: Andrew to reproduce on his IGEP board (has more RAM) • DONE: Michael to make sure merge requests are present for work that has been done Minutes • Release status □ Talked about the upcoming 2010.08 release □ Andrew has posted tarballs which Michael has grabbed and built □ Andrew is cross-testing • Discussed 4.5.1 □ 4.5.1 came out, depending on where you look, 11, 8, or two days ago □ Rolling in 4.5.1 and the Firefox exposed alignment bug would have more value □ Discussed time based vs feature based releases and a pragmatic middle ground □ Discussed releasing 4.5.0 based now vs 4.5.1 at next months release vs something inbetween □ Decided to delay the Linaro 4.5 release until at most 2010-08-17 □ Roll in 4.5.1 and the Firefox fix □ Gives something more useful to Ubuntu and others □ ACTION: Andrew to merge 4.5.1 and the Firefox fix by 2010-08-17 • Discussed what goes in next month □ Richard wants the sync primitives fixes □ CSL is still merging their patchset • Discussed what can be done in the future □ Please start thinking of topics for UDS □ Backporting the new costing infrastructure (Richard) ☆ Works by changing how costs are done and making them more generic ☆ Backend provides options for a certain segment ☆ Cost of an option is target dependent ☆ Removes a lot of hard-coded values for particular architectures ☆ Good for core-next ☆ Infrastructure matches trunk ☆ Might pull in ldm changes □ Richard's wishlist ☆ ACLE ☆ v6 SIMD, v5 (limited) □ Conditional instructions ☆ Some are best done at the expand phase where tree goes to RTL ☆ Not on Roger' slist ☆ Check on possible gains □ NEON intrinsics ☆ Don't generate very good code at the moment due to load/stores ☆ Might need internal intrinsics to compose these out of ☆ Developers currently use straight asm, perhaps out of personal preference ☆ Intrinsics aren't well documented/known ☆ Worthwhile as people coming from RVDS and using intrinsics will see big drop □ GDB ☆ Ulrich sent through his list ☆ To categorise into features and fixes ☆ ACTION: Ulrich to ticket items ☆ Work on critical fixes first ☆ Yao, Ulrich to work on list ☆ ACTION: Michael to understand whiteboards as a way of organising features Next meeting is a standup meeting on 2010-08-11 on the public code. --- ams: == Linaro GCC 4.4 == * Reviewed various merge requests. * Created and tested GCC Linaro 4.4-2010.08-0 release tarball. == Linaro GCC 4.5 == * Continued pushing CS patches to Linaro GCC 4.5. I've done quite a lot of these this week, but I've had to omit some patches that caused regressions. * Created and tested GCC Linaro 4.5-2010.08-0 release tarball. == Other == * Set up EEMBC for use with Linaro GCC so Chung-Lin can compare hard-float and soft-float ABIs. * Attended the monthly CS/Linaro sync call. --- yao: == Linaro GCC 4.4 bug fix == * LP:602190 & LP:602285 They are caused by a patch for performance improvement of generated code. Team suggests keep this patch, and fix test case a little bit to fix failures. Fix to LP:602285 is committed and merged to linaro 4.4. Thinking about how to fix LP:602190 from test case side. An option to force to turn 'cunroll' off is helpful. * LP:612011 & GCC PR45094 Update test case pr45094.c from a compilation test to an execute test. Sent to gcc-patches again. Waiting for ARM backend maintainer's comment. Merge this patch to linaro 4.4 first, because of release. Plan to backport to linaro gcc 4.5 once patch is approved by upstreams. * LP:612405 & LP:612406 Fix them by changing ARM target triplet from "arm-*-*" to "arm*-*-*", which is more general. Merged to linaro gcc 4.4. Create a patch against FSF GCC trunk to fix this in other test cases. * LP:612402 Same bug was reported in GCC Bugz PR41501/PR34999, which have been fixed on FSF GCC 4.5.0. No plan to backport to FSF 4.4.x. Leave this bug as Won't Fix on linaro gcc 4.4 and Fix Released on linaro gcc 4.5. * LP:602174 Can't reproduce it on arm-none-linux-gnueabi. Latest result shows obj-c++.dg/bitfield* only failes on x86-64. * LP:602168 g++.dg/eh/pr42859.C test failure Analyze this bug a little bit, and my initial result is that two BBs in exception catch are *not* marked as UNREACHABLE in linaro 4.4, while these two BBs are UNREACHABLE FSF GCC 4.4 trunk. == This Week == * Ping ARM backend maintainer for my patch to GCC PR45094. * Submit my patch on ARM target triplet in gcc patches. * Update status of LP bugs. Mark them as Fix Released if failure go away in gcc-linaro-4.4-2010.08-0. * Other linaro 4.4 bugs to look or other new work to do. Wrap up LP:602190. Analyze deeply on LP:602168/LP:602174. --- pmaydell: RAG: Red: None Amber: waiting final ARM legal OK for qemu contributions Green: Completed all the linaro new-starter admin tasks Milestones: none as yet Progress: - Miscellaneous setup/configure/getting started. virtio-system: - got qemu to boot linaro alpha-2 with random ubuntu versatile kernel - I have a set up that lets me rebuild kernels now Issues: - maemo-qemu supports beagle but the stock linaro alpha 3 takes a div-by-zero exception and panics on startup Plans: general: - flesh out some of the blueprints assigned to me virtio-system: - investigate the div-by-zero panic - find out the easiest way to replace the kernel in the shipped alpha 3 with one I've compiled - make sure virtio is enabled in kernel and try to get it working Absences: None planned. --- uweigand: == GCC == * Prepared Linaro GCC 4.5 backport for bug #604874 (Firefox fails to build) * Prepared Linaro GCC 4.4 backport for bug #500525 (bootstrap failure in stage3) * Investigated bug #600209 (getfem++ test failures) * Investigated bug #602168 (g++.dg/eh/pr42859.C failure) * Investigated bug #506538 (GENERAL_REGS spill failure) * Determined root cause of bug #608125 (gnat build failure) * Determined root cause of Debian bug #591075 (glib2.0 segfault on ARM / i386) == GDB == * Started planning future GDB feature / bugfix work == Miscellaneous == * Converted multiarch toolchain implications document to Wiki page --- cltang: == libffi VFP hard-float support == Mostly finished and doing testing. Using libffi's testsuite, currently has three regressions, two of them related to testing of variadic functions, which are pretty unsolvable due to AAPCS' rule of reverting to the base calling convention for all variadic functions (the libffi code currently has no way of detecting variadic function type from the user, so cannot correctly do this ABI revert). May solve by marking the testcases to be skipped under -mfloat-abi=hard. Will work on a few code optimizations before trying to submit it upstream. == Other == Looking at some Linaro GCC bugs.

14 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2010