From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25888 invoked by alias); 26 Jan 2012 13:36:58 -0000 Received: (qmail 25701 invoked by uid 22791); 26 Jan 2012 13:36:57 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jan 2012 13:36:31 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id EF2C72F78005; Thu, 26 Jan 2012 13:36:29 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJooJqelUqi8; Thu, 26 Jan 2012 13:36:28 +0000 (GMT) Message-ID: <4F2156B0.7080705@ecoscentric.com> Date: Thu, 26 Jan 2012 13:36:00 -0000 From: Alex Schuilenburg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ilija Kocho CC: eCos developers Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> <4F11AC54.7000902@siva.com.mk> <4F1CB41C.90900@jifvik.org> <4F1DA9A0.5070702@siva.com.mk> <4F1FF5AD.4010901@ecoscentric.com> <4F206D2E.7040608@siva.com.mk> In-Reply-To: <4F206D2E.7040608@siva.com.mk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00046.txt.bz2 Hi Ilija On 2012-01-25 20:59, Ilija Kocho wrote: > Hi Alex > > I wish to thank eCosCentric for supporting eCos GCC 4.6 release. It > will both assure quality of this release and strengthen the image of > eCos community toolchain. NP - it is a community effort after all :-) > In order to best utilize 2 lab. weeks of testing we should have well > prepared binaries. In my view, it would be the best to carry out the > eCosCentric lab. test as final release verification step after some > field testing. In a course of field testing we shall also prepare eCos > itself, (eliminate warnings, etc.). We have the opposite view - our test farm finds errors which normal user and field testing does not catch. I think the earlier you get the toolchain into the test farm the better because you will at least minimise the user and field regression testing needed when you fix issues thrown up by the farm. We are happy to throw as many toolchain candidates as needed into the test farm, with the only restriction being the bandwidth each board runs the tests, so don't feel you have to hold back and use the farm for final verification. Our test farm has thrown up far more eCos bugs and toolchain issues than the rest of the community has to date. > > Regarding targets, I don't have objections. However you may find > interesting Freescale K70 (Cortex-M4F) > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-K70F120M&parentCode=K70&fpsp=1 > > mainly because of single precision FPU support. Btw hard-float library > support for Cortex-M4F will be new feature in this GCC release. > I must admit that we don't have BSP yet as this is brand new chip but > am working on it and expect to have it in short time. That is interesting. However the two boards I suggested are ones we physically have so can build and run tests for and are conveniently currently located in our test farm. We don't have a Freescale K70. The publicly available boards we do have can be found at http://www.ecoscentric.com/ecos/ecospro_tab.shtml, although not all may be available in our test farm. Is there board in this list you may think may be better for testing for which a public eCos BSP exists? Cheers -- Alex Schuilenburg Managing Director/CEO eCosCentric Limited www.ecoscentric.com Reg in England and Wales, Reg No 4422071