TMS570LC43x - what should be done before coding

Thu May 25 09:30:14 UTC 2017

Hello Nikolay and Gedare,

On Monday 22 of May 2017 17:03:34 Gedare Bloom wrote:
> On Fri, May 19, 2017 at 12:19 PM, Nikolay Komashinskiy
>
> <nikolay.komashinskiy at yandex.ru> wrote:
> > Hello,
> >
> > I've started to investigate how to launch RTEMS on top of the TMS570LC43x
> > processor and it seems that some additional work should be done.
> >
> > I can't understand to what extent HalCoGen should be used. It seem these
> > two processors (TMS570LC43x and TMS570LS3731) differ in their memory
> > maps, in caches (LC43x has it).

yes, I have warned that differences are significant in the past
and that if SPI and I2C is not developed on TMS570LS3137 that
there is necessary porting to TMS570LC43x. On the other hand,
TMS570LC43x is really perspective RTEMS target.

Actual peripherals should be be compatible. The peripherals
differences (except system and PLL/clock controllion ones) should
be only in the direction that TMS570LC43x can have some additional
bits.

There is significant difference in the pin multiplexer but that should
be covered by the code already included in RTEMS. It should support
both concepts.

On the other hand, it is possible to start from the point where
low level initialization is done by "loader"/stub application
and RTEMS is compiled without HW init or RTEMS start with HalCoGen
generated init. I expect that in such setup only minor adjustment
to VIM and peripheral base addresses should enable to
run TMS570 BSP on the TMS570LC43x target with serial output.

> Yes we need to make the determination of how to use HalCoGen. I'm not
> sure if I prefer to include HalCoGen generated code in the git
> repository, or just to document how an end user should add the
> HalCoGen files themselves. I think I prefer to include the generated
> files, since it is then easier to quality control.
>
> > Also, LC43X has only MibSPI which is extended version of SPI.

It should not be a problem, TMS570LS3137 has MibSPI chanel as well.

> Does this mean the driver framework we have in cpukit/dev/spi cannot
> be used? In this case the SPI driver will have to be developed from
> scratch as part of the BSP.

I need to recheck, but I think that SPIs are the very similar
to AM3/4/5 ones so at least BSD and Linux drivers can be used
for inspiration. It should not be a problem to fit all this
to Linux like API.

> > Also, these boards have a bit different Vector Interrupt Managers
> > (different number of interrupts).
> >
> > Could you explain what should be done in order to get a working RTEMS
> > port on top of the board?
>
> First get the console to work. Console + one context switch = hello
> world. So the first step is to get hello world to work properly.

The steps to do and confirm by feedback:

 * use RTEMS Source Builder to prepare toolchain (GCC etc) for mainline
   master RTEMS build

 * build TMS570 BSP for example by RSB to test toolchain but I suggest
   to not continue this way further, use direct build from GIT for next steps

 * prepare your GitHub personal fork of RTEMS https://github.com/RTEMS/rtems
   learn how to build BSP from it, I have set of build directories with
   different configuration side-by GIT sources directory to can rebuild
   easily RTEMS after modifications for more target without full rebuild.
   Lear how "bootstrap -c", "bootstrap" and "bootstrap -p" works when you
   do more substantial changes

 * grant me (GitHub "ppisa") write access to your repo to simplify
   some corrections and communication. I can pus some experimental code
   from my repo there

 * check that critical peripherals definition matches register description
   in the TMS570LC43xx manual

       https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/include/ti_herc

   Start with reg_sci.h, reg_spi.h, reg_i2c.h, reg_gio.h, reg_vim.h which are
   listed in the priority order.
 * check peripherals bases/memory map in

      https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/include/tms570.h

   we should add define for TMS570LC43x and decide how to resolve differences.
   One option is to move map to tms570-regmap-ls3137.h and left tms570.h include
   the right one according to the selected chip, other option is to conditionalize
   these entries which are different between versions. I have obtained information
   from Ti support that they strive to allocate peripherals location and registers
   such way in the Hercules line, that they generally are only present or
   missing in the given address range but do not move and latest version
   registers definition should be usable for all older versions if fields
   unimplemented on older ones are not used. But it should be checked and there
   can be exceptions. I would prefer when fields, registers and peripherals
   missing on LS31 and introduced on LC43 are conditionalized to easily
   find incompatibility if BSP is build for older chips. Silent write to
   unimplemented bits and use of unimplemented features is a problem.

 * if you find differences in c/src/lib/libbsp/arm/tms570/include/ti_herc
   files and need to adapt them, try to that systematic way. We have generated
   all these files by scripts and tools "make all.bat", "make_header.py" etc.
   found in "headers/python"  directories

      https://github.com/AoLaD/rtems-tms570-utils

   clone the tools repository and try to adapt files in the JSON form if you need
   to add one or two fields

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

   if there is more differences then the mechanism to run comparison automatically
   is required. Our registers descriptions files has been obtained hard way
   by parsing PDFs due to unclear licences status at that days. Files generated
   by HalCoGen are correctly licensed now. On the other hand I think that files
   generated from our tools are following better form used by RTEMS (reference
   is mainly other modern RTEMS ports started or updated by Sebastian Huber).
   HalCoGen headers quite often lacks definition of masks for peripherals
   fields etc. The has been worse than what we have for sure in the past and they
   often differ in registers names and fields names for same peripheral
   between different family members. At least that has been situation one
   or two years ago. May it be that it has been improved since then.

   Anyway, I consider as optimal solution to use HalCoGen or CCS debugger XML
   definitions of registers and their fields as the source to generate
   Hercules family wide well matching header files for RTEMS.

   I plan to contact/speak with Ti representatives I have communicated
   in the past and check if they support and confirm that we can use this
   approach.

 * you should to check startup code stub at 

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

   try to use CCS to populate simple application which setups as much
   as possible peripherals on your board then prints something to serial
   port and waits in the infinite loop. Try to use GCC option for the
   code generation. But even application compiled by Ti compiler
   counts when runs well on your target. It has to be without operating
   system and interrupts enabled. Prepare repo with this application.
   It should be easy copy required files to the RTEMS and use it in
   that HalCoGen assisted mode to run simple shell demo.

Use your GSoC project Wiki page to maintain some TODO list and sumarise
your achievements and problems

  https://devel.rtems.org/wiki/GSoC/2017/TMS570_BSP_improvements

It may be possible Trac issue tracking system to organize
and prioritize work. But how and under which categories should
such points fall should be discussed with Gedare and others.

Best wishes,

Pavel Pisa