TMS570LC43x - what should be done before coding
pisa at cmp.felk.cvut.cz
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
There is significant difference in the pin multiplexer but that should
be covered by the code already included in RTEMS. It should support
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
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
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
clone the tools repository and try to adapt files in the JSON form if you need
to add one or two fields
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
* you should to check startup code stub at
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
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.
More information about the devel