On 04/03/2012 19:37, John Dallaway wrote: > 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.
Could be. I was basing my hypothesis off the fact that the LPC2468-32 was run in the farm as part of the eCos 3.0 public release and the RedBoot on that board is dated April 2008 so at some point I assumed anoncvs eCos ran successfully. >> 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. kexcept1 and except1 backtrace fail in every perm with 7.3 gdb. 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. It should be - we contributed it ;-) This is useful info at least and does point to an incompatibility issue between the eCos and eCosPro RedBoot. I will put the RedBoot built from anoncvs onto both boards and restart... > > 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) Ooops. I had forgotten to reload our test client to use the newer gdb when I reported the first couple of tests had passed. We also see the same failure. -- Alex
