rtems from TMS570 SDRAM or INTRAM

[Pavel Pisa]

Hello Mr. Ahmed Asif,

On Tuesday 14 of February 2017 09:19:07 AHMED, Asif wrote:
> Hello Mr. Sebastian Huber and everyone,
>
> Thank you for your help. I could make the rtems application (rtems-app.exe)
> for big endian tms570. Now that I have got the steps right, I would like to
> make simple rtems application for the board I have, which is TMS570lc4357
> HDK which contains arm cortex-r5 processor. That's why I wanted to get the
> basic tms570ls3137 application right. I have read that It is possible to
> use TMS570ls3137_hdk_sdram or TMS570ls3137_hdk_intram configuration while
> the when board is setup by
> https://github.com/hornmich/tms570ls3137-hdk-sdram initialization code in
> the Flash. I would like to start from there so that I can initialize my
> TMS570lc4357 HDK board using TI's HALCoGen. I have checked that lc4357 and
> ls3137 both the boards use same ISSI 442S16400F SDRAM CHIP. It would be a
> great help if you could guide me to steps to follow. I have created one
> sdram_sci_configuration ccs project for my lc4357 board similar to that
> link and changed the linker cmd file of bsp. I can do the bsp clock and
> other simple changes. But I am not sure how to integrate rtems application
> or what to do next? What should be my next step to keep the initialization
> in the flash and run rtems application from intram or sdram?

I would start first with links to TMS570 RTMES resources where I have tried
to track and collect our knowledge and achievements of my work with
Czech Technical University students on RTEMS port for TMS570.

I am sending copy to Nikolay Komashinskiy who expresses interrest to work
on target during this year GSoC to coordinate effort and knowledge base.

There is page in RTEMS wiki

  https://devel.rtems.org/wiki/TBR/BSP/Tms570

There are some remarks about debugging on the page

  https://devel.rtems.org/wiki/Debugging/OpenOCD/TMS570

more hardware remarks and stuff related to our actually
used development kit boards and our own board developed
as CPU test for one prime carmaker can be found
on our university local page

  https://rtime.felk.cvut.cz/hw/index.php/TMS570LS3137

The recapitulation of the BSP state and things which worth
to be done. The initial porting of RTEMS to TMS570
has been done by Premysl Houdek, my GSoC and then diploma
thesis student. The work repository there

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

He is now even employed at our inivesity
group (http://industrialinformatics.cz/) but all his
duties as employee at university are not related to TMS570,
he works on autonomous driving with future Nvidia ARM chips.

All valuable TMS570 results of his work and my further
enhancements has been included in RTEMS mainline.
So RTEMS mainline is the right start point.

The BSP can be build in multiple variants. If the basic
Flash start at zero address variant (tms570ls3137_hdk)
is build with TMS570_USE_HWINIT_STARTUP=1 configure option
than all code to bring-up all RTEMS supported peripherals
on TMS570LS3137 is included. The optional initialization
code is based on HalCoGen generated code but it has
been allmost completely rewritten to make it more readable,
allow to use same algorithms for chip with different sets
of peripherals etc. My longer term plan/dream is to support
TMS570LC4357 and evensome RM48 chips from the same code
base. The idea is to use common codebase, ideally even
the prebuild BSP and only select actually integrated
set of peripherals by tables provided by application
configuration. See how parity self test is implemented
to allow select peripherals to test by single table

  https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/hwinit/tms570_selftest_parity.c

The same for default pins functions setup which can
be modified if user application provides own
tms570_pinmux_init() function and pins functions list
using include for given chip/application variant. See

  https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c

I think that state of integrated HW initialization
is in good shape for all peripherals except for SDRAM
init where I have some issues and have not time to
find the problem. Actual init is one to one to HalCoGen
code but there are issues for first invocation after
power up reset. The initialization is correct for subsequent
ones and I have not any time to llok at this more.
Strange is that the same code in separate initialization
build by Ti CCS compiler from HalCoGen sources

  https://github.com/hornmich/tms570ls3137-hdk-sdram

works correctly. It is even more surprising because
their (Ti) original code does not use volatile and other
mechanisms to ensure correct compilation and CPU memory
barriers so according to C memory ordering standards it
is only coincidence that it works at all.

There are even other options how to load and run
RTEMS application image on TMS570.

1) Simple HW initialization and jumping to the RTEMS
or loading of application by JTAG. This has been
mode for the most of the RTEMS BSP development.
We used setup code which ends in the infinite loop

  https://github.com/hornmich/tms570ls3137-hdk-sdram

and then used OpenOCD to load (tms570ls3137_hdk_sdram)
application to SDRAM or for short tests internal RAM
(tms570ls3137_hdk_intram).

2) Use of XCP (automotive standard) FLASH loader and
boot code. The code is based on minimal FreeRTOS
application and allows to load application into Flash
or with small changes even into SDRAM by tool over
ETHERNET (TCP/IP, LwIP based). Code has been developed
by my coolegues at university as future step or our
large paid project.

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

I would be very happy if boot loader part of that code can
be opensourced but there is significant work and money
investment by my our group and and conditions of such support
has to be negotiated with our group head.

3) Direct integration of HalCoGen code to the RTEMS application.
I have done this experiment and pushed it to Premek's/our
TMS570 test repository (tms570-bsp-with-hwinit)

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

This is only interesting code in that repository which
has not been included in mainline. I can imagine that stub for
this option can be included in mainline after some more cleanups
but I am personally against pushing any HalCoGen single board/configuration
hardcoded generated code into maniline. But it can be used for fast
start or some company hacked non portable application.

We implemented ETHERNET driver and ported LwIP to TMS570.
The port of LwIP is part of our other project

  https://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/

I think that working on LwIP integration is the must
for RTEMS for memory constrained targets. The BSD based
networking stack does not fit into 3 MB of Flash,
external RAM is slow on TMS570LS3137 and there is no
chance to run BSD stack with less than 2 or 4 MB of Flash.
There is my analysis how to make LwIP the first class citizen
of RTEMS

  https://devel.rtems.org/wiki/Packages/LWIP

The LwIP can be used without this but you cannot use fprintf
and other file handle related functions with it when not integrated.
Use of lwip_socket, lwip_read etc is required for now.

As for the TMS570LC4357, this chip matches RTEMS nicely.
It has large enough Flash and RAM for many applications and even
external SDRAM memory can provide usable bandwidth thanks to the
cache addition.

Texas Instruments have donated me one this board and it is
on my long list of task in the category would be nice to
do or waits for some paid project at university or company
which would enhance priority of that work.

I have thought about future compatibility with TMS570LC4357 during
most of my TMS570 work and even done some preparation steps.
The code for pin multiplexer included in RTEMS mainline is prepared
for new style with separated innput and output switching matrix
found on TMS570LC4357. Even tools for parsing of Ti's manuals
and preparation of TMS570 BSP pins matrix description are prepared
for this setup

  https://github.com/AoLaD/rtems-tms570-utils/tree/master/headers/terminals-pins

and I have tuned manual parsing and have prepared RTEMS pinmux
compatible experimental/untested headers on my computer.
I can push this WIP on tms570lc4357-pins.h file into mainline
if there is negotiated how next steps for TMS570 BSP
are coordinated and results tested.

It would worth to prepare equivalent of

 https://github.com/hornmich/tms570ls3137-hdk-sdram/tree/master/SDRAM_SCI_configuration

for TMS570LC4357 . I would prefer GCC based in this case.
I have not tested if I can use my OpenOCD based tools for TMS570LC4357
chip directly or if it requires more development. Unfortunately
my enhancements required for OpenOCD to allow Flashing and debugging
of SDRAM applications are based on Andrey Smirnov OpenOCD branch
which has not been accepted to mainline. So if the code cannot work
with TMS570LC4357 as is then priority to invest time for rewrite
into shape which is potentionally acceptable for OpenOCD mainline
is even more important. As for TMS570LS3137, you should be warned
that chip revisions older than D have CPU core implementation
flaws which can cause problems when code is executed from external
SDRAM or SDRAM is used for ETHERNET buffers. I expect that there are
no such problems with TMS570LC4357.

Best wishes,

Pavel

PS: as for my availability, I am quite busy by teaching (lectures, seminaries,
courses coordination) and Zynq and other targets related work now.
I hope to have more time after summer exam period ends in June.
I am asked to provide consultation on-site abroad for some
company this week when not teaching so expect even more delays
in replies now.