Re: [Linaro-validation] Toolchain builds in LAVA

On 28/03/12 16:20, Paul Larson wrote: On Wed, Mar 28, 2012 at 10:03 AM, Andrew Stubbs mailto:andrew.stu...@linaro.org>> wrote: 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.

Re: Toolchain builds in LAVA

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.

Re: Plan for changing the binary toolchain to 4.7 and hardfloat

On 19/03/12 08:48, Konstantinos Margaritis wrote: On Sun, 18 Mar 2012 23:27:17 + Mans Rullgard 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

Re: gcc: Thumb interworking and weakly linked functions

On Tue 21 Feb 2012 09:57:12 GMT, Dave Martin wrote: struct pad_conf_entry { u16 offset; u16 val; } __attribute__ ((packed)); The "packed" attribute specifies that all struct elements ought to be considered to have alignment requirement 1 instead of their default alignment.

Re: Announcing the new Linaro *Community* Contributor process and team

On Thu 08 Dec 2011 14:59:02 GMT, Amber Graner wrote: The benefits of becoming a Community Contributor will include: * a Linaro e-mail address * the right to carry Linaro business cards (we supply the artwork, youprint your own cards) * a Linaro IRC cloak * listing in the relevant Working Group o

Re: ARM CPU part numbers

On 01/09/11 10:40, Andrew Stubbs wrote: I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo. Thanks to everybody who a

ARM CPU part numbers

Hi all, I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo. The problem is finding what magic numbers correspond to what CPU. I'v

Re: Better reviews for the same cost in gcc-linaro

On 17/05/11 17:01, Martin Pool wrote: I wanted to share with you some numbers on our changes in bzr 2.4 (final in August), based on the much-appreciated feedback from Linaro.The details are in but the short story is that l

Re: Better reviews for the same cost in gcc-linaro

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

Re: [RFC] Linaro Toolchain for Android and NDK

On 01/03/11 07:00, Jim Huang wrote: I think thats fine. however, how do we ensure that we have patches > that always apply to both release/snapshots? do we maintain branches > for gcc-patches.git in case you need two versions of patch X if the > linaro gcc codebase diverged? I might need help

Re: Building Linaro-netbook filesystem from sources

1. Right now I do not have access to board. I think probably I can use QEMU for simulating my hardware. Yes, I expect so, but it won't be fast! Does the kernel not have a VFP emulation mode that might make the existing binaries work on your netbook, at least well enough for bootstrapping purp

Re: Building Linaro-netbook filesystem from sources

On 17/12/10 08:01, Amit Mahajan wrote: I want to build linaro-netboook filesystem from *sources*, as I need a filesystem build without VFP support. I checked the wiki and other links but could not find a related document. Can anyone please point me to directions on how to do the same? I don't

Re: the linaro toolchain and older arm versions

On 07/10/10 12:54, a...@arndb.de wrote: On Thursday 07 October 2010 13:03:14 Wookey wrote: gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than t

Re: the linaro toolchain and older arm versions

On 07/10/10 12:03, Wookey wrote: gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than that. (i.e if you ask for v5, v6, v7, vfp, and neon options

Re: New projects and copyright

FAOD, the patch I sent you for that project is copyright Linaro, as per the CodeSourcery contract (it's a non-FSF project, of course). Andrew On 05/09/10 22:41, Michael Hope wrote: > I don't understand the page at: > https://wiki.linaro.org/Copyright > > I've put the new Toolchain WG web tools

Re: Patch tracking

On 13/08/10 12:35, Amit Kucheria wrote: > patchwork[1][2][3] can already monitor mailing lists for patches and > is used by several projects (Linux kernel, various sub-system > maintainers, etc.) to make sure that patches posted to the mailing > list are not dropped. (cc'ed Jeremy, author of patch

Re: Patch tracking

On 13/08/10 12:06, Loïc Minier wrote: > Before we dive into implementation questions such as Launchpad tags, or > tickets, or new software to be developed, I think it's important to > understand the fundamental goals of the tracker and the data it would > be working on. We're way past that

Re: Patch tracking

On 13/08/10 10:44, Loïc Minier wrote: > I think it's relevant to consider two things around this tracking: > - we're tracking a feature or a bug fix There's no automatic way to determine this, but it could be tracked using launchpad tags. Updating the tags might be tedious though. > - we w

Re: Patch tracking

On 13/08/10 10:08, Amit Kucheria wrote: > On 10 Aug 13, Michael Hope wrote: >> On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria >> wrote: >>> So git-based workflows won't benefit from this then? >> >> There's no particular dependence on any VC system. I will be making a >> report on each bzr commi

Re: Capturing usage information

On 10/08/10 03:47, Michael Hope wrote: > I'd like to record the running of a typical program such as Firefox, > GCC, or ffmpeg and capture the calls and arguments to functions like > strcpy() and memcpy(). The idea is to generate a usage profile so we > can tell what standard library functions and