Re: eCos GNU tools 4.6.2-20120125 ready for testing

[John Dallaway <john at dallaway dot org dot uk>]

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