TMS570 BSP status - update

Mon Aug 1 21:15:01 UTC 2016

Hello Florian and others,

I have invested some time to BSP to move work forward.
Changes integrated into mainline

  bsp/tms570: include package balls and PINMMR registers mapping for TMS570LS3135ZWT chip.
  bsp/tms570: include complete peripheral initialization to SCI driver.

These changes are required to do full chip initialization when there is
no loaded/startup code

  bsp/tms570: ensure that change of SCI baudrate is not applied in the middle of character Tx.

This has been nasty bug which I have hunted for long time because
it lead to stuck in RTEMS startup sometimes (caused by overlap of previous
printf overlap with shell startup tcset).

To run RTEMS as the first stage application on the board,
hardware initialization is required. It is quite complex
and I have not found time and courage to do it only from
documentation. There are some not so well documented
errata workaround sequences in HalCoGen generated code.

So one option is to use complete HalCoGen generated files,
solution for RTEMS 4.11 can be found in the branch

  https://github.com/AoLaD/rtems/tree/tms570-bsp-with-hwinit

which is enabled by TMS570_USE_HALCOGEN_STARTUP=1 configure option.
This is not mainline material. I can put the stub there if others
like that, but not hat HalCogen mix with Autosar stubs etc.

Other option for selftest and startup is to work on cleaned
and minimized code. I have it published it in tms570-bsp
branch which is RETMS mainline (4.12) based code

  https://github.com/AoLaD/rtems/tree/tms570-bsp

My configuration used for testing

../../../tms570/rtems/configure  --target=arm-rtems4.12 --prefix=/opt/rtems4.12 \
  --enable-rtems-inlines --disable-multiprocessing --enable-cxx \
  --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
  --disable-networking --enable-posix --enable-itron --disable-ada \
  --disable-expada --disable-multilib --disable-docs \
  --enable-rtemsbsp="tms570ls3137_hdk" \
  --enable-rtems-debug \
  TMS570_USE_HWINIT_STARTUP=1

The actual code in question is there

  https://github.com/AoLaD/rtems/tree/tms570-bsp/c/src/lib/libbsp/arm/tms570/hwinit

It is quite recent HalCoGen based code (latest versions are BSD-like licensed)
which has been heavily rewritten to use our complete header files. The most
of hardcoded hexadecimal numbers has been replaced by field names to allow
me minimize code and understand its function. Some parts are commented out
or missing still, for example MIBSPI peripherals local RAM parity errors
detection checking and state synchronization, internal SRAM ECC functionality
check, MPU and SDRAM setup and checks as well as error reporting system cehcking
and setup. This means that access to some uninitialized peripherals can lead
to exception etc. But ticker and some of our rtems-omk-template including shell
and lwIP port runs from Flash.

If the actual code is considered to be acceptable for mainline,
I can push it. But to make is clean I expect that something
like one or two man months would be required.

I have no project backup for this work so I cannot say if I find time
to continue work on BSP. I am sure that at university is almost zero
chance that I would be allowed to ask somebody from academic stuff
to help with this without project. May it be, some diploma thesis
is possible without project but we have not enough good students
for our project backed activities at this time.

We have XCP[1] Flash loader over ETHERNET (based on Ti tools only ..)
for TMS570LS3137 pushed forward recently. It uses actual lwIP version.
It has got to good shape now. But that work has been paid from our university
department budget to students/colleagues. I would be happy if it can be clean
from our other paid project infrastructure and open-sourced but something/
somebody has to pay the work before open-sourcing is allowed
by university.

As for the EPICS, I would like to have time to test it.
I spotted it many many years ago already when I started with RTEMS.
I have even thought that it would be nice to integrate
EPICS support into some of our motion and robotic controllers
directly. For example in our FPGA and LPC40xx based RoCoN
which can run RTEMS

  http://pikron.com/pages/products/motion_control/lx_rocon.html

But that is below line of my TODO list.

On Monday 27 of June 2016 16:09:26 Florian Feldbauer wrote:
> >> Later our goal is to run EPICS [1] on the MCU. But for this we need to
> >> downgrade to
> >> RTEMS 4.10
> >
> > I wouldn't advise you to go back too much. The 4.10 tag was made about
> > 5 years ago. The 4.11 branch on the other hand has a somewhat stable
> > version where only bug-fixes are pushed. If you absolutely need to go
> > back, I'd check exactly at which point did EPICS stop working and use
> > the commit before that.
> >
> > Do you have any clue on why EPICS doesn't work with newer RTEMS versions?
>
> No. My best guess would be, that they kept to the saying
> "Never change a running system"...The bug report for this problem is
> dated to end of May this year....

Porting to RTEMS 4.10 is probably possible but I would consider
that as lost of time for me so even if it is paid I would
request double price. It would be really huge task because
RTEMS-4.10 doe not include any Cortex based ARM BSP, really
any no M, A or R so backporting would be really huge effort.

So I would look for alternative solution. Invest to move
EPICS to be compatible with newer RTEMS. We have experience
(at the company) with keeping complex application compatible
with RTEMS from RTEMS-4.6 days and we have to keep actual
code compatible with 4.9 and 4.10 due to certification
and updates. But it compiles with minimal changes
and ifdefs with mainline too.

So if there is interrest, I see no problem to work on backport
of recent TMS570 BSP state to 4.11 but 4.10 is really
big and useless task.

As for EPICS, do you consider to use ETHERNET.
We have lwIP for TMS570. If only internal memory
is used then it is on the edge and can be problem
with more complex/more connections. And lwIP
is not seamlessly integrated with RTEMS file
descriptors yet. Other my TODO.
We have not TMS570 EMAC driver ported to classic
RTEMS network stack and have not considered that till now.
As for BSD stack, it cannot fit in internal SRAM
and external SDRAM is quite slow on TMS570LS3137.
There would be big difference on TMS570LC4357
which has cache. But that is another item for TODO
or some other contributors to put hands on.

Best wishes,

        Pavel

[1] XCP Universal Measurement and Calibration Protocol
    https://en.wikipedia.org/wiki/XCP_%28protocol%29
--
                Pavel Pisa
    e-mail:     pisa at cmp.felk.cvut.cz
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/