Re: Support for Raspberry Pi
On 4 November 2012 05:09, Loïc Minier loic.min...@linaro.org wrote: Hi Geert, On Fri, Nov 02, 2012, Geert Schuring wrote: Could you tell me if you have any plans to enable Ubuntu on the Raspberry Pi (ARMv6) ? Short answer: an Ubuntu ARMv6 port for the Raspberry Pi isn't a Linaro target, but we're taking patches and we're interested in some bugs! :-) There are two main reasons for that: - Linaro doesn't have the capacity to do large scale distro ports, this is usually mainly the job of distros, and we're sometimes giving a hand - Linaro is all about the future of ARM, so the focus is mainly on ARMv7 and ARMv8 at this point That said, there is hope! First, a bunch of Linaro folks have a Raspberry Pi and play with it; second, I believe Ubuntu's armel port is being re-targeted to ARMv5, so Ubuntu armel binaries should eventually run on the Pi. Yip. There's an unsupported cross compiler for Raspbian at: https://launchpad.net/linaro-toolchain-unsupported/+download Linaro does directly care about toolchain regressions you might encounter on ARMv5/ARMv6 (or even on x86), so please do report us any toolchain regressions caused by Linaro patches. Yes please. While we're focused on the Cortex-A series, we don't want to harm earlier architectures. If you see any speed or correctness regressions please let us know. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Lenovo battery at registration desk
I found a lonely looking Lenovo laptop battery in BV1. I've left it at the registration desk. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Kernel 3.6 build bug with Linaro 4.7 toolchains
On 3 October 2012 12:59, Tim Bird tim.b...@am.sony.com wrote: When I try to build the Linux kernel version 3.6 with the gcc-4.7 nightly build Linaro toolchains, $ arm-eabi-gcc --version arm-eabi-gcc (Linaro GCC 4.7-2012.09-1~dev) 4.7.2 20120910 (prerelease) $ arm-eabi-as --version GNU assembler (Linux/GNU Binutils) 2.23.51.0.3.20120918 Hi Tim. Could you tell me more about these builds? I don't recognise them - where did you get them from? I think Khem is right and you need a more recent binutils. The patch he linked to has been backported to the 2.23 branch and should be in the 2.23 release. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM gcc vs ARM rvct
On 27 September 2012 08:09, Dechesne, Nicolas n-deche...@ti.com wrote: Hi there, Is there any sensible comparison document for gcc vs rvct in terms of speed, code size, feature set? Is there any reason / use case to recommend rvct over gcc for non-Linux s/w? Hi Nicolas. I'd recommend talking with ARM about that. Have a think about the qualities you're looking for in a compiler such as: * Speed and size of generated code * Support for the architecture you're interested in * Integration with other tools * Level of support needed * Cost in dollars and effort * Licensing and long term availability My feeling is that our speed is great, size is OK, architecture support is great, integration is great, support is good, cost is good, and licensing is excellent. We haven't gotten around to benchmarking RVCT. In the toolchain team we look for 'headroom' which is where there's a big benchmark difference between current GCC and other compilers. We've still got a ton of work to do from looking at past and alternative versions of GCC so we haven't looked further afield. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Change in floating point performance across kernels
On 17 August 2012 00:37, Michael Hope michael.h...@linaro.org wrote: Hi there. I'm seeing a huge improvement in the SPEC floating point benchmarks between a hacked Ubuntu Precise 3.2.14 kernel and Linus 3.5. Does anyone know why off the top of their head? Hacked how? How big a change? What does perf say? It's a different config but otherwise the same as the Ubuntu linux-ti-omap4_3.2.0-1412.16 package. perf is next. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Change in floating point performance across kernels
On 20 August 2012 11:36, Mans Rullgard mans.rullg...@linaro.org wrote: On 19 August 2012 23:55, Michael Hope michael.h...@linaro.org wrote: On 17 August 2012 00:37, Michael Hope michael.h...@linaro.org wrote: Hi there. I'm seeing a huge improvement in the SPEC floating point benchmarks between a hacked Ubuntu Precise 3.2.14 kernel and Linus 3.5. Does anyone know why off the top of their head? Hacked how? How big a change? What does perf say? It's a different config but otherwise the same as the Ubuntu linux-ti-omap4_3.2.0-1412.16 package. perf is next. So... what did you change? The config file is here: http://people.linaro.org/~michaelh/incoming/precise.config It's mainly turning power management and similar features off. I didn't touch the errata or other core config. The next step would be to run the Ubuntu supplied build and see if performs the same as my reconfigured version to check if it's in the Precise tree or just my fault. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Change in floating point performance across kernels
Hi there. I'm seeing a huge improvement in the SPEC floating point benchmarks between a hacked Ubuntu Precise 3.2.14 kernel and Linus 3.5. Does anyone know why off the top of their head? I see the same on a PandaBoard and PandaBoard ES. In both cases the CPU is locked to 1 GHz and other power management features are disabled. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Raspbian's hard float benchmarks
The Raspbian project is a rebuild of Debian for the Raspberry Pi. adama did some benchmarks that show the improvement in going from ARMv4T with soft float to ARMv6 with hard float: http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ The page says that there's a 4-10 % improvement on integer programs and up to 40 % on floating point programs. It's hard to tell the new instruction vs pipeline influence and if the baseline is soft float or softfp/VFP based. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: QEMU doesn't support imx53 platform
On 30 June 2012 06:46, 陈磊 losemyhea...@gmail.com wrote: QEMU doesn't support imx53 platform, linaro image file for imx53 could not be loaded in QEMU. How to solve this problem? Hi there. QEMU emulates a number of boards including the BeagleBoard, SMDKC210, and Versatile Express but not the i.MX53. If you'd like to try the Linaro LEB under QEMU, then I'd recommend using a Versatile Express Cortex-A9 image instead: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress If you want to run a i.MX53 image under QEMU, then please talk with the upstream QEMU developers. Adding a new model is a fair amount of work but can be quite interesting. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
What happened on KVM in Q1.12
Thought I'd send out an email on what progress was made on KVM last quarter. The Linaro platform and toolchain groups did quite a bit of integration work to package and polish the different components to make it quicker to get going on KVM. You can now download pre-built versions of the boot wrapper, QEMU, kernel, and root file system; use linaro-image tools to create a host and guest; and then spin both up inside a Fast Model. There's more information including versions used and links off at: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/KVMIntegration There's still much to be done. The current focus is helping the upstream developers (Hi Christoffer!) get the patch set up into kvm-next. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Kernel not booting with Linaro GCC?
On 14 June 2012 04:22, Rob Herring robherri...@gmail.com wrote: On 06/10/2012 05:31 PM, Michael Hope wrote: There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/ Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release. The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree. ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure. The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt. This does not affect userspace programs as they run with the trap turned off. I've also hit this with u-boot if I enable armv7-a builds. Mainline u-boot generally builds using -march=armv5 and unaligned accesses disabled in h/w. Generally u-boot starts but dies on certain commands. I think there may be other u-boot issues with v7 compiles on newer gcc versions, but haven't debugged things further. Note that this is done through a unaligned access trap that is off by default. A quick grep through u-boot git shows that it defines CR_A but doesn't use it. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Raspberry pi - Linaro builds
On 10 June 2012 09:24, Anoop CH anoop.ch.1...@gmail.com wrote: Hi, Thank you for your work on the dev boards. Recently i had been working with Android. Your work saved a lot of time for me. I request you to also consider support the raspberry pi board. Which is quite useful for many people. Enduses as well as devs.. Hi there. We're focused on the Cortex-A series and aren't actively working on ARMv6 devices like the Raspberry Pi. There's a good community building up around the Pi - you might want to try stock Debian or the ARMv6 hard float rebuild, Raspbian. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Kernel not booting with Linaro GCC?
There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/ Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release. The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree. ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure. The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt. This does not affect userspace programs as they run with the trap turned off. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Both native and cross compilation failed with Ubuntu Linaro Gcc 4.5.x and 4.6.x for an ARM/OMAP board
On 31 May 2012 00:48, AKS aungk...@gmail.com wrote: Hi I was cross-compiling a Linux kernel 2.6.38 for a Gumstix Overo which is a tiny ARM (TI OMAP 35xx) based single board computer. I was using Linaro cross compiler (arm-linux-gnueabi-gcc) did not give an uImage that gets pass the Loading uImage. My console is ttyO2 and therefore it was not an issue. So I used Code Sourcey G++ Lite (64 bits version without ia32 library) and the kernel image uImage.bin built with the same configuration file (.config) but with different cross compiler can boot up to the stage that the kernel tries to mount ext3 partition on microSD card. So I suspect the package gcc-linux-arm-gnueabi has some bugs. I have a working 2.6.35 kernel (although I do not have the .config file with settings which I have used to build that) that was built with Linaro Gcc 4.3 or 4.4. I suspect the Linaro Gcc 4.5.x and above are giving me a problem. I used the Linaro media create tool with root file system and hardware pack but it also could not help me boot nor give me the right config file which I can use to cross compile a working kernel (that is booting kernel) for Overo computer. Hi Aung. You might be running into an unaligned access fault. The ARMv6 and above can do unaligned loads and stores from memory. Later versions of upstream and Linaro GCC use these instead of the older byte-by-byte operations. Unfortunately older kernels turn off this hardware support when in kernel mode and trap instead. Could you try adding a '-mno-unaligned-access' and try again? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Installing the armel libc on armhf
On 11 May 2012 02:50, Christian Robottom Reis k...@linaro.org wrote:
On Mon, May 07, 2012 at 11:51:47AM -0700, Marcin Juszkiewicz wrote:
W dniu 06.05.2012 16:06, Michael Hope pisze:
Hi there. Hopefully an easy question but I'm stumped. How do I
install the armel softfp libc6 on a new Precise armhf install?
I set APT::Architectures to { armel } and then tried a apt-get
install libc6:armel but I get errors about the package not matching
the host architecture.
echo 'foreign-architecture armel' /etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main
universe' /etc/apt/sources.list.d/armel.list
apt-get update
apt-get install libc6:armel
not tested, should work
Where should this be documented so others can find it when they are
trying to do the same as Michael?
It's not official, but I have a page on patching a multiarch system so
you can build GCC:
https://wiki.linaro.org/MichaelHope/Sandbox/MultiarchWorkarounds
and it now has a note on installing other libcs. Matthias is working
on upstreaming the multiarch patch which will eliminate the first
three, and my hard float loader patch fixes the fourth.
-- Michael
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Installing the armel libc on armhf
On 8 May 2012 06:51, Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote:
W dniu 06.05.2012 16:06, Michael Hope pisze:
Hi there. Hopefully an easy question but I'm stumped. How do I
install the armel softfp libc6 on a new Precise armhf install?
I set APT::Architectures to { armel } and then tried a apt-get
install libc6:armel but I get errors about the package not matching
the host architecture.
echo 'foreign-architecture armel' /etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe'
/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install libc6:armel
Ah, that's the magic. The sources.list entry isn't needed as apt
automatically includes any foreign architectures in the update.
Probably only works as armhf is also on ports.ubuntu.com.
-- Michael
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Installing the armel libc on armhf
Hi there. Hopefully an easy question but I'm stumped. How do I
install the armel softfp libc6 on a new Precise armhf install?
I set APT::Architectures to { armel } and then tried a apt-get
install libc6:armel but I get errors about the package not matching
the host architecture.
-- Michael
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: qemu hardware gfx acceleration
On 10 April 2012 07:13, John Stultz johns...@us.ibm.com wrote: So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as to if these sorts of changes were making it back upstream to qemu, or if qemu had its own plans for hardware acceleration? Unfortunately there's little technical details in the post above. The video is clearly running on OS X, so I'm not sure if this will also be usable w/ Linux hosts, but I could be wrong there. Hi John. Peter can say more, but I think they've done two things: pass OpenGL operations through to the host and run a virtualised x86 Android image instead of a JITted ARM Android image. I don't know what's going upstream but the Google QEMU people are friendly and have cherry picked from us before. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Toolchain builds in LAVA
On 29 March 2012 04:20, Paul Larson paul.lar...@linaro.org wrote: On Wed, Mar 28, 2012 at 10:03 AM, Andrew Stubbs andrew.stu...@linaro.org wrote: On 28/03/12 03:26, Michael Hope wrote: Hi there. The GCC build time is approaching 24 hours and our five Panda boards can't keep up. Sounds like a good time to LAVAise the toolchain build process a bit more... As you know, I've been doing some experiments with this over the last few months. I was blocked by a LAVA bug for a while, but that's been fixed now. Here's the latest test run (done by Le Chi Thu): http://validation.linaro.org/lava-server/dashboard/permalink/bundle/d73af579ed77957615bd3db2d9055d82bb14299e/ The test fails due to a GCC build failure: //usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or directory This surprised me, because I thought it was using the same rootfs you had on the ursa boards, but I've not had time to do anything about it yet. Looks like something that can likely be resolved by adding a dependency for the test. However, if you need, or if it would be more convenient to have a custom rootfs for this, that's certainly an option. Nothing says we necessarily have to run these tests on nano, developer, etc... but if it's interesting to make it possible for later running this as part of a platform release test, it might be better to make them generic so that they don't depend on a custom rootfs. There's a switch coming up due to Precise and hard float and I'll normalise against the Linaro LEB and hwpacks then. developer is a good start but it'll need extra packages added. I'll script those up and spin a new image with them pre-installed rather than add speed and reliability issue of doing it at boot time. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Toolchain builds in LAVA
Hi there. The GCC build time is approaching 24 hours and our five Panda boards can't keep up. Sounds like a good time to LAVAise the toolchain build process a bit more... Mike Hudson and I talked about doing a hybrid LAVA/cbuild as a first step where LAVA manages the boards and cbuild does the build. The idea is: * There's a image with the standard toolchain kernel, rootfs, build environment, and build scripts * The LAVA scheduler manages access to the boards * The LAVA dispatcher spins up the board and then invokes the cbuild scripts to build and test GCC This gives me a fixed environment and re-uses the existing build scripts. In the future these can be replaced with different LAVA components. There's a few details: * cbuild self updates on start so the image can stay fixed * Full results are pushed by cbuild to 'control' * The dispatcher records the top level log and an overall pass/fail * No other bundles are generated Most of this fits in with the existing LAVA features. There's a few additions like a 'run command' JSON action, passing the board name to the instance, and passing the job name as an argument. These seem OK. I'd like some of the boards to be fitted with fast USB flash drives for temporary storage. SD cards are slow and unreliable especially when GCC is involved. Thoughts? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On 19 March 2012 21:48, Konstantinos Margaritis konstantinos.margari...@linaro.org wrote: On Sun, 18 Mar 2012 23:27:17 + Mans Rullgard mans.rullg...@linaro.org wrote: FWIW, Gentoo has been using arm-hardfloat-linux-gnueabi for hardfloat configurations ever since gcc started supporting it. That's of course not a triplet, strictly speaking. Also fwiw, I have been assured from Gentoo developers that they will change their triplet to arm-linux-gnueabihf as soon as upstream adopts it. I find the situation sad as well, since Linaro has been pushing for this triplet (at least the OCTO team and me personally for more than a year), and not having full support from within Linaro with regards to this matter is quite depressing. And I have to say, especially one of the arguments (Windows storage issue) should be irrelevant for a Linux problem. I'm happy to make changes. Here's what I need: * Runs on the top four Linux desktop distros (plus RHEL) * The state of the art in performance (hard float + A9) * Support for one target distro * Installable by an unprivileged user * No feature regressions. If we change triplets, we change it once Here's what I'd like: * No hard break in compatibility * Usable across a product range, including non Cortex-As * The fastest Cortex-A15 configuration * Not prohibit dropping in a Fedora or other ARMv7 hardfloat sysroot * No surprises. The same command should give the same output, no matter who supplies it which means: * Multilib for the non-ABI variants * A armv4t libgcc for u-boot * Enough support so an end user can drop in a softfp sysroot and use it I'd prefer not to invalidate all the documentation out there by having a hard break in triplet. Perhaps the default is gnueabihf and we provide gnueabi symlinks? This breaks the rule of no surprises as there'd be a difference in behaviour between the Debian and Linaro binary builds and probably loader name issues. Note that the binary toolchain is a product compiler that inherently has a sysroot. The needs are different to distro native compiler or a Debian cross-develop setup. The upstream scripts do not recognise gnueabihf. Our policy is to be equivalent to upstream and have no long term ( 6 month) patches. I'm happy to take a patch providing someone commits to getting it upstream in a reasonable time. I've updated the wiki page with the new arguments. Linaro should move as one and use the same best practice across all groups. I'm happy to take the patches and risk but driving this change is not in toolchain's mission. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On 20 March 2012 01:42, Andrew Stubbs andrew.stu...@linaro.org wrote: I think the correct solution to this would be to have the binary toolchain built in a multilib configuration that supports both softfp and hardfp, and provide aliases for both triplets that configure the right setting, but that requires more build, test, and install effort and trickery, and it's not clear how much benefit there would be. It's not trivial with the current tools. The loader name changes as well but this isn't critical - we don't need to support more than one distro, just not lock out other uses. I don't really understand why the compiler name can't just be changed to match the ABI change though? Upstream GCC recognises arm*-*-linux*-*eabi and not *eabihf. Other packages may be the same. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On 17 March 2012 08:10, Loïc Minier loic.min...@linaro.org wrote: On Fri, Mar 16, 2012, Michael Hope wrote: https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration Is there a separate plan for gcc-4.5 deprecation in source releases? Yip, I'll send an email on that today. The triplet situation is sad; is there any hope that we fix this upstream? It's not for Linaro to change but for Debina/Ubuntu. The upstream canonical triplet is arm-linux-gnueabi for any configuration including soft or hard float. We talked about this at a cross distro session and Steve McIntyre was going to push some of the first steps. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro GCC 4.6 entering maintenance; 4.5 end of life
This is the first announcement on upcoming changes to the supported Linaro GCC versions. GCC 4.7 is expected out in the next two weeks. We plan to switch to 4.7 for the Linaro GCC 2012.04 release and, as part of that, will put Linaro GCC 4.6 into maintenance and retire Linaro GCC 4.5. While in maintenance we will continue to update, fix bugs, and do releases on 4.6. No further changes or releases will be made to 4.5. All historical releases and branches will stay available. For more informatio, please see the flyer at: https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer especially the section on Lifecycle: https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer#Lifecycle The formal change notes will be sent after the 2012.04 release. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Plan for changing the binary toolchain to 4.7 and hardfloat
Hi there. Over the next three months both GCC 4.7 and Ubuntu 12.04 'Precise' are coming out. We'll switch over to these pretty quickly which will affect our internal testing and anyone using the binary toolchain. The changeover plan including dates, details of what's happening, and backwards compatibility is at: https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration Comments and concerns are welcome, -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Downtime Planned
On 16 March 2012 15:50, Paul Larson paul.lar...@linaro.org wrote: This is just an early notification that the Linaro validation farm will be physically moving to a new site next week. Unfortunately, the network cables won't stretch that far, so it will mean some downtime. :) Here's the tentative plan: Wednesday, March 21st - the rack with the toolchain server will be shut down, crated and sent off Thursday, March 22nd - pretty much everything else will go offline (main LAVA server, development boards) I'll pause the tcpanda boards on Tuesday and shut them down on Wednesday. Our release is done so this should be fine. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On Wed, Mar 7, 2012 at 3:50 AM, Rob Herring robherri...@gmail.com wrote: On 03/04/2012 04:02 PM, Michael Hope wrote: I'd like to have one KVM kernel image which is suitable for the real hardware host and the virtio based guest. The single zImage plus Device Tree work seem like a great way to do this. We're currently using the vexpress-a15 on a Fast Model as the host and a vexpress-a15 as the guest. Device Tree support is required to describe the virtio-mmio devices. As a bonus, the vexpress-a9 and vexpress-a15 are the same hardware with a different memory map and can help demonstrate the Device Tree support. Except LPAE and non-LPAE will be 2 different builds... At least you will be able to run the same non-LPAE kernel build on both. Hardware virtualisation requires LPAE and we're planning on LPAE in the guest to match. What are the plans for single zImage? Where does the vexpress-a15 fit in with that? Could I bump it to the front of the list? DT support for vexp A9 is going into 3.4 I believe. Pawel has been working on it and can probably give details on A15 support. A single kernel for these 2 platforms (and A7 as well) is much simpler than getting to a single zImage in general (i.e. omap plus i.mx). But we'll be a lot closer in 3.4. Linus 3.4 or the Landing Team 3.4? From other emails it seems that the work may be more on the packaging side. Where are the Device Trees hosted? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On Tue, Mar 6, 2012 at 12:45 AM, Alexander Sack a...@linaro.org wrote: On Sun, Mar 4, 2012 at 11:02 PM, Michael Hope michael.h...@linaro.org wrote: I'd like to have one KVM kernel image which is suitable for the real hardware host and the virtio based guest. The single zImage plus Device Tree work seem like a great way to do this. We're currently using the vexpress-a15 on a Fast Model as the host and a vexpress-a15 as the guest. Device Tree support is required to describe the virtio-mmio devices. As a bonus, the vexpress-a9 and vexpress-a15 are the same hardware with a different memory map and can help demonstrate the Device Tree support. What are the plans for single zImage? Where does the vexpress-a15 fit in with that? Could I bump it to the front of the list? single zImage is already used for describing our final goal of having a single zImage for all boards... I think there is some way to go for that (especially since we do not yet have a single source tree). For stuff that can be tweaked through DT right now, I don't see why we couldn't have a single zImage ... e.g. like in your case having ability to boot vexpress-a15 in two different setups through different device tree... Most likely would require some platform plumming to ship two or more DTs for one kernel. What do we need for that? I guess we need a way to have two different device trees produced into the same image/hwpack and make it easy to decide at deploy time what u-boot is supposed to select? Good point on Device Tree. We'll do the same as x86 when starting the guest which is to pass the kernel, initrd, and (now) Device Tree directly to QEMU. We'll still need a vexpress-a15 hardware pack. This is mainly for testing and won't be released so a name like 'vexpress-kvm' might be better to prevent confusion - it's not coming from a Linaro tree and isn't supported on the real vexpress-a15. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Benchmark summary for Linaro GCC
The topic of benchmarking keeps coming up. We're working on making the next FSF release better, but it's a good idea to track how the current Linaro GCC stacks up against other releases. The summary is at: https://wiki.linaro.org/Internal/ToolChain/Now Included is how our current 4.6 release does against FSF 4.6, the change over six months, and how the upcoming 4.7 release fairs. There's also a comparison against other compilers including the Google 4.6 and Android 4.4 branches. A PDF version is attached to the page. The SPEC 2000 results are still coming in so I'll update the page once they arrive. Everything is generated so we'll update this with each monthly release. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Toolchain Working Group @ Linaro Connect
Here is a list of things we plan to talk about and do in the toolchain group next week: https://wiki.linaro.org/MichaelHope/Sandbox/Q1.12Plans Some of the 'next steps' topics will become more concrete this week. If you're interested in specific topics, let me know or just come on by. We'll be hacking away most of the time. -- Michael /shamelessly copying Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Architectures to support when releasing binaries
On Tue, Jan 17, 2012 at 1:21 AM, Alexander Sack a...@linaro.org wrote: On Mon, Jan 16, 2012 at 3:32 AM, Michael Hope michael.h...@linaro.org wrote: Hi there. I have a style question. For the pre-built versions of gcc-linaro, should we release a i686 version that also runs on x86_64, or do separate i686 and x86_64 builds? If we do just an i686 version then: * There's less to test * There's one 'linux' binary so less confusion on what to download and a simpler download page * Most end users will already have the 32 bit libraries due to Skype or Flash but it has some downsides: * May not work 'out of the box' * Cryptic failures if you don't have the 32 bit libraries installed Can we improve error reporting for those? Or maybe shipping a check-install script that probes for proper 32-bit libs? On a 64 bit system with no 32 bit libraries at all then you see the scary and misleading '-bash: arm-linux-gnueabi-gcc: No such file or directory'. Bash tried to run the program, couldn't find the lib/ld-linux.so.2 loader, and fails. I wonder if there's a fat binary style wrapper that can give you a more informative message. Say some 64 bit code that runs if you're on a 64 bit host that prints 'This is a 32 bit program. Please see README.txt for instructions on how to install the required 32 bit libraries.' I like the 'hey, if something's wrong run check-install.sh' idea. * Some users can't install extra packages and may not be allowed the 32 bit libraries What libs are potentially missing? How many of those could get linked in statically? Fairly minimal - just those provided by the LSB such as zlib, ncurses, libm, and libc. More esoteric libraries such as expat are already statically linked. Unfortunately a clean 64 bit install doesn't even include a 32 bit libc. It feels wrong to statically link it. Note that CodeSourcery's compiler is 32 bit only and dynamically links against libc. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Architectures to support when releasing binaries
Hi there. I have a style question. For the pre-built versions of gcc-linaro, should we release a i686 version that also runs on x86_64, or do separate i686 and x86_64 builds? If we do just an i686 version then: * There's less to test * There's one 'linux' binary so less confusion on what to download and a simpler download page * Most end users will already have the 32 bit libraries due to Skype or Flash but it has some downsides: * May not work 'out of the box' * Cryptic failures if you don't have the 32 bit libraries installed * Some users can't install extra packages and may not be allowed the 32 bit libraries There's no real performance or compatibility advantage in also having an x86_64 build. Any thoughts? I quite like having an i686 only build but am worried about the initial experience. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Binary toolchain preview
Hi there. We're putting together pre-built versions of the Linaro toolchain that cross-compile for the Linaro LEB and run on generic Linux or Windows. I've put a preview release together and would love some feedback. The binaries are available here: http://people.linaro.org/~michaelh/incoming/binaries/ The bug tracker is here: https://bugs.launchpad.net/linaro-toolchain-binaries There are a number of usability bugs logged already but nothing severe. You can also check out the requirements[1] and basic documentation[2]. Feedback is appreciated! -- Michael [1] https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/BinaryToolchain [2] http://people.linaro.org/~michaelh/incoming/binaries/README.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Presentation on benchmarking techniques
Hi there. I did a presentation on benchmarking techniques recently that covered our method, measuring, the statistics, and some future directions like STM. A copy is available at: http://people.linaro.org/~michaelh/presentations/Benchmarking%20Techniques%20r6.pdf The notes version is a bit more readable: http://people.linaro.org/~michaelh/presentations/Benchmarking%20Techniques%20Notes%20r6.pdf You can also get the original from Launchpad: bzr branch lp:~michaelh1/+junk/benchmarking-techniques -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: December release schedule
On Wed, Nov 23, 2011 at 5:58 AM, Fathi Boudra fathi.bou...@linaro.org wrote: Hi, Since most people will be on holidays, we have a modified schedule for December Christmas release. The current plan is to release one week earlier: * 2011-12-08 Toolchain WG 2011.12 release * 2011-12-15 Components 2011.12 release * 2011-12-22 Linaro 11.12 release The schedule has been updated on the wiki: http://wiki.linaro.org/Cycles I'd rather not as I'm travelling that week. I'll check with my group though. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Value of Thumb-2
On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe james.tunnicli...@linaro.org wrote: This isn't exactly overflowing with up to date numbers, but... http://elinux.org/images/8/8a/Experiment_with_Linux_and_ARM_Thumb-2_ISA.pdf Slides 14 and 15 say that across EEMBC Thumb-2 gives 98% of the performance of ARM 32 bit instructions (assume performance optimised) and binaries are 26% smaller (didn't catch what binary/binaries that was). These are numbers from 2007 and benchmarked on an ARM 11. I assume using ARMCC. I just ran EEMBC with gcc-linaro-4.6-2011.10 with -mfpu=neon -O3 -mtune=cortex-a9 and got similar numbers. Five of the 32 tests ran faster with Thumb-2 which is nice. I'll send the results privately as I'm not sure we can share. EEMBC embeds the test data in the executable so it it's hard to tell the change in text size. After de-duplicating, the average on-disk package size was 88 % of the ARM version. Ignoring the ones that are likely to have embedded test data, the average text size was 82 % of ARM mode. These days we're not really short of RAM so, as Mans says, improvements in startup time, cache footprint, or on-disk size might be a win. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Value of Thumb-2
On Fri, Oct 21, 2011 at 11:16 AM, Mans Rullgard mans.rullg...@linaro.org wrote: On 20 October 2011 23:07, Michael Hope michael.h...@linaro.org wrote: On Fri, Oct 21, 2011 at 7:48 AM, James Tunnicliffe james.tunnicli...@linaro.org wrote: This isn't exactly overflowing with up to date numbers, but... http://elinux.org/images/8/8a/Experiment_with_Linux_and_ARM_Thumb-2_ISA.pdf Slides 14 and 15 say that across EEMBC Thumb-2 gives 98% of the performance of ARM 32 bit instructions (assume performance optimised) and binaries are 26% smaller (didn't catch what binary/binaries that was). These are numbers from 2007 and benchmarked on an ARM 11. I assume using ARMCC. I just ran EEMBC with gcc-linaro-4.6-2011.10 with -mfpu=neon -O3 -mtune=cortex-a9 and got similar numbers. Five of the 32 tests ran faster with Thumb-2 which is nice. I'll send the results privately as I'm not sure we can share. How much faster? What about the ones that didn't run faster? More than 10 %. I can't share raw numbers in public as our EEMBC license doesn't allow it. I've sent the raw numbers to the linaro-toolchain-benchmarks list. I also don't think EEMBC is representative of real-world apps. Agreed. It's an embedded benchmark. SPEC would be interesting. EEMBC embeds the test data in the executable so it it's hard to tell the change in text size. The 'size' command? It turns the images and such into C arrays so they appear in the text segment. Hmm, I wonder if they get split into .rodata? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Easy crossbuilding of package sets/images
On Wed, Oct 12, 2011 at 1:23 AM, Wookey woo...@wookware.org wrote: One output from the 11.09 release was a reasonably painless way of cross-building whole images against an archive, which also forms the basis for an auto-crossbuilder. There is a HOWTO (for building linaro-nano images) here: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossBuildNano (It uses armel as the example, but should work the same for armhf) Summary of process -- Essentially you can generate a cross-building chroot in one command (using multistrap), chroot into that (using schroot), and give the builder (xbuilder-simple) a list of packages to build - either a pre-generated one for an image, or your own. It chunters through and builds them all (using xdeb), and leaving build-logs for each package. Then at the end (from outside the chroot) you cross-generate an image from the debs (using multistrap, but the pile could be input for a different tool if you prefer). -- To make this work usefully against a stable (natty) baseline, updated versions of both tools and packages are in two PPAs at: https://launchpad.net/~linaro-foundations/+archive/cross-build-tools and https://launchpad.net/~linaro-foundations/+archive/cross-alip Caveats --- This is currently a technology demonstration in so far as some of the packages needed for a nano image don't successfully cross-build, so you can't actually currently cross-build all of it, but that should be fixed quite soon. Anyone who wants to help with that is very welcome. I've filed current status and remaining bugs here: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LinaroNanoStatus The autobuilder can actually run just as well using pdebuild-cross as xdeb to do the build-work, but that's not been tested for a while and is not covered in the HOWTO. The existing xbuilder is pretty stupid (that's why it's called xbuilder-simple) and it does not yet fully ensure a clean build environment every time (when using xdeb, it should if using pbuilder-cross), but it does enough to work reasonably well in practice. A more rigorous environment reset is on the list of improvements RSN. Ongoing work The current focus is on getting the remaining packages cross-building so that the whole process works to completeion without cheating by bringing in pre-built packages from the existing archive (That's a useful way to proceed if you want to use this tech today - just adjust the multistrap config to include the base natty armel/armhf archive too) Once this is completed I'll be setting up a continuously-running autobuilder so that the cross-buildability or otherwise of packages can be more easily discovered and more people can get involved in fixing up packages so that cross-building of larger images becomes realistic. Nice. So with the proper setup I could inject a different GCC and use this as a compiler testsuite? Perhaps with NEON and -O3 on by default? I know we don't support it, but could it build an ARMv5 subset of Ubuntu? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android tip built with gcc 4.6 tip
On Sat, Sep 10, 2011 at 7:15 AM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: On 9 September 2011 08:35, Christian Robottom Reis k...@linaro.org wrote: Good job on proactively looking for bustage. I assume you guys worked out a plan with Michael on how to provide feedback on the issues we find -- let me know if that needs work. I presume normal bug reports will do the trick... When you say gcc tip code above, I think you actually mean gcc-linaro tip code. Is that right? yes The gcc build has already been patched with http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50116.patch http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50266.patch For the sake of sanity, it may help to name those patches using PR instead of bug as they actually refer to GCC PRs. OK with me -- I've symlinked them so new builds may use pr while old ones keep working. Are those patches not going to make it into the 11.09 gcc-linaro spin? Not sure - the bug is tracked in https://bugs.launchpad.net/gcc-linaro/+bug/827990 so the toolchain guys are aware of it. Since the bug breaks our build, we need the fix in right now - so until it does get in, we're using the GCC_PATCH_URL mechanism to inject the patches. Yip, this patch will be in this weeks release. The fix was done in the upstream release branch and will come down as part of our monthly merge-from-trunk. The merge request for this is at: https://code.launchpad.net/~ams-codesourcery/gcc-linaro/merge-from-fsf-20110908-4.6/+merge/74630 The auto builder built it fine on i686, x86_64, A9, and ARMv5. The testsuite changes still need to be investigated. Bernhard has done the right thing and pulled the upstream patch to meet their immediate need. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.07 oprofile on panda busted?
On Fri, Sep 2, 2011 at 11:52 PM, Avik Sil avik@linaro.org wrote: On Wednesday 31 August 2011 08:26 PM, Dave Martin wrote: On Thu, Aug 25, 2011 at 04:48:57PM -0500, Tom Gall wrote: The perf patch was dropped from linux-linaro-2.6.39 onwards as it apparently caused Panda boot hang (https://bugs.launchpad.net/linux-linaro/+bug/802693). Sorry, who is working on this and when is it going back in? perf is a significant feature and Panda is a very common board... -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Choosing the timer to use in benchmarking
On Wed, Aug 31, 2011 at 12:38 AM, Turgis, Frederic f-tur...@ti.com wrote: Hi, What was the timer used previously for benchmarks ? It was a bit random across the different suites. CoreMark uses clock_gettime(CLOCK_REALTIME, ...) which is a wall clock with NTP adjustments. EEMBC uses clock() which is a lower resolution wall clock. I was quite impressed with how steady the process clock was under different CPU loads. It doesn't seem to round up or down to a scheduler tick either which is nice. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Choosing the timer to use in benchmarking
Being able to accurately and consistently measure the elapsed CPU time is important for toolchain benchmarking. I ran a few experiments today and wrote up the results at: https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/TimerAccuracy The original is available at: http://bazaar.launchpad.net/~michaelh1/linaro-toolchain-benchmarks/trunk/view/head:/reports/timer-accuracy.rst Short story: * Use clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) * The mean is unaffected by CPU load * I/O load has a significant effect * Use nice -n -20 to reduce the variance For a CPU bound, non-VFP, L1 bound, 5 s long program: * The variation coefficient is 0.01 % so we can reliably measure 0.1 % changes * The accuracy is around 50 us I've changed eembc-linaro and will change denbench-linaro next. I recommend anyone else measuring time on core based benchmarks to do the same. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: GDB multi-threaded debugging?
On Wed, Aug 24, 2011 at 2:46 AM, Christian Robottom Reis k...@linaro.org wrote: I've decided to take a look at this moderately quiet l.k.embedded list and noticed this question: Is it possible to debug multi-threaded applications using gdb on ARM these days? http://thread.gmane.org/gmane.linux.kernel.embedded/3631 This is completely supported now, right? Pretty sure. Non-stop debugging (halting one thread while others keep running) is being done outside Linaro (hi Yao!) and is still in progress. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android gcc 4.6 1107 optimization benchmark
On Mon, Aug 22, 2011 at 11:31 PM, Chao Yang chao.y...@linaro.org wrote: HI Michael, The build log can be found at http://people.linaro.org/~chaoyang/shared_sources/build_2011-08-19_20-33.log The benchmark wiki page https://wiki.linaro.org/ChaoYang/Sandbox/gccoptimization is updated on 1. Adding benchmark for -fno-inline-function option (the size is reduced a bit) 2. Replacing O2 with O3 in build/core/combo/select.mk (a bit better results) I picked a command line at random and had a poke through it. There's a few interesting things: It includes -fgcse-after-reload and -finline-functions at all levels. These are normally in -O3 only, which may be why the -O2 results are so similar to -O3. It includes both -msoft-float and -mfloat-abi=softfp. softfp occurs second but you might want to remove the potentially conflicting -msoft-float. It uses -fno-strict-aliasing which reduces the number of optimisations that can be done especially at high optimisation levels. It uses -Wstrict-aliasing=2, i.e. turned down from the default -Wstrict-aliasing. I suggest removing the =2. It uses -fno-inline-functions-called-once which turns off a common optimisation. It uses -frename-registers and -frerun-cse-after-loop, which are normally part of -funroll-loops. I recommend pulling out most of the -f flags and re-running at -O2 and -O3. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Generic Linux cross toolchain for tests
On Tue, Aug 23, 2011 at 1:21 AM, Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote: Hi Some time ago we agreed that not everyone here uses Ubuntu distribution and decided to provide so called 'generic linux' cross toolchain. Recently I managed to get it done and now need brave testers to tell is it working or not. Get it here: http://people.linaro.org/~hrw/generic-linux/ (64bit only) Needed files are toolchain-11.07.tar.xz and init.sh script. Unpack tarball from / so /opt/linaro/11.07/ will be populated and put init.sh anywhere you want (it will be integrated into tarball later). How to use: $ source init.sh this will add cross toolchain into PATH and also set LD_LIBRARY_PATH to two directories: - one with binutils libraries - second with all extra libraries which may be needed Nice, I'm really happy that the libs are split out instead of statically linked. You should be able to use ld.so's $ORIGIN and rpath to find the libraries automatically. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Input for an optimized slide
On Sat, Aug 20, 2011 at 7:13 AM, Zach Pfeffer zach.pfef...@linaro.org wrote: Thanks Bero. Sending this extremely useful information out to a wider audience. Alex, I think you're probably be very interested in this for your Mozilla work. -O3 * What is is, does, available on -O3 enables several additional compiler optimizations such as tree vectorizing and loop unswitching, and optimizes for speed over code size somewhat more aggressively than -O2, e.g. by inlining all calls to small static functions. It is available on any platform supported by gcc. OpenMP * What is is, does, available on OpenMP is a simple API that makes it easier for a programmer to make use of multi-core or multi-processor systems, e.g. by automatically splitting marked loops into several threads. Example: #pragma omp parallel for for(int i=0; i100; i++) do_something(i); Would use up to 100 threads to do its job. It is available on plaforms supported by gcc that can use libgomp, gcc's OpenMP library. This includes most platforms that support POSIX threads - but -- initially -- not Android. Loop parallelization * What is is, does, available on Loop parallelization takes OpenMP a step further by automatically determining which loops are suitable for #pragma omp parallel for and similar constructs. This allows code that was written without multiprocessing in mind (such as most code written specifically for ARM platforms - multicore/SMP ARM systems are quite new) to take advantage of multicore/SMP systems (to some extent) without having to modify the code. Compiler flag: -ftree-parallelize-loops=X (where X is the number of threads to be optimized for - typically the number of CPU cores in the target system) Available on anything supported by gcc that has both libgomp and graphite (incl. CLooG, PPL or ISL) - the original Android toolchain has neither of those. ...and any other optimizations that you've done. None of the following is enabled yet (but the support in the toolchain is there now), but I'm planning to enable them step by step once we have systems built w/ the new toolchain that actually boot: binutils: --hash-style=gnu By default, ld creates SysV style hash tables for function tables in shared libraries. With --hash-style=gnu, we switch to GNU style hashes, making symbol lookup a lot faster. (details: http://sourceware.org/ml/binutils/2006-10/msg00377.html) Sorry, silly question, but does Android use the glibc dynamic linker? If not, does its linker support other hash styles? binutils: -Bsymbolic-functions Speed up the dynamic linker by binding references to global functions in shared libraries where it is known that this doesn't break things (it's safe for libraries that don't have any users trying to override their symbols - it's probably safe to assume e.g. skia and opengl could benefit). (details: http://www.fkf.mpg.de/edv/docs/intel_composer/Documentation/en_US/compiler_f/main_for/copts/common_options/option_bsymbolic_functions.htm) binutils/gcc: -flto, -fwhole-program Link-Time Optimization - causes code to be optimized again at link time, when the compiler knows what functions are called form what parts of the code, what functions are only called with constant parameters, etc. gcc: -mtune=cortex-a9 (or whatever the actual target CPU is) The Android build system uses -march=arm-v7a, which is good -- but it doesn't do any tuning for the specifc CPU type (e.g. cortex-a8 vs. cortex-a9). Good. Using -march=armv7-a -mtune=cortex-a9 enables the Cortex-A8 fixups. Using a -mcpu=cortex-a9 disables them which means your build may not run on an A8. gcc: -fvisibility-inlines-hidden Don't export C++ inline methods in shared libraries. Makes the symbol table smaller, improving startup time and diskspace efficiency gcc: -fstrict-aliasing -Werror=strict-aliasing Currently, Android uses -fno-strict-aliasing unconditionally for thumb code, to work around some pieces of code that violate strict aliasing rules. Using -Werror=strict-aliasing, we can determine what pieces of code are affected, and fix them, or limit the use of -fno-strict-aliasing to the specific files that need it - enabling the rather useful strict-aliasing optimization for the rest of the build gcc: Investigate Graphite optimizations that aren't even enabled at -O3: -fgraphite-identity -floop-block -floop-interchage -floop-strip-mine -ftree-loop-distribution -ftree-loop-linear Looks good. I'd add SMS to the list as well: first -fmodulo-sched, then -fmodulo-sched -fmodulo-sched-allow-regmoves. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android gcc 4.6 1107 optimization benchmark
On Sat, Aug 20, 2011 at 2:50 AM, Chao Yang chao.y...@linaro.org wrote: HI Bero, What I did was changing both Os and O2 to O3 in TARGET_linux-arm.mk. I did not change those O2/Os specified in each module internally. As there may be a reason for the module itself to specify the optimisation level. I think it is risky to change those. But I don't think it should be a big problem. Do you have the build log? You could do a quick grep over it to see if the GCC command line is sane. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 3D Demo at ARM
On Fri, Aug 19, 2011 at 2:21 AM, Andy Doan andy.d...@linaro.org wrote: On 08/17/2011 04:59 PM, Michael Hope wrote: On Wed, Aug 17, 2011 at 11:12 PM, Dave Martin dave.mar...@linaro.org wrote: On Tue, Aug 16, 2011 at 7:14 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: Nicolas, Thanks for the notes. As you say there are many, many things that can affect this demo. What notes like this really underscore is the importance of staying up-to-date. This demo is more about the macroscopic effects from tip support than anything else. We do have some more specific benchmark numbers at: https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking If we're confident that the benchmark produces results of a trustworthy quality, then that's fine. I don't know this benchmark in detail, so I can't really judge, other than that the results look a bit odd. Ditto on that. Have these benchmarks been qualified? Do they represent real workloads? Where do they come from? What aspects of the system (CPU, memory, I/O, kernel, SMP) do they exercise? How sensitive are they to minor changes? The benchmark code comes from Android: http://android.git.kernel.org/?p=toolchain/benchmark.git I'm not an expert on benchmarking. I've just tried to focus on running these in a way that's as fair and repeatable as possible. OK. Just keep an eye out then. If the benchmarks are dominated by things that Linaro isn't working on (such as I/O performance or memory bandwidth) then the results won't change. If they're dominated by certain inner functions that are very sensitive to environment changes, then you may see a regression. Benchmarks need to represent the workloads of a real system. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android gcc 4.6 1107 optimization benchmark
On Fri, Aug 19, 2011 at 2:40 PM, Chao Yang chao.y...@linaro.org wrote: HI Zach, The BP (https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-use-gcc4.6-with-o3) and Bug #822113 aim at improving android performance. I think we also need to balance the size and the performance improvement. I used the gcc benchmark tool to benchmark the performance with different configuration: -O3 for arm files only, -O3 for both arm files and thumb files and -fstrict-aliasing. The results can be found at https://wiki.linaro.org/ChaoYang/Sandbox/gccoptimization. Please note, the results are based on linaro_android_2.3.4 for panda and toolchain-4.6-1107. I will benchmark linaro_android_2.3.5 and toolchain-4.6-1108 if necessary when they are stable enough. The image size increases significantly when -O3 is enabled for thumb files, however it does not look like performance has been improved as much as expected. Could you please let me know if you think it is worth building thumb files with -O3 regardless of size? Thanks. Regards Hi Chao. I'm a bit confused by your numbers. There is no significant difference between the performance or size numbers across the different options you tested, except the Thumb results which grew unexpectedly. My experience is that Thumb-2 is typically 75 % of the size of ARM and 95 % of the speed, and that -O3 is significantly faster than -O2. I just ran a popular deeply embedded benchmark and found: * In Thumb-2 mode, -O3 is 4.3 % faster than -O2 and 122 % bigger (!) * At -O3, ARM mode is 12.4 % faster than Thumb-2 and 12.2 % bigger This benchmark is a bit small which is why the code size blew out so much and the -O3 improvement is so small. I used the size of the .text section. bz2 compressing and taking the on disk size to more closely match your method gives: * -O3 is 86 % bigger than -O2 * ARM is 4.4 % bigger than Thumb-2 Is there something strange going on with your benchmarks or options? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Toolchain builders utilisation
On Wed, Aug 17, 2011 at 7:47 PM, Amit Kucheria amit.kuche...@linaro.org wrote: On Wed, Aug 17, 2011 at 7:02 AM, Michael Hope michael.h...@linaro.org wrote: Your distraction for the day... Toolchain has four PandaBoards that are used for building GCC, GDB, and other interesting programs. Here's a graph of how busy they are: http://ex.seabright.co.nz/misc/utilisation/ursas.png The green line is how many boards are currently running jobs. The blue line is how many jobs are queued up. The spike at day 3 is the end-of-week build of the upstream branches. The drop to three boards at day 7 is me reserving one for benchmarking. The spike at day 8 is the start of our release week where many commits and the final tarballs are built and tested. All boards were busy for seven days out of eight. I think I might need a few more... That is the smoothest play for a hardware grab I've ever seen. ;-) Heh. I wasn't sure I needed them but I am now. Especially as I've taken two out of the pool to run the extra release testing. Nice work Michael. Is the toolchain compile very CPU bound or is IO bandwidth a limitation for you guys? Just curious. On ARM it's CPU bound and takes about five hours for a build and another five for test. A dual-core A9 is a big step up over a typical A8. The cloud builders are interesting - an x86 build on EC2 on an eight core machine only uses 450 % CPU, while on a 2 CPU it uses 190 %. It's cheaper but slower to build on a fewer core machine. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Android Platform Team 2011-08-07 to 2011-08-14
On Thu, Aug 18, 2011 at 9:42 AM, Tony Mansson tony.mans...@linaro.org wrote: -O3 for gcc 4.6 works. Cool. What does 'works' mean and where is it written up? Is this with -mfpu=neon as well? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 3D Demo at ARM
On Wed, Aug 17, 2011 at 11:12 PM, Dave Martin dave.mar...@linaro.org wrote: On Tue, Aug 16, 2011 at 7:14 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: Nicolas, Thanks for the notes. As you say there are many, many things that can affect this demo. What notes like this really underscore is the importance of staying up-to-date. This demo is more about the macroscopic effects from tip support than anything else. We do have some more specific benchmark numbers at: https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking If we're confident that the benchmark produces results of a trustworthy quality, then that's fine. I don't know this benchmark in detail, so I can't really judge, other than that the results look a bit odd. Ditto on that. Have these benchmarks been qualified? Do they represent real workloads? Where do they come from? What aspects of the system (CPU, memory, I/O, kernel, SMP) do they exercise? How sensitive are they to minor changes? gnugo in particular is a problem - the results don't change across a range of toolchains which suggests it's got a silly hot loop or isn't core bound. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Toolchain builders utilisation
Your distraction for the day... Toolchain has four PandaBoards that are used for building GCC, GDB, and other interesting programs. Here's a graph of how busy they are: http://ex.seabright.co.nz/misc/utilisation/ursas.png The green line is how many boards are currently running jobs. The blue line is how many jobs are queued up. The spike at day 3 is the end-of-week build of the upstream branches. The drop to three boards at day 7 is me reserving one for benchmarking. The spike at day 8 is the start of our release week where many commits and the final tarballs are built and tested. All boards were busy for seven days out of eight. I think I might need a few more... -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Why are our Android toolchains 32bit?
On Thu, Aug 11, 2011 at 2:29 AM, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly? If nobody complains, I'll remove the -m32 flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it... I'd leave it as 32 bit. This gives you a single binary toolchain that can run on 32 bit and 64 bit hosts, no matter what host it was built on. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hacking Android from a Toolchain perspective
Hi there. One of our goals in toolchain is to give good support to the Android group. I've written a page from the toolchain perspective on what is Android, how do you build it, and how you do common toolchainy tasks like reproduce a compiler fault: https://wiki.linaro.org/MichaelHope/Sandbox/AndroidAndToolchain Comments are welcome. It needs sections on how the compiler is configured, running a program using adb, and basic debugging. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Break in gcc-linaro tarball naming conventions, was: Re: Bug 809768 integration into gcc 4.6 for Linaro Android 1107 release
(On holiday so short) The tarball name has changed to match the new Linaro conventions. I forgot to put that in the announcement. The inner directory name should change as well but was missed, sorry. On Jul 21, 2011 6:59 PM, Paul Sokolovsky paul.sokolov...@gmail.com wrote: Hello, Well, before proceeding further, there seems that tarball naming convention has changed. For example, now it's gcc-linaro-4.6-2011.07.tar.bz2 whereas before it was gcc-linaro-4.6-2011.06-0.tar.bz2 . What's worse is that inside it's still gcc-linaro-4.6-2011.07-0 top-level directory. The build script uses tarball basename to find out uncompressed dir name, so builds fail now. This can be worked around on build script level, but is example of random inconsistency, and if let such will proliferate, there will be more and more workarounds everywhere, so would be nice if toolchain WG fixed tarball name on their side. Thanks, Paul On Thu, 21 Jul 2011 10:18:21 +0300 Paul Sokolovsky paul.sokolov...@linaro.org wrote: On Wed, 20 Jul 2011 21:44:10 +0100 Chao Yang chao.y...@linaro.org wrote: Hi Paul, Just a reminder that the bug was found in gcc 4.6, to which, I think, the patch should apply, not 4.5 only. Oops, sure, I just copied the wrong link, it should be http://launchpad.net/gcc-linaro/4.6/4.6-2011.07/+download/gcc-linaro-4.6-2011.07.tar.bz2 instead. Thanks and regards On 20 Jul 2011 21:12, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello Ulrich, On Wed, 20 Jul 2011 21:07:50 +0200 Ulrich Weigand ulrich.weig...@de.ibm.com wrote: Zach Pfeffer zach.pfef...@linaro.org wrote on 07/20/2011 08:56:32 PM: Michael Hope michael.h...@linaro.org wrote: Hey, we're getting ahead of ourselves here. The patch clears the problem but it hasn't landed upstream and may not be correct. We also haven't laid the ground work for triaging the problem including: * Describing the compiler involved (mainly how it's built) * Reducing to a test case (normally preprocessed source) * Reproducing and reducing the fault Any fix can introduce other bugs, so it's generally best to work around a last minute issue and then test it properly for the next release. We have a range of options: * Work around it in the packaging (such as changing the optimisation level, turning of debug, etc) * Work around it in the source * Carry a local patch to GCC * Use an earlier release (say 2011.05) We should talk about this in Cambourne especially in untangling what the Android compiler is, how it's built, and adding it as a test case for our releases. Michael, Thanks for the feedback. Lets chat at Cambourne. For right now, can we reference Ken's tree to build a WIP Android to facilitate debugging? Could Ken continue to work with Chao to create a testcase that shows the bug? I have our session on Wednesday at 11:00 AM now where we can sort out some more structural issues. [Pulling in Richard on CC as well.] Note that by now Richard has done a proper fix of the underlying compiler problem, which has now landed upstream: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html So my recommendation would be to use this month's Linaro GCC release with Richard's patch on top as the basis for the Android compiler. (By next month, I'd assume Linaro GCC will contain Richard's patch to start with.) That sounds like good plan. So, what process the toolchain team would suggest for this? I can imagine few choices: 1. Toolchain team prepares a tarball for Android team, which is http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-2011.07.tar.bz2 + http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html 2. Toolchain team creates a bzr branch withich is 2011.07 release (with any possible bugfix releases) + that patch applied. 3. I just add support for applying patches to android-build and build http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-2011.07.tar.bz2 with the patch applied. My own preference probably would be even p.3, as it doesn't create extra entities, but as we want more people try and adopt Linaro tools, p.1 would be still preferable I guess. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http
Linaro GCC 4.4 end-of-life reached on June 28, 2011
This note is to confirm that support for Linaro GCC 4.4 formally ended on June 28, 2011. The recommended upgrade path is to our current Linaro GCC 4.6 development branch or to our Linaro GCC 4.5 maintenance branch. Third-party fixes continue to be accepted for Linaro GCC 4.4 and all releases, branches, and history will remain available. Since entering development in July 2010, we have made eight releases containing many new features 22 bug fixes. Linaro GCC 4.4 was our first release and set the stage for the current, ongoing work. -- Michael Hope Toolchain Technical Lead ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro GCC 4.5 entered maintenance on June 28, 2011
This note is to confirm that Linaro GCC 4.5 entered maintenance on June 28, 2011. The new development branch is the 4.6.1 based Linaro GCC 4.6. Linaro GCC 4.5 continues to be actively supported with select high-impact bug fixes and will remain so until it enters end-of-life, shortly after Linaro GCC 4.7 is released. Monthly releases will be made alongside the new development release. -- Michael Hope Toolchain Technical Lead ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RFC: Linaro GCC stable branch
I'm considering starting an extra branch of Linaro GCC for use in the final stages of development and would like your input. Our goal is improve the performance of real, shipping products and to help the their time to market. We make improvements and fixes to FSF GCC and then backport them to Linaro GCC so that you can pick up these improvements early. The problem comes when you're nearing release time as picking up a new release for a needed bug fix also pulls in new features which might introduce bugs. To reduce the risk, we could run a stable branch or bolster up the FSF stable branch. The Linaro stable branch would: * Start from Linaro GCC and its many performance improvements * Only take bug fixes * Be tested and released every month * Run for six months at a time * Work in the same way as our main release including support and having binary builds The idea is that you could track the main branch during development and switch to the stable branch during the last few months. This gives a good mix of the latest performance with less risk at release time. Bolstering up the FSF stable branch approaches the problem a different way. We work upstream, so all of our improvements are available in an upstream release, but perhaps a year later than via Linaro GCC. We could take the mainline releases, add binary builds, and generally boost mainline support. The FSF stable branch would: * Start at the upstream 4.x.1 release such as 4.6.1 * Only take regression fixes * Be tested and release with each (roughly quarterly) mainline release * Run for the roughly twelve months until the next mainline 4.y.1 release * Give a good path if you move away from Linaro in the future Any comments are appreciated. There's more background and discussion on the wiki at: https://wiki.linaro.org/MichaelHope/Sandbox/StableBranch I'm particularly interested in comments from people making products, distributions, or IDEs such as: * Is a stable branch useful? * How long does it need to be supported for? * When do you freeze your toolchain? * Should we spend our time elsewhere such as on more performance, faster bug fixes, more documentation, being in more distributions, or being available in other ways such as binary builds? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Error in compile 11.05 linux kernel using 4.5.1 linaro toolchain
On Tue, Jun 21, 2011 at 4:31 PM, Amit Mahajan amit.maha...@b-labs.com wrote: Hi, I am compiling 11.05 release linux kernel using linaro gcc-4.5.1. Getting following errors: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j 8 CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALL scripts/checksyscalls.sh CHK include/generated/compile.h Building modules, stage 2. Kernel: arch/arm/boot/Image is ready SHIPPED arch/arm/boot/compressed/lib1funcs.S AS arch/arm/boot/compressed/lib1funcs.o MODPOST 1736 modules LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8974.ko] undefined! ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8940.ko] undefined! ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8510.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Division symbols seems missing. Hi Amit. This is a known issue with the compiler. See LP: #771832 at: https://bugs.launchpad.net/gcc-linaro/+bug/771832 The problem exists in all 4.6 based compilers. The work around is to change the kernel configuration and disable Device Drivers - Sound card support - Advanced Linux Sound Architecture - ALSA for SoC audio support - Build all ASoC CODEC drivers. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Compiling kernel for panda linaro natty 11.05
On Tue, Jun 21, 2011 at 7:22 PM, Amit Mahajan amit.maha...@b-labs.com wrote: On Tue, 2011-06-21 at 12:14 +0530, Avik Sil wrote: On Tuesday 21 June 2011 12:06 PM, Amit Mahajan wrote: Hi, I have booted panda board using 11.05 natty release of ubuntu. It worked great. Now, I am trying to compile the kernel myself. I am using the sources from tarball provided on 11.05 release page as well as from linaro git 2.6.38 tree. I have extracted the .config from running ubuntu(of 11.05 LEB) and using it to compile my own kernels. Then I am just replacing the uImage on sdcard(generated using 11.05 LEB) by my compiled kernel. Boot process goes fine till the init process but then it fails to bring on the graphics and goes to console mode. Any help on this? You may want to install modules on the SD card too: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/media/rootfs modules_install I am getting these errors while building the modules. I have linaro gcc-4.5.1. Is it related to older gcc? AS arch/arm/boot/compressed/lib1funcs.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8974.ko] undefined! ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8940.ko] undefined! ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8510.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Hi Amit. This is a known issue with the compiler. See LP: #771832 at: https://bugs.launchpad.net/gcc-linaro/+bug/771832 The problem exists in all 4.6 based compilers. The work around is to change the kernel configuration and disable Device Drivers - Sound card support - Advanced Linux Sound Architecture - ALSA for SoC audio support - Build all ASoC CODEC drivers. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bug escalation procedure
On Thu, Jun 16, 2011 at 11:06 PM, Fathi Boudra fathi.bou...@linaro.org wrote: On 14 June 2011 21:53, Michael Hope michael.h...@linaro.org wrote: How does this relate to working group outputs? Here's my process BTW: https://wiki.linaro.org/WorkingGroups/ToolChain/BugProcess It's unusual for a bug to be a release blocker as there's normally some type of work around. I'd normally only stop or respin a release if the bug is embarrassing (which I guess is equivalent to Critical :) A bug can be qualified as a release blocker after the WG release, probably during Platform integration coming after your component release. It will result that the bug will be under the release team radar and we'll work together to fix it in time for the Platform release, most likely a respin is needed. I'd prefer to add a work-around to the package than respin. If no work around exists and the package is important enough then we can fix and respin, but note that any change to the compiler may affect a different package. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please help us setup patches.linaro.org
On Thu, Jun 16, 2011 at 1:26 AM, Guilherme Salgado guilherme.salg...@linaro.org wrote: Hi folks, http://patches.linaro.org/ went live yesterday and we need your help to set it up and get accurate metrics. It should take only a few minutes! The first thing we need is the HTTP URL for the upstream master branch of every project on the front page -- I'll take a git:// URL if that's all they have. If you could send me the URLs for the projects you contribute to, it'd be great. This has to be done only once and we'll use that to automatically detect when a patch is committed upstream. Hi. I've updated the page at: https://wiki.linaro.org/WorkingGroups/ToolChain/CodeImports with links to the primary projects we work on and a few secondary ones. Note that only QEMU natively uses GIT. Most have a GIT mirror though. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bug escalation procedure
On Wed, Jun 15, 2011 at 3:23 AM, Fathi Boudra fathi.bou...@linaro.org wrote:
Hi,
This is an update to the bug management process. The wiki page is:
https://wiki.linaro.org/Cycles/BugManagement
Cheers,
Fathi
--
Bug escalation procedure
It's important that bugs which affect the LEB's and other images are caught
early and fixed as soon as possible. To help the Linaro Release Team in
identifying and tracking the release blocker bugs, any individual could
propose
a bug as a blocker and follow the bug escalation procedure.
Prerequisite
* All bugs in a 'New' state should be sufficiently triaged to determine their
importance.
* All bugs in a 'High' or 'Critical' state should be highlighted to the Linaro
Release Team: Please, add it to the wiki page 'Bugs' section for the next
release meeting. The release meeting calendar can be found on the wiki.
Meetings are held on Thursday. If possible, attend the meeting.
Procedure
-
1. Subscribe Linaro Release Team ('linaro-release') to the proposed bug.
2. Linaro Release Team evaluates the proposed bug.
2a. Linaro Release Team accepts the bug as a release blocker:
* notify by a comment on the bug.
* set the milestone to the next release.
* assign to the appropriate team.
2b. Linaro Release Team rejects the bug as a release blocker:
* unsubscribe Linaro Release Team from the poposed bug.
How does this relate to working group outputs?
Here's my process BTW:
https://wiki.linaro.org/WorkingGroups/ToolChain/BugProcess
It's unusual for a bug to be a release blocker as there's normally
some type of work around. I'd normally only stop or respin a release
if the bug is embarrassing (which I guess is equivalent to Critical :)
-- Michael
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Draft daily (hmm) cloud builds of Android toolchain from bzr
On Wed, Jun 15, 2011 at 12:16 AM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello Michael, On Tue, 14 Jun 2011 08:41:21 +1200 Michael Hope michael.h...@linaro.org wrote: [] Note that it now expects bzr branch with explicit version, e.g. lp:gcc-linaro/4.5 or lp:gcc-linaro/4.6 . Minor nit: these are called 'series'. I understand that in Launchpad's terms it's series, but there's doesn't seem to be such notion on bzr level, so how they're represented in bzr - are they 2 separate repositories, or 2 branches of the same repo? Interesting question. Here's my understanding: * They are both branches * The could be stored as different repos * Both are stacked on top of another branch to reduce the download and storage cost * Both are originally forked from different places of a different branch How this ties in with the repo implementation I'm not sure. I think the technical history of the gcc-linaro branch is: * lp:gcc is a automatic import from GCC SVN * The lp:gcc-linaro stacked branch was created from the lp:gcc/4.5 branch * The lp:gcc-linaro/4.5 was branched off lp:gcc/4.5 and stacked on top of gcc-linaro * The lp:gcc-linaro/4.6 was branched off lp:gcc/4.6 and stacked on top of the 4.5 derrived lp:gcc-linaro -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Draft daily (hmm) cloud builds of Android toolchain from bzr
On Tue, Jun 14, 2011 at 12:41 AM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello, Alexander, I've set up builds of Android toolchain from bzr: https://android-build.linaro.org/builds/~pfalcon/linaro-toolchain-4.5-bzr/ https://android-build.linaro.org/builds/~pfalcon/linaro-toolchain-4.6-bzr/ Jim, I had to revamp bzr build in linaro-build.sh: http://git.linaro.org/gitweb?p=people/pfalcon/android/toolchain/build.git;a=shortlog;h=refs/heads/pfalcon Note that it now expects bzr branch with explicit version, e.g. lp:gcc-linaro/4.5 or lp:gcc-linaro/4.6 . Minor nit: these are called 'series'. Well, now the issue: the builds above are not quite ready to be daily. That's because bzr checkout is slow, and is also quite big. Normal bzr clone takes 1.1Gb and cloud build takes 1hr instead of 30min with a tarball. I tried to play with bzr checkout --lightweight, but ctrl+c'ed it when it showed that it dealt with 1.3Gb of stuff (surprisingly, after break, I saw almost empty local empty structure, so I wonder if that wasn't d/l counter, but even then it's awfully slow). So, where do we go from here? Unless there's tip export feature directly out of remote repo for bzr (bzr export seem to requite local working copy), we'd need to play mirror, this time bzr, again %). Make an initial shared repository, take an initial branch, tar it up, store it somewhere in the same zone, and use that to seed the checkout. That should cut the checkout to minutes and ~10 MB. See: https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)
On Mon, Jun 13, 2011 at 8:48 AM, Zach Pfeffer zach.pfef...@linaro.org wrote: Ken, Would you get a patch together for Google? This looks like a good small fix for when they upgrade to 4.5. Before pushing would you make sure that the fix doesn't break the current Android build. This should generate some good discussion about the underlying prelink issue. Note that this is a work-around and not a fix and should be presented as such. I'm afraid I don't want Ken to fix the root problem as it's not an area we're working on. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)
On Mon, Jun 13, 2011 at 9:20 AM, Zach Pfeffer zach.pfef...@linaro.org wrote: What's the root problem? Is there anyone else who can sort it out? Ah, there's the rub :) It could be in the Android specific prelinker, GCC, or in the code itself. The Android toolchain time I have set aside is for helping the Android group integrate our current outputs, and not for doing the initial triage or for working on new toolchain related components. We should talk about this with Kiko and co and figure out what's next. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 2 cross-development toochain quesions
On Sat, Jun 4, 2011 at 3:02 AM, Bernard Ogden bernard.og...@arm.com wrote: I was asked to take a look at the blueprints relating to cross-toolchain development (e.g. https://blueprints.launchpad.net/ubuntu/+spec/linaro-platforms-o-linaro-cross-toolchain-stories) in advance of Monday's 'Android and Developer Platform' plan review call. I just have two questions to ask for now: 1) I would like confirmation that the Windows binaries will be 'windows native' and standalone i.e. customer does not need to install MSYS/cygwin/etc. I got the impression that this is the intention, but am not 100% clear that it's a requirement. The build will be Windows native and self contained. Cygwin will not be used and any mingw support libraries will be minimal and shipped with the binary. The goal is to have something that is usable from a NT CMD prompt, cygwin prompt, and Eclipse. 2) Will Linaro test the toolchains on Red Hat Enterprise? RHEL 5 is one the supported platforms for DS-5, so it would be useful to know if the toolchain will be validated on that platform, or if we need to test ourselves. Not at the moment but we might slip it in to meet the requirement of working on the top four development Linuxes. As Marcin says, we'd test under CentOS instead of Redhat. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)
On Fri, May 27, 2011 at 11:20 PM, Alexander Sack a...@linaro.org wrote: Hi Jim, On Fri, May 27, 2011 at 1:06 PM, Jim Huang jim.hu...@linaro.org wrote: Hello list, If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager. To work around this problem, you can apply the following patch: --- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \ LOCAL_MODULE:= libgui +LOCAL_CFLAGS += -O0 + in channel you said that -O1 is also working ... do we need O0 here? one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue. we definitly should file a bug against linaro-android project and then also add gcc-linaro project so it gets visibility of toolchain WG. Hi guys. Yip, let's start doing this properly. Can I suggest the same as the Ubuntu relationship and methods? Basically: * You find an issue * Log a bug on Launchpad against the component or, failing that, linaro-android * Figure out if it is a toolchain or package problem * Figure out if there is a work around such as changing the optimisation level If it is a toolchain issue: * Feel free to do a work around in the package * Add the right tags so you can revert the workaround in the future * Mark the bug as affecting gcc-linaro * Provide sufficient information to reproduce the bug - preprocessed source would be great! and we'll get on to it. We'll need some help in setting up a test environment. Note that a lot of the triage work is on the distribution side (i.e. Android). -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Minutes from platform leads call 2011-05-24
On Wed, May 25, 2011 at 7:19 AM, Fathi Boudra fathi.bou...@linaro.org wrote: Hi, Available at https://wiki.linaro.org/Platform/2011-05-24 * AGREED: share a common format for the presentation to get a consistent layout across the platform teams. listing TRs, sorted by priority. * ACTION: whoever finishes first few slides to send around to agree on common format/layout. DEADLINE: 2011-05-25 I'd like to do the same. Could you send me a copy please? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The need for more verbose work item updates
On Wed, May 25, 2011 at 2:21 AM, Alexandros Frantzis alexandros.frant...@linaro.org wrote: Hi all, in some of the blueprints I am following, I have noticed that many work items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by any additional information. Of course, not all work items need more information, but some are meaningless to an external viewer without it. This is a general observation across Linaro and I am as guilty as any. As an example, consider the following (semi-fictional) work item updates: + Add Qt tracing support for pixmaps: POSTPONED + Create a bazaar branch for libX: DONE + Select and port an application to GLES2: DONE + Test that the application functions correctly on ARM: BLOCKED These updates raise many questions: * Why was Qt tracing for pixmaps postponed? * What is the exact location of the published branch? * Which application was selected for porting? * Where can I find the ported code for the application? * Why is the application test blocked? Such information is usually placed at the top of the whiteboard, like this (at least this is how I am doing it): [alf May 8]: Postponed work on Qt pixmap tracing because it turned out we can trace Qt/Webkit without it, so it is not considered critical anymore. [alf May 10]: Uploaded branch to lp:libX [alf May 10]: Selected application Y for porting to GLES2 [alf May 12]: Finished porting Y to GLES2 and uploaded it to http://git.linaro.org/... [alf May 13]: Blocked on testing the ported application Y because of an issue (LP: #66) with the 3D drivers for chipset Z. I've been thinking of using square bracket footnotes to add a bit more detail to things: --- Work items: Design extension foo[1]: TODO Add support for Thumb-2: DONE Add to project bar[2]: POSTPONED [1] will involve the kernel guys. Need to start this early. [2] postponed as it's been merged with blueprint X for next cycle. --- To bikeshed a bit, I prefer sortable dates with the year like 2011-05-25. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Would you like remotely accessible boards?
On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado guilherme.salg...@linaro.org wrote: If you do, I need to know more about how you'd like to use them, to make sure we provide something that is suitable to everyone. At this point I'm interested in drafting some user stories so if you have any, please do add them to the RemoteDevelopmentBoards[1] wiki page. Also, if you'd like to participate in the discussion at LDS, don't forget to subscribe to the blueprint[2] on Launchpad. Hi Guilherme. We currently have a Versatile Express and three PandaBoards in the London data centre: https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware There's also a bunch of hardware in my home office that is slowly being replaced by the data centre boxes. These are set up as porter boxes. Toolchain people are a bit unique as we're very much an end user: a board which is reliable and consistent is more important than the latest and greatest. They're used for building GCC (~5 hours), testing it (~7 hours), building packages, debugging, and all the usuals. One tricky thing is benchmarking. If you run a benchmark you want the same environment as last time and some type of exclusive access. The environment can change over time as these are generally development benchmarks so you can run a baseline first. -- Michael -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Would you like remotely accessible boards?
On Thu, May 5, 2011 at 8:55 AM, Guilherme Salgado guilherme.salg...@linaro.org wrote: On Thu, 2011-05-05 at 08:26 +1200, Michael Hope wrote: On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado guilherme.salg...@linaro.org wrote: Hi Michael, On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote: On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado guilherme.salg...@linaro.org wrote: If you do, I need to know more about how you'd like to use them, to make sure we provide something that is suitable to everyone. At this point I'm interested in drafting some user stories so if you have any, please do add them to the RemoteDevelopmentBoards[1] wiki page. Also, if you'd like to participate in the discussion at LDS, don't forget to subscribe to the blueprint[2] on Launchpad. Hi Guilherme. We currently have a Versatile Express and three PandaBoards in the London data centre: https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware There's also a bunch of hardware in my home office that is slowly being replaced by the data centre boxes. These are set up as porter boxes. Toolchain people are a bit unique as we're very much an end user: a board which is reliable and consistent is more important than the latest and greatest. They're used for building GCC (~5 hours), testing it (~7 hours), building packages, debugging, and all the usuals. One tricky thing is benchmarking. If you run a benchmark you want the same environment as last time and some type of exclusive access. The I've added a user story with this requirement. environment can change over time as these are generally development benchmarks so you can run a baseline first. Do you mean that when the environment changes you want to run the baseline benchmark against the old environment? There's two stories: * A developer benchmarking their latest changes. They can run a baseline, bring in the change, then run to show the improvement. The environment should stay the same over that week Ok, I understand it now, although I can't think of a way to write this nicely using the 'As role I want to perform task so that value it brings' format. Maybe As a Toolchain engineer, I want to have a system with a stable environment allocated to me for a week so that I can benchmark the toolchain with my changes against a baseline. ? * The continuous build recording benchmark results with every build. The environment should always stay the same so that the numbers can be compared How does As a Toolchain engineer, I want to continuously build the toolchain against a stable environment and record the benchmark results, so that they can be compared. Sound as a user story for the above, using our preferred format? Change 'stable' for 'consistent'. Sounds good. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
zlib NEON improvements
Jan Seiffert has been looking into vectorising the adler32 routine in zlib. On the A9 there's a 3.0 x improvement to be had on blocks that fit in the L1 cache and a 2.1 x improvement for larger blocks. See: http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-May/002556.html for the work in progress. -- Michael -- Forwarded message -- From: Michael Hope michael.h...@linaro.org Date: Mon, May 2, 2011 at 10:35 AM Subject: Re: [Zlib-devel] [3/8][RFC V3 Patch] Add special ARM Adler32 version To: zlib-de...@madler.net On Mon, May 2, 2011 at 9:48 AM, Jan Seiffert kaffeemons...@googlemail.com wrote: 2011/4/24 Jan Seiffert kaffeemons...@googlemail.com: This adds an NEON version, a iWMMXt version for Intel (now Marvel) StrongARM and a version for ARMv6 DSP instructions of Adler32. Thanks again to Edwin Török the NEON and ARMv6 DSP version are now tested and fixed. The good news is NEON: an i.MX515@800MHz (arm7l) with NEON orig -- a: 0x0CB4B676, 1 * 16 bytes t: 4010 ms a: 0x25BEB273, 1 * 15 bytes t: 2990 ms a: 0x733CB174, 1 * 159998 bytes t: 4060 ms a: 0x1144AF76, 1 * 159996 bytes t: 4050 ms a: 0x3F4ECB8A, 1 * 159992 bytes t: 4060 ms a: 0x1902A382, 1 * 159984 bytes t: 4060 ms vec -- a: 0x0CB4B676, 1 * 16 bytes t: 1450 ms a: 0x25BEB273, 1 * 15 bytes t: 1450 ms a: 0x733CB174, 1 * 159998 bytes t: 1460 ms a: 0x1144AF76, 1 * 159996 bytes t: 1450 ms a: 0x3F4ECB8A, 1 * 159992 bytes t: 1460 ms a: 0x1902A382, 1 * 159984 bytes t: 1450 ms speedup: 2.765517 Hi Jan. I see similar numbers. I wasn't sure what you were using to benchmark this so I wrote my own little stub that did the seed=0x0CB4B676 version over data from rand(). I ran each test five times and picked the lowest user time as the best. All were built with gcc-linaro-4.5-2011.04 with -mfpu=neon -mtune=cortex-a9. The results were: Cortex-A9 @ 1 GHz: Plain C: 4.094 s ARMv6: 4.578 s NEON: 1.985 s Cortex-A8 @ 720 MHz: Plain C: 4.164 s NEON: 1.819 s NEON: 1.570 s (with -mtune=cortex-a8) It's interesting how the slower A8 does better than the A9. It's probably due to the A8 having wider access to the L2 cache as running the same test but on 16 k of data so that it fits in the L1 cache gives: Cortex-A8: 5.234 s Cortex-A9: 3.969 s The ratio here is 0.760 which is very similar to the ratio between the clock frequencies. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: zlib NEON improvements
On Mon, May 2, 2011 at 11:13 AM, Jan Seiffert kaffeemons...@googlemail.com wrote: 2011/5/2 Michael Hope michael.h...@linaro.org: Hi Michael, Linaro Devs I see similar numbers. Great to hear ;) Means i'm not totally on the wrong track Note that I've sent the results to zlib-dev. The copy to linaro-dev was forwarded on rather than cross-posting. I wasn't sure what you were using to benchmark this A little program which contains the different code versions and a test loop. As it is written there: 1 * 16 bytes means 1 calls with a 16 bytes buffer. The different lines are from tests with buffer + offset, len - offset to test for different alignments The buffer is filled with 0xff (the worst input for adler32, because it may overflow the internal sums earlier then other input, so all internal looping must be for 0xff). The time is measured with times(). Oh, and if it's not clear, this is only the adler32 speedup, because only adler32 is run in a loop. Any idea on how much time in a zlib decompress is spent in adler32? so I wrote my own little stub that did the seed=0x0CB4B676 version over data from rand(). Yeah, that's also a valid test. Maybe you want to srand(0) or something to get a reliable result. Yip, I had srand(1234) so the results should be repeatable. It's interesting how the slower A8 does better than the A9. It's probably due to the A8 having wider access to the L2 cache as running the same test but on 16 k of data so that it fits in the L1 cache gives: Cortex-A8: 5.234 s Cortex-A9: 3.969 s The ratio here is 0.760 which is very similar to the ratio between the clock frequencies. Yepp, cache connection is important. Most Vector units are, at least for this task, very fast and only constrained by internal brain damage or cache/memory. Look at the Altivec numbers: http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-April/002544.html As long as it fits into the cache 6.6 speedup, after that 1.3 speedup. Makes sense. The A8 has a direct connection to the 256 k of L2 cache so the 160k x 10,000 test runs as fast as the 16 k x 100,000 test. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Help on general file sharing
On Fri, Apr 29, 2011 at 7:23 PM, Shawn Guo shawn@freescale.com wrote: I have one 35MB tarball to share with Linaro folks. It's too big to distribute through email. Is there any infrastructural solution for such general file sharing purpose? (The launchpad PPA is for package than general file sharing, and I do not want to bother.) Thanks. You can upload arbitrary files to Google Docs and share the link. Andrew and I use this to push release candidate files about before releasing them. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Toolchain performance 2011-04-26 minutes
Hi there. Minutes from this weeks toolchain performance call are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-26 These meetings discuss current and future work on improving the performance of GCC. Future minutes will be added to the toolchain meetings page at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings and announced on the linaro-toolch...@lists.linaro.org list. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFF] Patch tracking/metrics
On Sun, Apr 24, 2011 at 1:27 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: We're planning on bringing up Gerrit at UDS for tracking Android upstreaming. Perhaps it could be used for tracking GCC patches? Probably not. It seems to be tied to git and requires the Android workflow. Here's our workflow: Patches that are backported or unique to gcc-linaro are handled through the Launchpad merge request system. Patches on mainline are constrained by mainline's method which is: * Send the patch to gcc-patc...@gcc.gnu.org * Iterate on the mailing list, perhaps in new threads * Get approval via reply to the latest post * Commit into svn The final commit is automatically emailed to the gcc-...@gcc.gnu.org list. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcement: Linaro ARM Optimized Toolchain for Android platform
Hi Jim. Good effort. The Android patch set will be included in
gcc-linaro-4.5-2011.04 which is due out today.
We need to discuss toolchain build scripts at the summit. There's a
want for builds of pretty much every combination of
{Android,Linux,bare metal?} target, crossed with {Native,Cross}
builds, crossed with {Ubuntu,Generic Linux,Windows?} hosts. I'll talk
with Alexander and Steve and see about a session.
-- Michael
On Wed, Apr 20, 2011 at 8:13 PM, Jim Huang jim.hu...@linaro.org wrote:
Hello list,
Today we're announcing a new technical preview of ARM optimized
toolchain for Android platform by Linaro[1].
Linaro is a NFP (Not For Profit) organization that aims to make
embedded open source development easier and faster. Regardless of
Android release cycle from AOSP, Linaro would like to bring the latest
and ARM optimizing open source technologies to the common software
foundation for software stack, and Linaro toolchain[2] deals with all
aspects of system-level tools - the core development toolchain
(compiler, assembler, linker, debugger).
In this announcement, the technical preview of ARM optimized toolchain
for Android is available for evaluation: (source repository and binary
package)
https://wiki.linaro.org/Platform/Android/Toolchain
An early activity of the Android Platform Team has been to run the
Android benchmark suite to show the gains possible in going from the
default Google 4.4 based toolchain to the Linaro 4.5 toolchain. The
experimental benchmarks were run on a 600 MHz Cortex-A8 board running
Android 2.2: (unofficial, for reference only)
https://wiki.linaro.org/JimHuang/Sandbox/LinaroToolchainAndroidBenchmarking
Developers can utilize the optimization techniques from GNU Toolchain
and Linaro's ARM improvements through Linaro Toolchain for Android and
NDK. For example, skia benchmark[3] brings 11% performance
improvements after using Linaro Toolchain.
Linaro's Android platform team plans to deliver the final linaro-11.05
release, and you can check out the status of open development:
https://launchpad.net/linaro-android/
On-going Blueprints:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-toolchain-ndk
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-toolchain-integration
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-google-benchmark-suite
Sincerely,
Jim Huang,
Android platform team,
Linaro
[1] http://www.linaro.org/
[2] https://wiki.linaro.org/WorkingGroups/ToolChain
[3] Linaro uses the same toolchain benchmark as Google compiler team
does: https://wiki.linaro.org/Platform/Android/UpstreamToolchain
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Working around a Tegra 2 errata for Natty
Hi there. There's a problem with the thread local storage register in the Tegra 2 which is exposed by Ubuntu switching to GCC 4.5. The fault is quite serious and causes many applications to segfault. There's more details in LP: #739374. The problem is Tegra 2 specific and is caused by bit 20 of the CP15 thread pointer register always reading as zero. With GCC 4.4, access to the thread pointer always goes through the GLIBC helper function '__aeabi_read_tp' which calls into the kernel which then reads and returns CP15. Either GLIBC or the kernel[1] itself swaps bit 20 and bit 0 which works around the problem. This doesn't work in GCC 4.5 as it reads CP15 directly instead. There are a few solutions: Change GCC to swap bits 20 and 0 as well. This is a hack and requires rebuilding the archive. The performance should be small. Change GCC to always call the helper function. The helper function can detect the processor and call into the kernel on Tegra devices, or return CP15 directly on others. IFUNC could be used to reduce the overhead. The archive would have to be rebuilt. Worse performance than above, but still better than 4.4. Change GLIBC to allocate thread local storage on a 2 M boundary. Bit 20 would always be zero. The thread pointer is a base address so the thread could still have more than 2 M of thread local data. GLIBC would have to be rebuilt and this limits the maximum number of threads. No runtime performance hit. I prefer changing GLIBC. Any thoughts? Linaro doesn't support this chip. Who should do the work? Linaro? Ubuntu? The EGLIBC community? -- Michael [1] Dave and I disagree where it is but neither have tracked it down ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Likely empty space in a processes's virtual address space
Hi there. The address space randomisation feature in 2.6.35 and above kernels breaks GCC's precompiled headers support. GCC works by compiling the header once, dumping the internal format out to disk, and then mmap()ing it back in at a fixed address. The solution for other architectures is for GCC to pick a spot in the virtual address space that is likely to be free and map the PCH in there. Most of them use 0x6000 which from a bit of poking seems to be fine on ARM as well. Can someone point me at the typical virtual address space for a ARM Linux process? How does 0x6000 sound? For reference, this is the code in kernel/arch/arm/mm/mmap.c that exposes the problem: /* 8 bits of randomness in 20 address space bits */ if (current-flags PF_RANDOMIZE) addr += (get_random_int() % (1 8)) PAGE_SHIFT; The GCC code with addresses for other architectures lives at: http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5/view/head:/gcc/config/host-linux.c#L67 /proc/self/maps on a simple program gives: 8000-9000 r-xp 00:14 28747240 /home/michaelh/a.out 0001-00011000 r--p 00:14 28747240 /home/michaelh/a.out 00011000-00012000 rw-p 1000 00:14 28747240 /home/michaelh/a.out 00012000-00033000 rw-p 00:00 0 [heap] 2ab4c000-2ab4d000 rw-p 00:00 0 2ab5c000-2ab5e000 rw-p 00:00 0 2ab89000-2aba r-xp 00:0d 26352847 /lib/ld-2.12.1.so 2aba8000-2aba9000 r--p 00017000 00:0d 26352847 /lib/ld-2.12.1.so 2aba9000-2abaa000 rw-p 00018000 00:0d 26352847 /lib/ld-2.12.1.so 2ac35000-2ac36000 rw-p 00:00 0 2ac93000-2aca r-xp 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca-2aca7000 ---p d000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca7000-2aca8000 r--p c000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca8000-2aca9000 rw-p d000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca9000-2ad96000 r-xp 00:0d 26352832 /lib/libc-2.12.1.so 2ad96000-2ad9e000 ---p 000ed000 00:0d 26352832 /lib/libc-2.12.1.so 2ad9e000-2ada r--p 000ed000 00:0d 26352832 /lib/libc-2.12.1.so 2ada-2ada1000 rw-p 000ef000 00:0d 26352832 /lib/libc-2.12.1.so 2ada1000-2ada4000 rw-p 00:00 0 7ed9c000-7edbd000 rw-p 00:00 0 [stack] 0x6000 is well above the shared libraries and well below the stack. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFF] Patch tracking/metrics
On Sat, Apr 9, 2011 at 2:14 AM, James Westby james.wes...@linaro.org wrote: Hi, This service is going to be used by management to get an idea of the number of patches going to each project over time, the number of patches submitted upstream by each team over time, the % of patches accepted upstream, the average time from submission to acceptance for each project, and other things like that. For this to work well, and for your work to be accurately counted, you are going to be expected to keep it up to date as you submit patches upstream. Now is the time to speak up if the interface doesn't have what you need to do this. Obviously it would be better if it took care of everything for you, but we don't think that everything can be automated. If you know better then we would obviously like to hear about that too. Hmm. We already do patch tracking in Linaro GCC to make sure that all patches go upstream. It's a manual process as the GCC workflow itself is very manual. I don't want to manually update two places when a patch changes state. How can we merge these systems? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Libraries with NEON backends
On Sun, Apr 10, 2011 at 5:47 AM, Jim Huang jim.hu...@linaro.org wrote: On 31 March 2011 08:23, Michael Hope michael.h...@linaro.org wrote: Thanks all for your replies. I mixed these in with a bit of Googling and recorded them here: https://wiki.linaro.org/MichaelHope/Sandbox/LibrariesWithNeon hi Michael, Jan Seiffert implemented a series of adler32 vectorization for zlib: http://blackfin.uclinux.org/git/?p=users/vapier/zlib.git;a=summary ARM NEON and ARMv6 SIMD are included. It looks great and is being reviewed in zlib mailing-list: http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-April/date.html Hi jserv. I had a quick play with this on one of my machines. It looks promising but is a bit broken at the moment: michaelh@ursa1:/scratch/michaelh/zlib$ gdb ./example ... Starting program: /scratch/michaelh/zlib/example zlib version 1.2.5 = 0x1250, compile flags = 0x155 uncompress(): hello, hello! gzread(): hello, hello! gzgets() after gzseek: hello! inflate(): hello, hello! Program received signal SIGSEGV, Segmentation fault. 0x00015c48 in adler32_vec (adler=2363950230, buf=0x7b000 Address 0x7b000 out of bounds, len=0) at adler32_arm.c:162 162 in16 = *(const uint8x16_t *)buf; (gdb) back #0 0x00015c48 in adler32_vec (adler=2363950230, buf=0x7b000 Address 0x7b000 out of bounds, len=0) at adler32_arm.c:162 #1 0x00016446 in adler32 (adler=2363950230, buf=0x26008 x\001\354\320\261\r, len=2) at adler32.c:418 #2 0xb81c in read_buf (strm=0x7ebf3634, buf=0x44ba8 , size=25536) at deflate.c:1005 #3 0xbe7a in fill_window (s=0x39898) at deflate.c:1380 #4 0xc06c in deflate_stored (s=0x39898, flush=0) at deflate.c:1484 #5 0xb252 in deflate (strm=0x7ebf3634, flush=0) at deflate.c:822 #6 0x922e in test_large_deflate (compr=0x26008 x\001\354\320\261\r, comprLen=4, uncompr=0x2fc50 hello, hello!, uncomprLen=4) at example.c:281 #7 0x9ca6 in main (argc=1, argv=0x7ebf37f4) at example.c:551 Richard, the implementation uses NEON intrinsics so it'd be interesting to see if your pack/unpack patches apply to it. I'll mention this on the zlib-devel list. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Libraries with NEON backends
Thanks all for your replies. I mixed these in with a bit of Googling and recorded them here: https://wiki.linaro.org/MichaelHope/Sandbox/LibrariesWithNeon -- Michael On Mon, Mar 28, 2011 at 5:52 PM, Jim Huang jim.hu...@linaro.org wrote: On 28 March 2011 05:09, Michael Hope michael.h...@linaro.org wrote: Hi there. I'm looking for areas where the toolchain could generate faster code, and a good way of doing that is seeing how compiled code does against the best hand-written code. I know of skia, ffmpeg, pixman, Orc, and efl - what others are out there? hi Michael, Great motivation to optimize the existing libraries by NEON ! As far as I know, Android depends on several libraries, and some of them are computing bound: - libpixelflinger -- a bit like pixman There is no official document about PixelFlinger, but you can always check out its source: http://android.git.kernel.org/?p=platform/system/core.git;a=summary I submitted one NEON optimization patch for libpixelflinger to AOSP before: https://review.source.android.com//#change,16358 - zlib Using SIMD, we can optimize 'copy / repeat an existing sequence' in LZ-style encoding. The reference Intel SSE2 optimization patch is attached in this mail. Sincerely, -jserv ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Libraries with NEON backends
Hi there. I'm looking for areas where the toolchain could generate faster code, and a good way of doing that is seeing how compiled code does against the best hand-written code. I know of skia, ffmpeg, pixman, Orc, and efl - what others are out there? Thanks for any input, -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Starting a cookbook
Hi there. I'd like to start an official Linaro cookbook that has recipes on how to build and use the various Linaro outputs. This cookbook would answer questions such as 'how do I build Linaro GCC from source?' and could be expanded into others. I'm thinking of having a concise Makefile for each of the interesting uses. The Makefiles would be executable documentation - something that you can read and understand the steps, and also run to get a valid output. They should be correct but very focused so, for example, a broken download would be detected but make force a 'make clean' instead of adding another line to the script. I currently have a single stage cross GCC against the Linaro sysroot, a bare metal cross GCC (unsupported), and a fancy cross GCC that works against the Debian/Ubuntu ARM, PowerPC, and MIPS sysroots. This would be an official Linaro product and would be updated with each monthly release. Thoughts? What scripts do people have tucked away that I could tidy up and publish? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Starting a cookbook
On Mon, Mar 28, 2011 at 12:29 PM, Loïc Minier loic.min...@linaro.org wrote: On Mon, Mar 28, 2011, Michael Hope wrote: Hi there. I'd like to start an official Linaro cookbook that has recipes on how to build and use the various Linaro outputs. This cookbook would answer questions such as 'how do I build Linaro GCC from source?' and could be expanded into others. Is that a Linaro Toolchain cookbook? Could be, but it doesn't have to be if there are other things that are complicated to build and use. Othewise, it sounds much like the HowTo tab on wiki.linaro.org: https://wiki.linaro.org/Resources/HowTo https://wiki.linaro.org/CategoryHowTo In any I feel your efforts could definitely be part of the HowTos :-) Yip, but I'd like something that someone can read and run; and that we can update and make releases of. The wiki does make things easy to find - perhaps these should also be mirrored up to the wiki for reference? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Tue, Mar 15, 2011 at 11:53 PM, Andrew Stubbs andrew.stu...@linaro.org wrote: Richard may know all this, but I'm just going to post anyway in case some people reading can benefit from some tips. I find that bzr is slow - there's no getting around it, but there are some tricks that can help. On 14/03/11 11:12, Richard Sandiford wrote: My concern was that, again with my way of working, the process is: 1) develop fix 2) branch trunk (creating a whole new gcc source tree, so quite slow) This is going to take a short while however you cut it, but doing it the naive way is *very* slow. So, make sure you use init-repo. This creates a top-level .bzr directory that can be shared between many branches. This cuts down on network usage, and speeds up local branching also. To set it up: mkdir my_work_dir cd my_work_dir bzr init-repo . bzr branch lp:gcc-linaro my_1st_branch bzr branch lp:gcc-linaro my_2nd_branch Basically, any branches you create within sub-directories of my_work_dir have shared history, so there's no need to waste time duplicating it. I believe hard-linking should be a win too, but I don't use it much: bzr branch --hardlink my_1st_branch my_2nd_branch You might also try experimenting with local stacked branches (so the new one has only shallow history), but I'm not sure there's any advantage if you use a shared repo: bzr branch --stacked my_1st_branch my_2nd_branch 3) apply fix to new branch, with ChangeLog entry 4) publish new branch in laucnhpad I find bzr push is quite fast, but there's a special gotcha - it always stacks new feature branches on top of the gcc-linaro/4.5 branch (more accurately, the focus of development branch), and if you're working with 4.4 or 4.6, that means there quite a lot of difference to upload. You can fix this by telling it what branch to stack on: bzr push --stacked-on=bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6 lp:~user/gcc-linaro/newbranch Unfortunately, the lp:... form doesn't work with --stacked-on. :( 5) wait for branch to be processed by launchpad (only a few minutes, nothing major) 6) ask for a review 7) merge to trunk (with the inevitable ChangeLog merge failure that you mentioned). whereas the upstream way would be: 1) develop fix 2) ask for a review, attaching patch 3) apply patch to trunk, with ChangeLog entry The upstream way feels much simpler, and avoids the merge failure hassle. True. If you prefer, by all means include the ChangeLog entry in the merge request, and it can be inserted into ChangeLog.linaro at merge time. It makes no real difference to me, but it does mean that if there is anybody out there pulling toolchains from feature branches, the ChangeLogs won't be helpful. I doubt that anybody does that??? Short story is that we have a better tool than svn, so feature branches may make some use cases overall easier and more transparent. Well, as you say, the size of GCC and its history is pushing the limits of bzr a bit. For bug-fixing and committing, I actually find quilt+svn to be a fair bit more productive than bzr, and that's even with Andrew doing the heavy work on merging. I'd say that calling bzr a better tool than svn is pushing it a bit. It has some nice features, and it works better than svn for launchpad's purposes, but I'd still rather use SVN or, better still, git. If bzr wasn't such a dog to use (for large projects), it would be as good as SVN or GIT, but it would not be better - just different. (Svn was lacking a good merge tool, but I believe that's fixed now?) I prefer bzr over svn for this project for reasons that are better discussed over a beer... I've updated the BzrTips page on the wiki: https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips with links out to Andrew's, Loic's, and Martin's emails. If these tips work for you, please edit the wiki. I've also updated the BzrIssues page at: https://wiki.linaro.org/MichaelHope/Sandbox/BzrIssues with the performance numbers from earlier in the thread. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Tue, Mar 15, 2011 at 12:12 AM, Richard Sandiford richard.sandif...@linaro.org wrote: Short story is that we have a better tool than svn, so feature branches may make some use cases overall easier and more transparent. Well, as you say, the size of GCC and its history is pushing the limits of bzr a bit. For bug-fixing and committing, I actually find quilt+svn to be a fair bit more productive than bzr, and that's even with Andrew doing the heavy work on merging. I did some quick benchmarks. No comment either way: bzr pull - took 4:06 to pull down and merge a few changes bzr branch 4.5 lp-foo - took 4:35 bzr commit - took 3:08 for a one line change bzr send (puts the delta in a mail message) - took 10:20 bzr merge - took 3:08 for the one-line change into trunk bzr diff is very fast. The branch for the one-line commit was 23 MB on disk. A standard work flow of pull / do work / commit /push would be ~7 minutes. A pull / branch / do work / commit / push / merge / commit / push would be ~18 minutes assuming push is free. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Instructions for building Linaro GCC with crosstool-NG
Ta. I've added links to this and others to: https://wiki.linaro.org/WorkingGroups/ToolChain/Using -- Michael On Mon, Mar 14, 2011 at 6:56 AM, Robert Schwebel r.schwe...@pengutronix.de wrote: On Thu, Mar 10, 2011 at 02:28:15PM +1300, Michael Hope wrote: I've written some short instructions on using crosstool-NG to build Linaro GCC: https://wiki.linaro.org/WorkingGroups/ToolChain/Using/CrosstoolNg Could someone review these for me please? Linaro GCC is already available in a bunch of places including OpenBricks, crosstool-NG, OpenEmbedded, OpenWRT, and (of course) Ubuntu. I hope to write a short page on each so people know where to find our toolchain in the distribution of their choice. OSELAS.Toolchain 2011.02.0 and above has support for linaro gcc as well: http://www.pengutronix.de/oselas/toolchain/download/ rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Better reviews for the same cost in gcc-linaro
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it. If you have experience in running a master branch or ideas on continious integration please have a read. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Thu, Mar 10, 2011 at 10:28 AM, James Westby james.wes...@canonical.com wrote: On Thu, 10 Mar 2011 09:56:27 +1300, Michael Hope michael.h...@linaro.org wrote: We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts Hi Michael, One thing that isn't clear to me from that page is why patches can go unreviewed for days. Do you tie the review to the testing somehow? It's the way things are. Andrew has been doing all of the review and doing it as part of the integration phase. This will change. The proposal to have a designated person who will review patches promptly is one that has seen success in other projects. It trades off prompt reviews for more interuptions in someone's time, but it seems like that is often worth doing. Some further questions: * How frequently do problems get through review that are found by the test suite? Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things. * How frequently do problems get past the testsuite? Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite. * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk? Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Thu, Mar 10, 2011 at 11:36 AM, James Westby james.wes...@canonical.com wrote: On Thu, 10 Mar 2011 11:09:21 +1300, Michael Hope michael.h...@linaro.org wrote: * How frequently do problems get through review that are found by the test suite? Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things. Sure, but reviews shouldn't be trying to catch every single problem that may exist. If you don't have an idea of how much benefit test-before-merge has over just review-before-merge then it's going to be hard to estimate the risk of changing that scheme. We currently have review+build+test before merge. If we checkin directly to trunk then it would be review+merge, then build+test automatically afterwards. * How frequently do problems get past the testsuite? Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite. That indicates that getting the code out there for (non-production) use would actually be worthwhile, rather than trying too hard to ensure everything goes through the testsuite. (Unless every patch has 10 problems that are not found in review but found by the testsuite.) Yip. It's quite stable and bugs are quite rare. A huge testsuite like Ubuntu is a good way of exercising the compiler. * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk? Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk. What sense are you using break here? On second reading, too loosely. I meant 'fail to build', but most developers will want to run the testsuite. If the checkin before them caused a testsuite regression then they may get confused. A timely automatic build would help with that: perhaps notify the previous author of the regression, and give the developer somewhere to easily check the state of their baseline. It sounds like prompt review-integration branch-beta testers | `-test suite-trunk would be best if you don't think that you can have a quality release if you merge-before-test. Yip. The integration branch however may be Ubuntu itself. Matthias is fairly happy cherry-picking things so if these checkins/feature branches are at least reviewed and preferably build+tested then he can be the path to beta testers. This may change when Linaro gets set up to build main. If you feel that you are equipped to recover from problems found by running the test suite against trunk before doing a release then it may be better to avoid the overhead and merge to trunk after prompt review, and deal with test failures when they happen. Agreed. The build+testsuite can happen automatically and probably within two days. -- Michae ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Instructions for building Linaro GCC with crosstool-NG
I've written some short instructions on using crosstool-NG to build Linaro GCC: https://wiki.linaro.org/WorkingGroups/ToolChain/Using/CrosstoolNg Could someone review these for me please? Linaro GCC is already available in a bunch of places including OpenBricks, crosstool-NG, OpenEmbedded, OpenWRT, and (of course) Ubuntu. I hope to write a short page on each so people know where to find our toolchain in the distribution of their choice. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: A good skia [was: Re: [RFC] Linaro Toolchain for Android and NDK]
On Tue, Mar 8, 2011 at 7:37 AM, Jim Huang jim.hu...@linaro.org wrote: From the above messages, Google introduced the automated approach to deploy benchmark suite and evaluate it on the fly. Hi jserv. That's quite cool. I'll have a look into their benchmark suite as there seems to be a lot of overlap with what I'm doing. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Fw: [PATCH][RFC] CC_OPTIMIZE_FOR_SIZE should default to N
On Tue, Mar 8, 2011 at 8:47 AM, Tom Gall tom.g...@linaro.org wrote: To quote the GCC manual: -Os Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version That said (and unless there's other undocumented differences), it would seem to take some expertise to comment on the trade off between memory efforts (cache misses, TLB etc) vs instructional effects by having these optimizations off. I am certainly not that expert but I suspect given the memory bus speeds that typical arm hardware has, we'd want -Os over -O2. I don't know about the kernel, but here's the difference for some other programs: * pybench: -Os is 24 % slower than -O2 * skia: -Os is 18 % slower than -O2 * CoreMark is similar (I've lost the numbers) ...so you're going to need a large bandwidth saving to beat the core speed improvement of -O2. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Minutes Actions: Toolchain Working Group meeting of Feb 28 Mar 02, 2011
On Fri, Mar 4, 2011 at 9:29 AM, Vandervennet Yves-R55763 r55...@freescale.com wrote: Hi TC working group, May I ask what the following means? “724987: discourage use of NEON on the A8” Hi Yves. This is an optimisation that discourages GCC from using certain NEON instructions that are expensive on the A8 and better done through core registers. It doesn't discourage NEON in general, nor does it mean we have a policy of discouraging NEON on that core. Hope that answers your question, -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Monthly component release candidate dates
On Wed, Mar 2, 2011 at 9:48 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 2 March 2011 01:33, Michael Hope michael.h...@linaro.org wrote: On Wed, Mar 2, 2011 at 10:04 AM, Peter Maydell peter.mayd...@linaro.org wrote: https://wiki.linaro.org/Releases/MonthlyMilestones That would be an annoying format change for toolchain group releases, which are already on a monthly schedule and currently use 2011.03 for milestone names, and 2011.03-0 (-1, -2 ...) for release versions. Hi Peter. We'll keep the 2011.xx-y names for the products. Each project has product series and a planning series. The product series are ones like '4.5' or '4.4' for gcc-linaro, and 'trunk' for qemu-linaro, and these then have milestones like '2011.03'. Is this a proposal to vary the proposed new milestone names, or a suggestion that the toolchain group should continue as it is and not worry about the inconsistency with other groups? There's no change from our product series/milestone naming point of view. The dates will change to the end of the month to sync up across Linaro. There will be a parallel and, unfortunately, largely identical planning series with milestones as well. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Monthly component release candidate dates
On Wed, Mar 2, 2011 at 10:04 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 1 March 2011 20:45, Jamie Bennett jamie.benn...@linaro.org wrote: On 01/03/11 at 01:25pm, Tom Gall wrote: On Tue, Mar 1, 2011 at 9:49 AM, Jamie Bennett jamie.benn...@linaro.org wrote: https://wiki.linaro.org/Releases/MonthlyMilestones If agreed I would propose that all projects use the milestone names and dates in the above link in their launchpad projects. Blueprints and work items can then target these milestones That would be an annoying format change for toolchain group releases, which are already on a monthly schedule and currently use 2011.03 for milestone names, and 2011.03-0 (-1, -2 ...) for release versions. Is anybody actually currently using the milestone names in the wiki page above? If not, wouldn't it make more sense to standardise on the format we're already using? (Plus, two digit years? Very retro...) Hi Peter. We'll keep the 2011.xx-y names for the products. Each project has product series and a planning series. The product series are ones like '4.5' or '4.4' for gcc-linaro, and 'trunk' for qemu-linaro, and these then have milestones like '2011.03'. The planning series are named after the planning cycle such as '11.05' and have milestones like '11.05-final', '11.05-alpha2', and so on. The planning series names and dates are consistent across all of Linaro and let the PM people collapse the data into a whole of Linaro view. Every blueprint we plan to complete this cycle should be accepted for the 11.05 series and at least targeted at the 11.05-final milestone. There is a wart though - say we plan to finish blueprint 'x' by the March release. Do we assign it to the product 2011.03 milestone or the otherwise identical planning 11.05-foo milestone? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
