From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26854 invoked by alias); 30 Jul 2012 10:09:19 -0000 Received: (qmail 26837 invoked by uid 22791); 30 Jul 2012 10:09:16 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,MALFORMED_FREEMAIL,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RCVD_IN_SORBS_WEB X-Spam-Check-By: sourceware.org Received: from mail-lpp01m010-f49.google.com (HELO mail-lpp01m010-f49.google.com) (209.85.215.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jul 2012 10:08:48 +0000 Received: by laap9 with SMTP id p9so3251727laa.36 for ; Mon, 30 Jul 2012 03:08:47 -0700 (PDT) Received: by 10.112.11.100 with SMTP id p4mr5068953lbb.35.1343642927018; Mon, 30 Jul 2012 03:08:47 -0700 (PDT) Received: from sg-laptop ([178.123.5.116]) by mx.google.com with ESMTPS id lv13sm10190433lab.8.2012.07.30.03.08.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 03:08:46 -0700 (PDT) Date: Mon, 30 Jul 2012 10:09:00 -0000 From: Sergei Gavrikov To: Ilija Kocho cc: Alex Schuilenburg , John Dallaway , Jonathan Larmour , eCos Discussion In-Reply-To: <50165611.8000202@siva.com.mk> Message-ID: References: <4FE9982C.9020605@dallaway.org.uk> <4FE9A0A5.1080909@siva.com.mk> <50127D75.8060507@ecoscentric.com> <50165611.8000202@siva.com.mk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Fwd: [ECOS] eCos arm-eabi GNU tools - test release 4.6.3-20120623 X-SW-Source: 2012-07/txt/msg00038.txt.bz2 On Mon, 30 Jul 2012, Ilija Kocho wrote: > Hi Alex > > Thanks for report. > > ustl has been upgraded recently > http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001545 > so we need to check if that is ustl or compiler or both. > > Unfortunately I have no LPC2468, or any target other than Cortex-M handy. > I'm adding Sergei to the CC, I hope he may have some insight. Hi Ilija, unfortunately, I have no LPC2468 too. That is Uwe's Kindler BSP for the Embedded Artists LCP2468 OEM board. Mine Olimex LPC229X targets. I'm sorry I cannot assist here too :-( But, I reported that I have no problems with the previous GNU toolchains builds (4.6 based) on theB AMT7TDMI-S targets from Olimex (all non-interactive USTL tests passed smoothly in RedBoot+GDB environment). And what's about the below (was it applied?) packages/hal/arm/lpc24xx/ea2468/current/ChangeLog 2012-04-23 Nick Garnett * include/pkgconf/mlt_arm_lpc24xx_ea2468_rom.ldi: * include/pkgconf/mlt_arm_lpc24xx_ea2468_ram.ldi: Relocate fixed vectors to 0x40000020. Previously, the HAL_VSR_GET/SET macros accessed the wrong locations and didn't have any effect; now both hardware and software have the same idea of where the VSR table is. NOTE: that this renders RAM applications built with this layout incompatible with RedBoot built with the old layout. A new RedBoot needs to be installed. I have no ideas anymore :-( Sergei > Thanks > Ilija > > > On 27.07.2012 13:37, Alex Schuilenburg wrote: > > Hi Ilija, > > > > On 2012-06-26 12:44, Ilija Kocho wrote: > >> Hi Alex > >> > >> As announced by John we have new test release of the GNU tools. This > >> release fixes the issues found in previous test releases in both GCC and > >> GDB so we can continue with testing. > >> Therefore I would ask you to put it on eCosCentric test farm. The > >> details for download and installation are below. > > The 4.6.3-20120623 arm tools are now in the farm running on the stm3210e > > eval board and lpc2468. Actually, I had the lpc2468 start in the farm a > > while ago but failed to monitor the results - they were all timing out > > because the old anoncvs redboot I built in March 2012 is now > > incompatible with the current anoncvs. Obviously RedBoot is now updated. > > > > One big issue is that the ustl permutation fails with every test on the > > lpc2468 for both arm and thumb. The tests fail to start - they either > > dont hit the cyg_test_init breakpoint or they fail with SIGBUS or, if > > they do hit cyg_test_start, they crash and burn afterwards with another > > SIGBUS. I have terminated all ustl tests for the lp2468 as a result as > > they simply slow things down. Unfortunately, excluding the ustl > > failures, the failure rate is currently 13 out of 484 tests run so far. > > I'll post a more complete list when it has run 5000 or more tests. > > > > The stm3210e is faring a lot better. 1113 tests run so far and only 6 > > failures: ustl tests that have failed so far are bvt05, bvt13, bvt17 and > > sprintf2. Both testintr and kexcept1 are failing in other perms as before. > > > > -- Alex > > > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss