Is the "or32" target still supported?

[Paul Cadaret]

Ralph,
Your comments are in line with my experience over the last few days. 
 After trying to use the source trees
from rtems.com to build the or32-rtems target without success, I made my 
post to the rtems-users list
and started digging into everything I could find on the 'opencores.org' 
site.

See my comments below.

Thank Ralph.
Paul
-------------------------------------------
Ralf Corsepius wrote:

>On Fri, 2004-01-02 at 20:48, Paul Cadaret wrote:
>  
>
>>Hello,
>>The web page   http://www.rtems.com/targets.html    says that the 'or32' 
>>target is supported.
>>    
>>
>I don't know if the or32 has ever worked for anybody, nor if it has ever
>built for anybody.
>
>But I know, that the or32 is on a top ranking place to be abandoned and
>removed for RTEMS-4.7, unless the general or32 situation changes
>basically soon (If I had to decide, it already would be gone).
>
>  
>
>>    If you have knowledge of the processors used in the above ports and
>>    want to contribute to RTEMS, please contact a member of the RTEMS
>>    Steering Committee.
>>
>>I wasn't sure what to make of this.
>>    
>>
>AFAICT, the or32 status is as follows:
>1. or32 support is part of binutils >= 2.14
>
On Solaris-7, I was able to build the binutils for a or32-rtems target.

>2. The open cores folks have not contributed their gcc port to the FSF
>gcc and had been using a modified gcc instead.
>3. The or32 port in RTEMS is an adaptation the code the OpenCore folks
>had on their web site.
>
>I don't know if the OpenCores project is alive anymore.
>Fact is, there had not been any RTEMS/OpenCores activities for years,
>nor did the OpenCores folks contribute their gcc code to the official
>FSF/GCC.
>
I have tried building their modified gcc-3.1 for the or32-rtems target:
configures- OK

    + /bin/sh ../gcc-3.2.3/configure --prefix=/tools/local.or32-rtems
    --target=or32-rtems --program-prefix=or32-rtems- --with-gnu-as --w
    ith-gnu-ld --with-newlib --verbose --enable-threads
    --enable-languages=c,c++ --disable-nls
    Configuring for a sparc-sun-solaris2.7 host.
    ...

make - dies building libstdc++-v3 as follows:

    ... 
    4500  ../../../../gcc-3.1/libstdc++-v3/libsupc++/eh_catch.cc: In
    function `bool
      4501     std::uncaught_exception()':
      4502  ../../../../gcc-3.1/libstdc++-v3/libsupc++/eh_catch.cc:105:
    Internal compiler
      4503     error in emit_move_insn, at expr.c:2746
      4504  Please submit a full bug report,

Build documentation... yet to find it... I'm extrapolating from the 
m68k-rtems procedure I used earlier.

I have tried building their modified gcc-3.2.3 for the or32-rtems target 
as well:
configures- OK

    + /bin/sh ../gcc-3.2.3/configure --prefix=/tools/local.or32-rtems
    --target=or32-rtems --program-prefix=or32-rtems- --with-gnu-as --w
    ith-gnu-ld --with-newlib --verbose --enable-threads
    --enable-languages=c,c++ --disable-nls
    Configuring for a sparc-sun-solaris2.7 host.
    ...

make - dies right away:

        44  + make
        45  make[1]: Entering directory
    `/sd/c0t8d0/opt1/web/sites/www.opencores.org/openrisc_1000/cvs/or1k/gcc-3.2.3.or32-rtems/fastjar
        45  '
        46  /tools/local/bin/gcc -DHAVE_CONFIG_H -I.
    -I../../gcc-3.2.3/fastjar -I. -I. -I../../gcc-3.2.3/fastjar
    -I../../gcc-3.2.3/fastj
        46  ar/../zlib -I../../gcc-3.2.3/fastjar/../include   -W -Wall
    -pedantic -Wstrict-prototypes -Wmissing-prototypes -Wwrite-string
        46  s -g -O2 -c ../../gcc-3.2.3/fastjar/jartool.c
        47  ../../gcc-3.2.3/fastjar/jartool.c:195: zlib.h: No such file
    or directory
        48  ../../gcc-3.2.3/fastjar/jartool.c:234: getopt.h: No such
    file or directory
        49  make[1]: *** [jartool.o] Error 1
        50  make[1]: Leaving directory
    `/sd/c0t8d0/opt1/web/sites/www.opencores.org/openrisc_1000/cvs/or1k/gcc-3.2.3.or32-rtems/fastjar'
        51  make: *** [all-fastjar] Error 2

Not very encouraging...

I'm going generate some postings to the 'openrisc' mailing lists and see 
if I can get some guidance there.
I'll let you know my results.  

>
>  
>
>>    ftp://ftp.rtems.com/pub/rtems/releases/4.6.0pre5/tools/rtems-4.6-binutils-2.13.2.1-1/source/
>>    ftp://ftp.rtems.com/pub/rtems/releases/4.6.0pre5/tools/rtems-4.6-gcc3.2.3newlib1.11.0-1/source/
>>
>>I had already applied all the diffs to these source files and had run 
>>configure and built them successfully for
>>the m68k-rtems target.   I then decided to try to just build for an 
>>'or32-rtems' target to see what would happen.
>>    
>>
>It won't work. You'd have to use the gcc version from the opencores's
>website for or32-targets, because or32-support is not part of the
>FSF-sources.
>  
>
Yes

>
>  
>
>>I can definitely use some guidance here.  
>>I would like to know if there are any OR32 specific build instructions.
>>    
>>
>First of all, you probably should try to clarify if the opencores
>project is still alive at all.
>
I'll try to assess this and let you know.

>If you're seriously interested in it, you then should either try to
>merge their patches to gcc into the RTEMS gcc-sources or to add the
>RTEMS specific patches to gcc into their gcc-sources.
>
>If opencores should be dead, and/or if you (or an other OpenCores
>person) are not interested enough to improve the or32/RTEMS/GCC
>integration,  I'd prefer to let the or32 support in RTEMS die, ASAP.
>
>Ralf
>
>
>  
>
Thanks again