Re: [taste-users] TASTE with RTEMS 4.12 (or maybe 5.1)

[Thanassis.Tsiodras@xxxxxxx]

>  There
are too many RTEMS drivers for the Gaisler platforms around in the 
wild

I didn't explain
properly - I was referring here to TASTE drivers, i.e. this sort of thing:

https://gitrepos.estec.esa.int/taste/polyorb-hi-c/blob/master/src/drivers/po_hi_driver_rasta_spacewire.c

Every time there's
an RTEMS API-related change, these need to follow along - and ideally,
use the appropriate #ifdefs to continue compiling even if someone uses
an older toolchain with an older version of RTEMS.

Fully in agreement
with what you said, otherwise - in fact I am hoping that as some point
in the future the TASTE VM (and Dockerfile) will be acting as a sort of
"baseline" with a ready-made toolchain, that one can reproduce
from source on his/her own . 

Thanassis
Tsiodras
Real-time Embedded
Software Engineer 
System, Software
and Technology Department

ESTEC
Keplerlaan 1,
PO Box 299
NL-2200 AG Noordwijk,
The Netherlands
Thanassis.Tsiodras@xxxxxxx
| www.esa.int
T +31 71 565 5332



From:
       Sebastian
Huber <sebastian.huber@xxxxxxxxxxxxxxxxxx>
To:
       Thanassis.Tsiodras@xxxxxxx
Cc:
       taste-users@xxxxxxxxxxxxxxxxxxx
Date:
       17/10/2017
11:18
Subject:
       Re:
[taste-users] TASTE with RTEMS 4.12 (or maybe 5.1)

---

Hello Thanassis,

On 16/10/17 10:04, Thanassis.Tsiodras@xxxxxxx wrote:
> Hello, Sebastian.
>
> *The good news:*
>
> The current version of TASTE is already using RTEMS 4.12 :-) You can
> see this for yourself by downloading the TASTE VM: from 
> https://taste.tools/go
to "Download area" and you will see a big /.ova 
> /file (/TASTE-VM-9.0.1-32bit.ova/) - that's a VirtualBox "appliance"
> that you can import in any installation of VirtualBox.
>
> Booting that machine you will then see...
>
> /(master)*$ sparc-rtems4.12-gcc -v/
> /Using built-in specs./
> /COLLECT_GCC=sparc-rtems4.12-gcc/
> /COLLECT_LTO_WRAPPER=/opt/rtems-4.12-2017.07.17/libexec/gcc/sparc-rtems4.12/7.1.0/lto-wrapper/
>
> /Target: sparc-rtems4.12/
> /Configured with: ../gcc-7.1.0/configure 
> --prefix=/opt/rtems-4.12-2017.07.17 
> --bindir=/opt/rtems-4.12-2017.07.17/bin 
> --exec_prefix=/opt/rtems-4.12-2017.07.17 
> --includedir=/opt/rtems-4.12-2017.07.17/include 
> --libdir=/opt/rtems-4.12-2017.07.17/lib 
> --libexecdir=/opt/rtems-4.12-2017.07.17/libexec 
> --mandir=/opt/rtems-4.12-2017.07.17/share/man 
> --infodir=/opt/rtems-4.12-2017.07.17/share/info 
> --datadir=/opt/rtems-4.12-2017.07.17/share --build=i686-linux-gnu
> --host=i686-linux-gnu --target=sparc-rtems4.12 --disable-libstdcxx-pch
> --with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls
> --without-included-gettext --disable-win32-registry 
> --enable-version-specific-runtime-libs --disable-lto 
> --enable-newlib-io-c99-formats --enable-newlib-iconv 
> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258--enable-threads
> --disable-plugin --enable-libgomp --enable-languages=c,c++,ada/
> /Thread model: rtems/
> /gcc version 7.1.0 20170502 (RTEMS 4.12, RSB 
> e2952bb185c1f40027caa76cfd9e4a45b17a8886-modified, Newlib 
> 2.5.0.20170623) (GCC) /
>
> This is a version of 4.12 built from the commit you indicated as the
> right one to use for projects, back in July - that is, the last one
we 
> tested on both the GR712 and the GR740 - with all tests passing.

ok, this is good. I didn't test the VM yet and the wiki page

http://taste.tuxfamily.org/wiki/index.php?title=Building_a_TASTE-y_RTEMS

indicated that a hand crafted RTEMS 4.11 tool chain is in use.

>
>
> This toolchain was also built to include Ada support (/necessary for
> some of the TASTE code generators that emit Ada code/). Preliminary
> tests seem to work - but we have not performed any extensive testing
> on these parts yet.

If someone cares about Ada, then the next two weeks or so would be a 
good time frame to test it and integrate Ada fixes into RTEMS.

>
>
> In addition to the VM, we are also supplying a Dockerfile ( 
> https://gitrepos.estec.esa.int/taste/taste-setup/blob/master/Dockerfile)
> - allowing you to build a container that has a complete TASTE install
> inside it, built from source.  A Debian chroot is also an option
(see 
> the README in the "taste-setup" repo linked above for details)
- or 
> under Debian-based platforms, a native install.
>
> *The bad news:*
>
> The move to 4.12 is breaking the code related to some TASTE drivers
- 
> we need to e.g. rewrite the code necessary to support SpaceWire as
a 
> communication channel. I recently tried to compile the Gaisler SpW
> examples with 4.12, and saw numerous failures - many defines have
been 
> renamed in the new BSPs, and I understand that the driver model itself
> has changed. A new project is underway where this - and other things
- 
> will hopefully be addressed (/Gaisler is part of the consortium in
it/).

There are too many RTEMS drivers for the Gaisler platforms around in the
wild. It would be good to consolidate this step by step and move the 
drivers to the official RTEMS. Gaisler already integrated their driver
manager and the standard drivers. It makes no sense that every European
space project using RTEMS and Gaisler products uses its own copy and 
paste driver versions.

In case interfaces are missing (e.g. low level hardware access as a 
hypervisor guest, etc.), then we can add them to RTEMS as well.

>
>
> As for signals use, I am not the one behind the Ocarina/POHI 
> middleware - which is the only one that could be doing this - so I
> will ask the Ocarina crew and get back to you.  A quick grep
though 
> shows a 'signal' call in at least one Leon-related TASTE driver used
> by POHI - the ethernet one ( 
> https://gitrepos.estec.esa.int/taste/polyorb-hi-c/blob/master/src/drivers/po_hi_driver_leon_eth.c#L628).

Who sends this SIGPIPE which is ignored here?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@xxxxxxxxxxxxxxxxxx
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.





This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.