build RTEMS TIc4x

[Joel Sherrill]

liu danil wrote:
> Hello,anybody.
>
> My recent project has a TI c3x DSP board, and I want to use RTEMS on it. 
> But I tried for two weeks and couldn't find a right RTEMS and Tools version 
> combination.  
>
> I tried rtems-4.7-tic4x-rtems4.7-***.i386.rpm files in the 
> ftp.rtems.com/rtems/linux/4.7/redhat/7.3/i386 directory, but they didn't 
> work.
>
>   
First the tic4x was removed from the 4.7 release branch so it is an
accident to have the tools out there for 4.7. You should be trying it
with 4.8 tools and use the tic4x port from CVS.

Second.. why are they broken? Please be more specific. This is the
preferred toolset
for this target and even though it is a dying target, we are trying to
keep it alive
with the last toolset that seemed OK enough for it.

The sad truth is that the tic4x has been obsoleted as a target in gcc
and it is unlikely
any target newer than gcc 3.4.x will ever be made to work.
> As my DSP board is very simple, I think the very beginning BSP of RTEMS c4x 
> is enough. So I tried files in the directory ftp.rtems.com/c4x-tools.
>
>   
This is a directory of questionable value given its age but it is a
historical
capture of the "official" patches that floated around the net a few
years ago.
I recall that even Michael Hayes who was hosting a tic4x toolset site was
having trouble a while back finding these patches so I put what I had on
the net
in the interest of history.

Plus it was the only gdb simulator patch.

> From the file names I recognized that it need tools:
>  binutils-2.7
>  gcc-2.95.2
>  newlib-1.8.2
>
> So I attempted to build them one by one. First, I unpacked binutil-2.7, and 
> installed 
>   c4x-rtems-binutils-collection-2.7-1.nosrc.rpm
> there were two files in it:
>   binutils-c4x-1.6.3-glibc-1.diff
>   binutils-c4x-1.6.3.diff
> Then using these files to patch binutils-2.7. The first one was ok, but 
> when I patched the second file, it reported a wrong message in my cygwin 
> window:
>    patch: *** Only garbage was found in the patch input.
>
>   

Apparently, that file is gzip'ed also in spite of not having an extension.
The newlib 1.8.2 patch appears to be gzip'ed even though there was no
extension on it. I renamed it.

> I used vi to show binutils-c4x-1.6.3.diff, it's really only garbage. I 
> checked other files, found that file c4x-newlib-1.8.2-0.1.7.patch is also 
> garbage!
>
>   

Do you have the "file" command on Cygwin? I used it on Linux to discover
that
they were gzip'ed even though the extension wasn't there.
>   Is there any mistake when collected c4x tools? Could anyone send me a 
> right copy of such files?
>
> BTW, what the "1.6.3" in the file name means? as from the RPM file name I 
> thought the binutils version is 2.7.
>
>   
The people doing the tic4x tools had version numbers on their patches.
That's
all it means.

You will VERY lucky to compile a toolset that old on a host with recent
tools.
Even if you succeed, you might not even be able to compile RTEMS given
newlib
differences over the years. Please just report problems with the current
toolset
and let's see if we can work forward from there.

--joel
> Danilliu
>
> _________________________________________________________________
> 与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>