[ECOS] twothreads.c not working correctly on ARM AEB1

[ECOS] twothreads.c not working correctly on ARM AEB1

[javelina]

Greetings,

I have been experimenting with an ARM evaluation board using ecos 1.2.1
under Redhat Linux 6.1 with quite a bit of success, until recently I had
a hard disk failure.   I replaced the drive and began restoring my
system, and I figured it was a good time to update to ecos 1.3.1.

I very carefully followed the steps on
http://sourceware.cygnus.com/ecos/tools/linux-arm-elf.html
to install and build the development tools.  This all went smoothly.

Next, I downloaded
ecos-1.3.1-1.i386.rpm
from
http://sourceware.cygnus.com/ecos/install-linux.html
and installed it.  Then I set my PATH and ECOS_REPOSITORY as instructed.

Next I configured and built ecos as outlined in
http://sourceware.cygnus.com/ecos/docs-1.3.1/tutorials/arm/ecos-tutorial.11.html#pgfId=2031450

I issued the following commands:

mkdir ecos-work
cd ecos-work
ecosconfig new aeb1
ecosconfig tree
make

This all seemed to work perfectly.  No reported errors.

 I compiled the example twothreads.c (found in
/opt/ecos/ecos-1.3.1/examples) as follows:
arm-elf-gcc -I/home/javelina/ecos-work/install/include twothreads.c
-L/home/javelina/ecos-work/install/lib -Ttarget.ld -nostdlib
Which worked ok.

However when I ran the resulting a.out I got:

>arm-elf-gdb -nw a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i586-pc-linux-gnu
--target=arm-elf"...
>(gdb) set remotebaud 38400
>(gdb) target remote /dev/ttyS1
Remote debugging using /dev/ttyS1
0x4019358 in ?? ()
>(gdb) load
Loading section .rom_vectors, size 0x60 lma 0xc000
Loading section .text, size 0xea18 lma 0xc060
Loading section .rodata, size 0x474 lma 0x1aa78
Loading section .data, size 0x300 lma 0x1aeec
Start address 0xc060 , load size 61932
Transfer rate: 27525 bits/sec, 305 bytes/write.
>(gdb) continue
Continuing.
Entering twothreads' cyg_user_start() function
Beginning execution; thread data is 0
Beginning execution; thread data is 1
Thread 0: and now a delay of 1104334939 clock ticks
Thread 1: and now a delay of 1149184530 clock ticks

Notice the HUGE delay.  It should be something between 200 and 250.

My debugging efforts so far include:
- Updating the gdb stubs to 1.3
- Redoing the entire install procedure again, looking for any install
messages I missed the first time.
- Restoring my old ecos 1.2.1 kernel and tools to verify that they still
work (they do).

Has anybody else had this problem?  Am I missing something obvious?

Any help is appreciated,

Louis LeGrand

Re: [ECOS] twothreads.c not working correctly on ARM AEB1

[Jonathan Larmour]

javelina wrote:
> Continuing.
> Entering twothreads' cyg_user_start() function
> Beginning execution; thread data is 0
> Beginning execution; thread data is 1
> Thread 0: and now a delay of 1104334939 clock ticks
> Thread 1: and now a delay of 1149184530 clock ticks
> 
> Notice the HUGE delay.  It should be something between 200 and 250.

I haven't seen this before. Is this the default configuration? If not,
check what differs from the default. Also enable assertions (just in case
it catches something) and also tracing so you can see if there's some
problem with the per-thread data that rand() obtains from the kernel, for
example.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] twothreads.c not working correctly on ARM AEB1

[Jonathan Larmour]

javelina wrote:
> 
> Jonathan Larmour wrote:
> 
> > javelina wrote:
> > > Continuing.
> > > Entering twothreads' cyg_user_start() function
> > > Beginning execution; thread data is 0
> > > Beginning execution; thread data is 1
> > > Thread 0: and now a delay of 1104334939 clock ticks
> > > Thread 1: and now a delay of 1149184530 clock ticks
> > >
> > > Notice the HUGE delay.  It should be something between 200 and 250.
> >
> > I haven't seen this before. Is this the default configuration? If not,
[snip my waffle]
> To try your suggestion:
> I believe I enabled assertions by editing the section of the ecos.ecc file as
> shown below:
> 
> cdl_component CYGPKG_INFRA_DEBUG {
>     # Flavor: bool
>     user_value 1                             <<< I edited this line, 

Yep that's right.

> Then I recompiled the kernel, and tried to compile twothreads.c, as shown
> below:
> 
> #arm-elf-gcc -g -I/home/ljavelina/ecos_work_new/install/include twothreads.c
> -L/home/ljavelina/ecos_work_new/install/lib -Ttarget.ld -nostdlib
> /usr/cygnus/ecosSWtools-arm-990321/H-i586-pc-linux-gnu/lib/gcc-lib/arm-elf/2.9-ecosSWtools-arm-990321/../../../../arm-elf/bin/ld:
> address 0x280e8 of a.out section .data is not within region ram
[snip]
> Am I on the right track?  Are the messages the desired consequence of enabling
> the assertions (i.e. to they tell me the problem I was having with the
> twothreads executable), or are they an undesired consequence (i.e. the
> assertions make the executable to big)?

They're an undesired consequence :-(. In that case, to find out what's
going on, edit twothreads.c. At the beginning add:

#include <cyg/infra/diag.h>

and then further down replace *all three* calls to printf with diag_printf
instead. That should reduce the size requirements.

It would also help tell me whether rand() going wrong, or printf() if it
suddenly appears to start working :-).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] twothreads.c not working correctly on ARM AEB1

[Jonathan Larmour]

javelina wrote:
[snip]
> 
> When I turned on asserts with no tracing I get no additional output again:
> 
> (gdb) continue
> Continuing.
> Entering twothreads' cyg_user_start() function
> Beginning execution; thread data is 0
> Beginning execution; thread data is 1
> Thread 0: and now a delay of 1104334939 clock ticks
> Thread 1: and now a delay of 1149184530 clock ticks
[snip] 

Sorry, I should have said before: the reason that there's no output is that
that number of clock ticks is *far* too large. It's meant to be a number
between 200 and 250.

Let's try a different approach:

Change the following two lines of code in twothreads.c from 

  for (;;) {
    delay = 200 + (rand() % 50);
                                                                                             
to:

  for (;;) {
     int r, d;
     r=rand();
     d=rand() % 50;
     delay = 200 + d;
     diag_printf("r=%d, d=%d, delay=%d\n", r, d, delay );

Another thing to do is to try compiling twothreads.c both with and without
optimization (i.e. with -O2 or without -O2) and see if there's any
difference.

HTH,

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] twothreads.c not working correctly on ARM AEB1

[Jonathan Larmour]

[ stuff about twothreads delay not being computed correctly, traced to
dodgy % behaviour ]

javelina wrote:
>
> As a sanity check on the bad behavior of the % operator, I wrote a tiny program to
> isolate the problem
> 
>//////////////////////////////////////////////
> 
> #include <stdio.h>
> 
> int main(void)
> {
>    int i;
>    int m;
>    for (i=0; i < 21; i++) {
>        m = i % 5;
>        printf("%d %d\n", i, m);
>    }
> }
>//////////////////////////////////////////////
> 
> The ouput looks like:
> 
> (gdb) continue
> Continuing.
> 0 0
> 1 1
> 2 2
> 3 3
> 4 4
> 5 5
> 6 6
[snip] 
> So it realy does look like a mod operator problem.  Let me know what you think.

Aha! I found it, and it's interesting. Basically, for the AEB, you *must*
compile with -mcpu=arm7di as used in the example makefile. However, you
didn't compile this program, nor twothreads with this option. Whenever I
compile the above with -mcpu=arm7di it works, and without it, it behaves as
you saw. 

The reason is that without -mcpu=arm7di, the compiler will default to
-mcpu=arm7tdmi, which assumes you have a fast multiplier unit, which the
arm7di (as used on the AEB) doesn't.

As a result the compiler uses the "smull" instruction, which fails silently
- unfortunately the ARM doesn't raise an exception when this instruction is
not supported.

So compile with -mcpu=arm7di and all will be well.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault