Does anyone have any input on the requirements of the ARM cross tool chain going into ubuntu? Could you please add your comments to this thread on the linaro list.
Forwarded conversation Subject: Restricting architectures ------------------------ From: Michael Hope <[email protected]> Date: Tue, Aug 31, 2010 at 6:03 PM To: Linaro Dev <[email protected]> Cc: David Rusling <[email protected]> Hi there. We've been having a discussion in the Toolchain WG regarding Thumb-1 improvements. I want to decline doing them as I've assumed that Linaro is focused on the Cortex-A series, but I can't find that written down anywhere. May I limit the Toolchain WG to currently or nearly shipping Cortex-A implementations? This means: * Cortex-A profile only * ARMv7 only * ARM and Thumb-2 instruction sets * With or without NEON * With either VFPv3 D16 or D32 * With or without SMP We will try to do no harm to other architectures or earlier ARM versions. The Thumb-2 routines may be applicable to the Cortex-M and Cortex-R series but we will not optimise for them. I'd like Linaro to state this explicitly in the next round. https://wiki.linaro.org/Linaro1011/TechnicalRequirements defines a 'Standard ARMv7 Configuration' but there's no higher level statement justifying it, no statement restricting us to it, and it includes ARM, Thumb-2, and Thumb-1. -- Michael _______________________________________________ linaro-dev mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-dev ---------- From: Linaro <[email protected]> Date: Tue, Aug 31, 2010 at 6:07 PM To: Michael Hope <[email protected]> Cc: Linaro Dev <[email protected]> It is, see the original requirements. You have it correct, ARMv7A + vfp + neon... Dave Sent from my iPhone ---------- From: Arnd Bergmann <[email protected]> Date: Thu, Sep 2, 2010 at 11:56 AM To: [email protected] Cc: David Rusling <[email protected]> I think there are two aspects to this: On the one hand, we need to improve the code formost for new CPUs looking forward, so the latest generation of shiny high-end hardware is what matters the most and needs to be the primary target. Today's high end is tomorrow's mainstream, so sooner or later everyone will benefit from this. On the other hand, I think we need to be relevant and provide code that everyone can use. The market today mainly consists of stuff that's not the primary focus, like ARM926 or some non-MMU cores. Refusing to do a simple fix because it's not relevant for Cortex-A8/A9 will just manage to piss off people [1]. Obviously there has to be a middle ground. We're building the binary packages for the configuration Dave mentioned (v7A/Neon), but IMHO that shouldn't prevent anyone from rebuilding it with our tool chain without having to make significant changes. If there are patches readily available for stuff that's not our primary focus (thumb1, non-cortex v7A CPUs, vfp without neon, ...), I'd say we should still keep them or get them upstream. Arnd [1] http://www.joe-ks.com/archives_oct2006/ItsNotMyJob.htm ---------- From: Jon Smirl <[email protected]> Date: Thu, Sep 2, 2010 at 1:17 PM To: Arnd Bergmann <[email protected]> Cc: [email protected], David Rusling <[email protected]> As an embedded developer I'd like to see a standardized tool chain for building on most ARM architectures. There are at least two groups of users for this tool chain - ARM based PCs and embedded systems. There are dozens are various tool chain build systems for ARM. Every time I get a new embedded dev board I have to build yet another ARM tool chain to match what the accompanying software expects. This is a significant hurdle to new developers who may not have fast machines. Some of the people I've worked with needed 24hrs to build a tool chain. Let's get a standardized tool chain for the older ARM chips into a distribution to stop this needless proliferation. -- Jon Smirl [email protected] ---------- From: Linaro <[email protected]> Date: Thu, Sep 2, 2010 at 1:40 PM To: Jon Smirl <[email protected]> Cc: Arnd Bergmann <[email protected]>, "[email protected]" <[email protected]> Agree, whilst v7A is our priority, we need to 'do the right thing' for everyone ---------- From: Loïc Minier <[email protected]> Date: Thu, Sep 2, 2010 at 2:32 PM To: Jon Smirl <[email protected]> Cc: Arnd Bergmann <[email protected]>, David Rusling <[email protected]>, [email protected] I'd like to understand your use cases to make sure we're on track to cover them. First, we're trying to maintain a toolchain source tree which is adequately patched; that's mostly launchpad.net/gcc-linaro right now. Second, we're integrating that into the native Ubuntu toolchain. Third, we're providing a cross-toolchain to install in Ubuntu environments. The latter two are built from the same source, which includes the gcc-linaro tree. Is this what you're looking for, or do you need more? What were the specific cases which you experienced which required different toolchain? Things I can think of, but I don't know how important they are: - being able to easily change the default toolchain build flags (how do you get the toolchain? which flags do you use?) - being able to easily drop patches into the toolchain (how do you get the toolchain? which kind of patches?) - being able to roll your own toolchain packages from another toolchain tree - providing RPM packages for native and cross toolchains - providing tarball "packages" with "standalone" linux binaries, similar to CS toolchain downloads I think we have partial answers for some of the above things, but many we dismissed. Would love to hear which one you think are important for your specific use case (tell us what you do!) -- Loďc Minier -- Jon Smirl [email protected] -- ptxdist mailing list [email protected]
