RE: Fwd: Different behaviour of RTEMS in QEMU/i386 and SPARC

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

arm build failure on gcc head

Hi,

This looks like an issue with the gcc head (4.7.0)
Compiling the RTEMS head.  It looks like an extra
flag needs to be passed to ld and we are missing
something.

With the gcc head, you get this for the csb336 BSP.

arm-rtems4.11-gcc -mstructure-size-boundary=8 -mcpu=arm920 -mfpu=vfp 
-mfloat-abi=soft -O2 -g  
m.c
/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld: 
error: /tmp/ccs3cuW7.o uses VFP instructions, whereas a.out does
not
/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld: 
failed to merge target specific data of file
/tmp/ccs3cuW7.o
/users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld: 
warning: cannot find entry symbol _start; defaulting to 0000000000008000
collect2: error: ld returned 1 exit status

Any ideas?

--

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: arm build failure on gcc head

On 11/01/2011 07:43 PM, Joel Sherrill wrote:
> Hi,
>
> This looks like an issue with the gcc head (4.7.0)
> Compiling the RTEMS head. It looks like an extra
> flag needs to be passed to ld and we are missing
> something.
>
> With the gcc head, you get this for the csb336 BSP.
>
> arm-rtems4.11-gcc -mstructure-size-boundary=8 -mcpu=arm920 -mfpu=vfp
> -mfloat-abi=soft -O2 -g m.c
> /users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld:
> error: /tmp/ccs3cuW7.o uses VFP instructions, whereas a.out does not
> /users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld:
> failed to merge target specific data of file /tmp/ccs3cuW7.o
> /users/joel/test-gcc/install-svn/lib/gcc/arm-rtems4.11/4.7.0/../../../../arm-rtems4.11/bin/ld:
> warning: cannot find entry symbol _start; defaulting to 0000000000008000
> collect2: error: ld returned 1 exit status
>
> Any ideas?
>

Append -v -Wl,-v to the compiler call and compare the results of 
compiling with gcc-4.6.2 and your compiler.

Ralf
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Building RTEMS

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: Building RTEMS

On 11/02/2011 09:10 AM, Asma Mehiaoui wrote:
> Hello everybody,
>
> I tried to built RTEMS on the target i386 and bsp= i386ex
>
> i made: ../rtems-4.10.1/configure --target= i386 --disable-posix
                                             ^^^^^^
This needs to be --target=i386-rtems4.10

There are 2 mistakes with dramatic consequences in your invocation of 
configure:
a) a blank between "--target=" and "i386"
b)"i386" not a valid target for RTEMS.

> --disable-networking --disable-cxx --enable-rtemsbsp=i386ex
> --prefix=/opt/rtems-4.11/
            ^^^^^^^^^^^^^^^^

Though the value passed to --prefix can be arbitrarily chosen, you on 
one hand seem to be trying to build rtems-4.10, but on the other hand 
seem to be intending to install into a "rtems-4.11" directory.

As RTEMS 4.10 and RTEMS 4.11 are quite different and require different 
toolchains, so mixing them will rarely work.
This doesn't seem wise to me.
> when i did "make all" i had these error:
>
>
> In file included from
> ../../cpukit/../../../i386ex/lib/include/rtems/libio_.h:22:0,
> from ../../../../../rtems-4.10.1/c/src/../../cpukit/posix/src/sysconf.c:23:
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:56:18: error:
> expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rtems_off64_t’
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:109:24: error:
> expected declaration specifiers or ‘...’ before ‘*’ token
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:111:3: error:
> expected declaration specifiers or ‘...’ before ‘rtems_off64_t’
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:109:9: warning:
> type defaults to ‘int’ in declaration of ‘rtems_off64_t’
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:109:9: error:
> ‘rtems_off64_t’ declared as function returning a function
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:113:1: warning:
> function declaration isn’t a prototype
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:164:5: error:
> expected specifier-qualifier-list before ‘rtems_filesystem_lseek_t’
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:363:43: error:
> field ‘size’ declared as a function
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:364:43: error:
> field ‘offset’ declared as a function
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:382:27: error:
> field ‘offset’ declared as a function
> ../../cpukit/../../../i386ex/lib/include/rtems/libio.h:461:25: error:
> ‘rtems_libio_lseek_t’ declared as function returning a function
> ../../../../../rtems-4.10.1/c/src/../../cpukit/posix/src/sysconf.c: In
> function ‘sysconf’:
> ../../../../../rtems-4.10.1/c/src/../../cpukit/posix/src/sysconf.c:47:12: error:
> ‘PAGE_SIZE’ undeclared (first use in this function)
> ../../../../../rtems-4.10.1/c/src/../../cpukit/posix/src/sysconf.c:47:12: note:
> each undeclared identifier is reported only once for each function it
> appears in
> make[5]: *** [src/libposix_a-sysconf.o] Erreur 1
> make[5]: quittant le répertoire «
> /home/asma/Bureau/building-RTEMS/b-sis/c/i386ex/cpukit/posix »
> make[4]: *** [all-recursive] Erreur 1
> make[4]: quittant le répertoire «
> /home/asma/Bureau/building-RTEMS/b-sis/c/i386ex/cpukit »
> make[3]: *** [all] Erreur 2
> make[3]: quittant le répertoire «
> /home/asma/Bureau/building-RTEMS/b-sis/c/i386ex/cpukit »
> make[2]: *** [all-recursive] Erreur 1
> make[2]: quittant le répertoire «
> /home/asma/Bureau/building-RTEMS/b-sis/c/i386ex »
> make[1]: *** [all-recursive] Erreur 1
> make[1]: quittant le répertoire « /home/asma/Bureau/building-RTEMS/b-sis/c »
> make: *** [all-recursive] Erreur 1
These likely are all follow-ups to how you specify "--target= "

Ralf
_______________________________________________
rtems-users mailing list
rtems-users <at> rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users

Question regarding driver

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

MVME162 BSP Issues

On the web page for this BSP the "Test Reports" section has the following comment:

  CVS head -- March 24, 2011: User:Richard Campbell:
  Ticker ran successfully; File I/O printed to console but did not accept input.

This still seems to be the case with RTEMS version 4.10.1 (in addition the loopback program in the
testsuites/samples directory locks up with a yellow STAT light - the processor halts).

1) Has anyone gotten the console to work properly for this board?

2) Is anyone actively using this BSP?

Note that the ticker and base_sp programs from testsuites/samples both run.  Originally they also
triggered the yellow SCON light upon completion and do not return to the 162Bug program.  This is the result
of bugs in the bsp_return_to_monitor_trap() function in the bspclean.c module.

There's an #ifdef for mvme162lx that conditionally sets the 162Bug vector address.  By default, 162Bug
uses DRAM to run in and the address should always be 0x0 (not 0xFFE00000, this is the SRAM address).  The rest
of the function is commented out with an #if 0 block that says it does not work on the 162 board.  If the vector
address is correctly restored the code does work (at least it does on an MVME162-413 board).

	Vic Hoover

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: MVME162 BSP Issues

On 11/02/2011 09:21 AM, Hoover, Victor P CTR NAVAIR, AIR 4.1.3.3 wrote:
> On the web page for this BSP the "Test Reports" section has the following comment:
>
>    CVS head -- March 24, 2011: User:Richard Campbell:
>    Ticker ran successfully; File I/O printed to console but did not accept input.
>
That would be the board in the RTEMS lab which only gets spotty
checking.  We also had issues with where the console was directed
at first.  I recall it wasn't the same as where 162Bug went.
> This still seems to be the case with RTEMS version 4.10.1 (in addition the loopback program in the
testsuites/samples directory locks up with a yellow STAT light - the processor halts).
>
The NIC is not yet supported.

Besides this is a loopback test with only the local interface.
If it locks up, then there is a reason.  I have no idea what though.
> 1) Has anyone gotten the console to work properly for this board?
>
> 2) Is anyone actively using this BSP?
>
>
Those are both questions for the community.  We did not
have this board for the lab until not long before we tested
it.  If the console input ever worked, I don't know.

Check c/src/lib/libbsp/m68k/mvme162/console/console.c

FWIW this looks like a pre-termios driver so it is possible that
the input doesn't interface correctly.  Check that inbyte works
and then refactor the driver to follow the "simple polled
single port" template.  powerpc/psim has a nice example of
this.  Basically inbyte/outbyte become support routines
for a framework.

This is a very old BSP.  It was the first BSP ever submitted.
Any updates will be appreciated.  I will review and merge
them.
> Note that the ticker and base_sp programs from testsuites/samples both run.  Originally they also
triggered the yellow SCON light upon completion and do not return to the 162Bug program.  This is the result
of bugs in the bsp_return_to_monitor_trap() function in the bspclean.c module.
>
> There's an #ifdef for mvme162lx that conditionally sets the 162Bug vector address.  By default, 162Bug
uses DRAM to run in and the address should always be 0x0 (not 0xFFE00000, this is the SRAM address).  The rest
of the function is commented out with an #if 0 block that says it does not work on the 162 board.  If the vector
address is correctly restored the code does work (at least it does on an MVME162-413 board).
>
Submit a patch.  If you can tidy up the lose ends on this BSP.

It is likely a case of mild bitrot over the years. :(
> 	Vic Hoover
>
>
>

--

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

RE: MVME162 BSP Issues

> The NIC is not yet supported.

Okay, if I make any progress at all I should be able to steal network
Code from the MVME167 BSP - my 162 and 167 boards (at least) use the
Same NIC chip.

> FWIW this looks like a pre-termios driver so it is possible that
> the input doesn't interface correctly.  Check that inbyte works
> and then refactor the driver to follow the "simple polled
> single port" template.  powerpc/psim has a nice example of
> this.  Basically inbyte/outbyte become support routines
> for a framework.

Yep, I had already dug through the console.c code for both the 162 and
167 BSPs and noticed that the 162 BSP didn't have the termios code.

> This is a very old BSP.  It was the first BSP ever submitted.
> Any updates will be appreciated.  I will review and merge
> them.

Hopefully I can get things working although it's going to be on a part
time basis.  I need to build a system to do some data capture but it's
currently a low priority project.

On the seriously bad side though I seem to have some problems with the
development tools.  I've discovered that the printf function doesn't
work right for me.  If I do a printf of a newline terminated string it
prints to the console.  If the string does not end with a newline or
if the string contains any kind of formatting commands (%s, %d, etc.)
then processor halts.  If I can't sort this out then trying to do any
kind of testing or development is going to be very tricky.

	- Vic Hoover

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: MVME162 BSP Issues

On 11/02/2011 11:57 AM, Hoover, Victor P CTR NAVAIR, AIR 4.1.3.3 wrote:
>
>> The NIC is not yet supported.
> Okay, if I make any progress at all I should be able to steal network
> Code from the MVME167 BSP - my 162 and 167 boards (at least) use the
> Same NIC chip.
>
>> FWIW this looks like a pre-termios driver so it is possible that
>> the input doesn't interface correctly.  Check that inbyte works
>> and then refactor the driver to follow the "simple polled
>> single port" template.  powerpc/psim has a nice example of
>> this.  Basically inbyte/outbyte become support routines
>> for a framework.
> Yep, I had already dug through the console.c code for both the 162 and
> 167 BSPs and noticed that the 162 BSP didn't have the termios code.
>
That's what I tried years ago for someone.  But it never got
debugged.  There are minor differences between the two
boards so it should be a matter of just tripping the right bit.

FWIW the 167 BSP is used more by the EPICS community.
But both boards are quite old at this point.  I know we
had to located a new RTC because the battery had died
in the one we were given.
>> This is a very old BSP.  It was the first BSP ever submitted.
>> Any updates will be appreciated.  I will review and merge
>> them.
> Hopefully I can get things working although it's going to be on a part
> time basis.  I need to build a system to do some data capture but it's
> currently a low priority project.
>
It should be quite good at that.
> On the seriously bad side though I seem to have some problems with the
> development tools.  I've discovered that the printf function doesn't
> work right for me.  If I do a printf of a newline terminated string it
> prints to the console.  If the string does not end with a newline or
> if the string contains any kind of formatting commands (%s, %d, etc.)
> then processor halts.  If I can't sort this out then trying to do any
> kind of testing or development is going to be very tricky.
>
I am pretty sure that is a side effect of the driver not
properly supporting termios.  I would do the minor
hacking required to switch it to the same style as
psim.  It shouldn't take very long.  That also might be
enough to fix reading the console.

printf() also shouldn't be used during initialization, etc.
due to being able to potentially block.
> 	- Vic Hoover
>
>

--

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users