RTEMS on TMS570
Pavel Pisa
pisa at cmp.felk.cvut.cz
Tue Feb 3 18:57:22 UTC 2015
Hello Martin,
On Tuesday 03 of February 2015 16:49:44 Martin Galvan wrote:
> Hello Pavel! I'm writing you about the RTEMS support on the TMS570. Last
> time we spoke I mentioned a bug on printf which caused the system to hang
> when trying to print a two-digit decimal numer (e.g. 42). We've been trying
> out a number of solutions but so far we haven't succeeded. We were using a
> toolchain generated by the RTEMS Source Builder. However, we noticed that
> the bug seems to disappear if we use the toolchain you posted here:
>
> https://rtime.felk.cvut.cz/debian/pool/main/b/binutils-2.24/
> https://rtime.felk.cvut.cz/debian/pool/main/g/gcc-4.9.0/
>
> As those are .deb packages, however, we have no way to know which version
> of the sources you used or how did you configure them. Running
> arm-rtems4.11-gcc -v gives us the following output:
My latest builds versions are available there
https://rtime.felk.cvut.cz/debian/pool/main/b/binutils-2.24/
https://rtime.felk.cvut.cz/debian/pool/main/g/gcc-4.9.2/
I prepare these mainly for internal purpose to help students to start-up
projects. But I would be happy if we find where is problem with
other builds and I can re-pack my sources for others as well.
I have followed Newlib development and proposed required multilib
combinations then I followed Sebastian Huber's development and
I has been convinced that all required changes has been push
to project mainlines.
My binutils setup
Sources binutils-2.24, no patches
Configure
CFLAGS=-O2 LDFLAGS=-s \
../../../binutils/configure \
--build=x86_64-pc-linux-gnu \
--target=arm-rtems4.11 \
--with-gnu-ld --exec-prefix=/usr --prefix=/usr \
--verbose --disable-nls \
--disable-win32-registry \
--disable-werror \
--with-mmap --enable-64-bit-bfd \
The latest GCC setup
Sources gcc-4.9.2, no patches
Next components are linked into GCC source tree
gmp -> ../gmp-5.1.3
mpc -> ../mpc-1.0.2
mpfr -> ../mpfr-3.1.2
newlib -> ../newlib-2.1-141030/newlib
No patches are applied in any of these projects but plain
Newlib 2.1 is insufficient, more changes has been applied
to mainline to resolve some issues when incorrect opcodes
leaked to the Cortex-R build etc. The exact last commit
of the snapshot I have used is
git://sourceware.org/git/newlib.git
commit 9b9f839addfe16ab0fd11f09a30a28139bfae6d5
Author: jturney <jturney>
Date: Thu Oct 30 11:25:16 2014 +0000
2014-10-29 Jon Turney <jon.turney at dronecode.org.uk>
* libc/include/string.h: Correct guard for strcasecmp().
The GCC configure used is there
CFLAGS="-O2 -pipe" LDFLAGS=-s \
../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr \
--build=x86_64-pc-linux-gnu \
--enable-languages=c,c++ \
--disable-libstdcxx-pch \
--with-gnu-ld \
--with-gnu-as \
--enable-threads \
--enable-target-optspace \
--with-system-zlib \
--verbose \
--disable-nls --without-included-gettext \
--disable-win32-registry \
--with-newlib \
--enable-plugin \
--enable-newlib-io-c99-formats \
--enable-version-specific-runtime-libs \
--enable-newlib-iconv \
--disable-lto \
As you can see, I compile all stuff out of source directories to keep single
clean source trees for all builds. Build is achieved by simple "make"
command after configure.
The only modification to standard install mechanism is hack to automatically
prepare directory for DEB package build without need to manually define
versions etc. When respective attached script is run in binutils, gcc, gdb
build directory it runs install with DESTDIR set to /usr/local/pkg and then
retrieves required information about target, version etc from configure status
files leaved in the build directory. Scripts then prepares Debian package
control file from retrieved information so running next sequence in
/usr/local/pkg builds Debian packages
for i in * ; do
if [ -d $i ] ; then
chown root:root -R $i
chmod a-s -R $i
dpkg -b $i
fi
done
The code of the my_XXXarch_install scripts ensures that most of files
which would collide with standard distribution parkages are deleted.
There is some rearrangement of binaries locations as well.
It is mostly for historical reasons but idea is that I can have
multiple full GCC versions installed in
/usr/arm-rtems4.11/gcc/4.9.0
/usr/arm-rtems4.11/gcc/4.9.1
/usr/arm-rtems4.11/gcc/4.9.2
and only change required to test with other version is to redirect
link
/usr/arm-rtems4.11/gcc/current
to the right version subdirectory.
But usual "make install" in the build directory should work same way
but you lost control a little what and where has been installed.
My scripts could work with allmost each autoconf based package
after little tweaking.
Please, try to build tools from the same packages versions.
If it works, try to build and test latest availabe versions.
If there is problem with your builds, try compile test with my binaries.
If you have problems then readelf or arm-rtems4.11-objdump is quite helpfull
to search for object files ARM features attributes to find if some
part of newlib is build for incorrect CPU variant. The TMS570 Cortex-R
uses one of following wariants
/usr/arm-rtems4.11/lib/eb/thumb/armv7-r
/usr/arm-rtems4.11/lib/eb/thumb/armv7-r/vfpv3-d16/hard
Best wishes,
Pavel
PS: the exam term period is over and I hope that my student finds time
to push TMS570 forward a little or more now
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my_binarch_install
Type: text/x-shellscript
Size: 3836 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150203/57e9aee2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my_gdbarch_install
Type: text/x-shellscript
Size: 4002 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150203/57e9aee2/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my_gccarch_install
Type: text/x-shellscript
Size: 6508 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150203/57e9aee2/attachment-0002.bin>
More information about the devel
mailing list