bsp/tms570: actual state

[Pavel Pisa]

Hello Daniel,

On Thursday 18 of September 2014 18:08:04 Daniel Gutson wrote:
> Hi folks,
>
>     could you please give us an update of the shape of this BSP?
>
> There's a project that uses the TMS570, and I'd like to convince some
> people to move to RTEMS. How far do you consider the BSP is from the
> "industrial" status?
> I don't see much progress details in its wiki, such as stability and
> drivers status.

the project is not ready for industrial grade use yet. I would be carefull
even to use actual RTEMS GIT until it is polished for real 4.11 release.

As for the TMS570 - I am not in a tight contact with Premek now.
Something like two weeks ago he hard worked on proper header files
preparation. But I expect that he need some rest time before semester
start after hard work over holiday now.

I expect that basic TMS570 support will mature till end of the year
during Premek's master thesis work. The final release Q1 2015.

As for the status:

I have run many test from testsuite - the success rate from internal
SRAM is very high (only some capture engine and test with memory
demand above SRAM capacity fails). But there is still some issue
for running from SDRAM and even from Flash which I have managed
to be useable with RTEMS in last weeks. I can upload output on
Wiki or my page if there is interrest.

We need proper automated test suite setup - probably in Python
and for sure with OpenOCD. I have worked on OpenOCD and its TMS570
Flash support so we do not need any Ti/Java/Eclipse tools
for regular RTEMS development now. I look at testing setup
with Premek when he returns.

RTEMS Flash image still runs with initial setup build by Ti tools
and HalCoGen. We expect to include even initial setup code
in RTEMS during next work phase.

But bootloader based startup sequence with RTEMS at some Flash base
offset would be important for many use cases still. I can imagine
that option is to port U-boot to TMS570 to allows Ethernet and TFTP 
RTEMS+application updates. But it is considerable amount of work
which cannot be done in my time constrains. I have colleague who
worked on U-boot for AM3xxx and other Linux systems under his
contracts. But to gain his time, contract/payment for work is required.
So proper solution with boot over bootloader in this case is not
on my free plan now. But if we need some loader in our contracts
paid project I would argue to made it public - but it would be probably
some HalCoGen based hacks in such case.

The RTEMS TMS570 port is running soft float still to keep things
simple till we resolve other problems to not mix them with possible
problems caused by HF. Cortex-R4F HF is prepared by Sebastian in
tools and RTEMS core  and actual switching to HF is a matter one
or two GCC switches in a BSP config. I plan to test that soon.
But not priority in our plan now.

Priority are header files to cover most of peripherals.

We have now proper driver for both serial ports which builds and
works reliably  in interrupt driven and polled mode.
Timer is OK, still fixed tick based but that is normal setup
for RTEMS. Support for subtick time read resolution is there
and we have working CPU support for micro benchmarking with
CPU clock cycle resolution - I am not aware of other
ARM RTEMS BSP with such support.

Ethernet support has been analyzed, we have identified matching
BSD driver code but porting finishing can take some months
(even because project and steps prioritization).

As for my other colleagues work, we probably gain paid project
to deliver industry use ready Matlab/Simulink target support
for TMS570 and RM48. But that will be Ti tools (not RTEMS)
based to fulfill tight time constrains.

 http://rtime.felk.cvut.cz/rpp-tms570/

I dream that there would be RTEMS based version of this support
one day. But that whole project is in scale of many man years
(three of my colleagues worked on it for year, paid students
over two holidays seasons etc.) and it has to pay bills of our
department. So there is minimal chance that RTEMS port happens
and would be supported by budget of our department head if there
is not the contract.

But I hope that solid RTEMS TMS570 support is on its way to
happen in our open/enthusiast activities frame. We would be
happy for all possible kinds of cooperation and testing.
If you can access TMS570LS31x HDK kit, I help you to setup
system to state where we are. You need to build patched
OpenOCD, Linux host preferred - I never used it on Windows,
same even for Ti tools. Toolchain is available as x86 64-bit
packages or regular mainline sources. SDRAM setup code is on GitHub
and I provide compiled binary too.

If your customer wants to have industrial ready system
till end of year than I would answer that RTEMS is no
solution if you or they do not plan to invest significant
time or money to the project. If they want to build platform
for future applications and expect to start final application
development about end of year with product testing at start
of Q2 2015, then RTEMS should become ready on base of our
interrest/work investment. Anyway, for real grade target
project, they (in house), you, OAR, Embedded Brains or somebody
else has to take care about the platform, its testing,
certification, professional grade support etc.

Best wishes,


              Pavel