From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22391 invoked by alias); 4 Mar 2012 19:37:35 -0000 Received: (qmail 22382 invoked by uid 22791); 4 Mar 2012 19:37:34 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from tetra.codeconfidence.com (HELO tetra.codeconfidence.com) (94.229.66.225) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Mar 2012 19:37:19 +0000 Received: from cog.dallaway.org.uk (cpc1-cmbg10-0-0-cust34.5-4.cable.virginmedia.com [81.102.132.35]) by tetra.codeconfidence.com (Postfix) with ESMTP id 1269D234C17B; Sun, 4 Mar 2012 19:37:17 +0000 (GMT) Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id q24JbFtf027778; Sun, 4 Mar 2012 19:37:15 GMT Message-ID: <4F53C46B.4090502@dallaway.org.uk> Date: Sun, 04 Mar 2012 19:37:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.24 (X11/20111109) MIME-Version: 1.0 To: Alex Schuilenburg CC: Ilija Kocho , eCos developers Subject: Re: eCos GNU tools 4.6.2-20120125 ready for testing 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> <4F39887A.5050905@siva.com.mk> <4F50F700.5080902@ecoscentric.com> <4F521D6A.4010500@siva.com.mk> <4F52B2C8.4010809@schuilenburg.org> In-Reply-To: <4F52B2C8.4010809@schuilenburg.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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-03/txt/msg00005.txt.bz2 Hi Alex Alex Schuilenburg wrote: > On 03/03/2012 13:32, Ilija Kocho wrote: >> On 02.03.2012 17:36, Alex Schuilenburg wrote: >>> [...] >>> Thanks. I have taken a test snapshot of anoncvs on 2012-03-01 >>> 00:00:00:00 along with the toolchain above and thrown that to our test >>> farm. Unfortunately the Embedded Artists LPC2468-32 anoncvs port >>> appears to be either incompatible with our RedBoot or is broken in >>> anoncvs. All the tests fail to hit a breakpoint set at cyg_test_init, >>> or run without any breakpoints. I suspect this port appears to have >>> suffered bitrot since the V3 as the board appears to have been run in >>> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on >>> the board is dated Apr 25 2008 which goes back to V2. >>> >>> I have just switched to using our eCosPro sources and the first couple >>> of tests I checked passed, so at least this confirms this is not any >>> issue with the toolchain. Using the same set of eCosPro sources with our >>> ecospro tools and the anoncvs tools at least will tell us if there is >>> any regression. Unfortunately though, if there is a regression we will >>> only be able to report the test/s that failed along with the flags and >>> configuration used to build the tests. Otherwise somebody is going to >>> need to fix the anoncvs port for the Embedded Artists LPC2468-32 board. >> >> Thank you Alex. >> I think that the first step is to find out whether it is a problem with >> EA LPC2468-32 code or more general. Unfortunately I am not able to test >> with this board as we don't have one > > I am pretty certain it is an issue with the EA LPC2468-32 code in > anoncvs as the eCosPro EA LPC2468-32 builds and runs fine, although it > could be a more general issues with the anoncvs code (see below). An incompatibility between eCos RAM startup application code and the eCosPro build of RedBoot for this platform seems more likely. > There is only one issue uncovered so far, and that is the backtrace of > gdb 7.3 is unreliable. It occasionally can end up in an infinite loop, > while our own 7.2 gdb for eCosPro works just fine in exactly the same > tests (i.e. built with gcc 4.6.2). However, I guess users could add a > "set backtracelimit=100" and that should catch this issue. That is useful info, thank you. Could you provide examples of the infinite backtrace please? We need to understand which of the backtrace backstops is missing or ineffective. >> I hope that the testing with STM32 may give us some hint. > > anoncvs eCos for the stm3210e_eval board behaves unfortunately in > exactly the same manner. tests do not even reach cyg_test_init. I just > did the same switch to the eCosPro source base and the tests run so far > all passed. > >> I also wander if test with RedBoot from current CVS would help. > > I spoke to Nick Garnett who said there is a remote possibility that the > anoncvs sources have become incompatible with the eCosPro RedBoot, Certainly some change, either in eCos sources or eCosPro sources, may have introduced an incompatibility. At present, this seems to be the most likely explanation for the behaviour you have observed. > and given that anoncvs tests for both selected targets die in the same > manner, I will rebuild RedBoot and give it a go. Great. Thank you. Clearly RedBoot and RAM startup application code must share a common understanding of memory layout (including the precise layout of the virtual vector table). > I'll need to fetch the > boards from the testfarm though (our testfarm is off-site, in a shed on > a "farm" :-) to do this, or maybe just try a RAM redboot first. I'll > let you know how I get on. > > Hopefully it is something simple and not that eCos in anoncvs for both > boards has been subject to bitrot. FYI, I have just built ROM RedBoot and the tm_basic kernel test for STM3210E-EVAL from latest CVS sources using the new arm-eabi test release toolchain (4.6.2-20120125). I can confirm that there is no issue with running this (RAM startup) test via this RedBoot image and hitting breakpoints at cyg_test_init() and cyg_test_exit(). There are many people using this board within the eCos community and I believe that eCos/RedBoot support for STM3210E-EVAL is solid. However, this success was achieved using arm-eabi-gdb 6.8.50.20080706. There does appear to be an issue with the length of the 'g' packet when using the new arm-eabi-gdb 7.3.1: > (gdb) tar rem /dev/ttyS0 > Remote debugging using /dev/ttyS0 > Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021 > (gdb) We will need to look into why the packet length has apparently changed for Cortex-M targets. I can connect to an ARM7 target using the new GDB without problem. John Dallaway -- John Dallaway eCos maintainer http://www.dallaway.org.uk/john