Re: TMS570LC43x - what should be done before coding

[Pavel Pisa]

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
>
>  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 

Re: TMS570LC43x - what should be done before coding

[Gedare Bloom]

On Fri, May 19, 2017 at 12:19 PM, Nikolay Komashinskiy
 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 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.
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.

> 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.

>
>
> ---
> Regards,
> Nikolay Komashinskiy
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

TMS570LC43x - what should be done before coding

[Nikolay Komashinskiy]

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).

Also, LC43X has only MibSPI which is extended version of SPI.
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? 



---
Regards,
Nikolay Komashinskiy
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel