Re: eCos GNU tools 4.6.2-20120125 ready for testing

[Alex Schuilenburg <alexs@ecoscentric.com>]

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