This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: eCos GNU tools 4.6.2-20120125 ready for testing
- From: Alex Schuilenburg <alexs at ecoscentric dot com>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: Ilija Kocho <ilijak at siva dot com dot mk>, eCos developers <ecos-devel at ecos dot sourceware dot org>
- Date: Sun, 04 Mar 2012 23:47:25 +0000
- 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> <4F53C46B.4090502@dallaway.org.uk>
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