Porting to Cortex-R4F - Thesis and GSoC project proposal

Gedare Bloom gedare at rtems.org
Mon Mar 17 00:30:58 UTC 2014

Hi Pavel,
Hopefully Sebastian may comment as he is most familiar with ARM, but
here are my two cents:

On Sun, Mar 16, 2014 at 7:40 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello everybody,
> we have a student (Premysl Houdek) who has interrest
> in ARM based embedded systems. He has long term experience
> with Cotex-M LPC based boards.
> He has not used RTEMS yet but he likes idea to test it,
> work on it and eventually use it in applications.
Have him do the GSOC getting started ASAP if he hopes to participate.

> We have discussed possible summer and thesis projects
> and his preference is to try port RTEMS to Cortex-R4F /
> Ti's TMS570LS3137 . Advantage is that we have some boards
> based on this chip left at our university office from
> previous projects, we have already implemented support
> for CAN, FlexRay and other peripherals with use of
> Ti CCS and included rudimentary OS and we would be happy
> to test RTEMS as more complete operating system running
> on the HW.
> Other, more important reason for Cortex-R4 is that
> it is one of not so many safety enhanced CPUs.
> TMS570LS3137 includes two cores in lockstep mode with
> hardware differences comparison, full ECC SRAM and Flash
> and all peripherals registers and memories equipped
> by parity bits.
> There is not much MCUs which provide such setup.
> There are more such PowerPC based systems and there
> are much more expensive special chips for aerospace
> and space applications. But Ti's TMS570 and Hercules
> families are relatively new and some of these chips
> are quite affordable. RTEMS targets same/similar range
> of applications as these chips so I think there is
> good match.
All this sounds good.

> My question:
> What is opinion of RTEMS development coordinators,
> do you suggest to open that task for GSoC application
> and student proposal evaluation?
On the surface, a new BSP is not usually going to be enough for GSoC,
unless it requires some modifications due to instruction-set
differences at the architecture level. If R4 requires some different
assembly code for context-switch and interrupt handling than what
exists already, then there could be enough work to cover the summer.
That said, including support for the cache management and MMU/MPU (if
one exists) can also be proposed as optional time-fillers, or some
other peripherals.

> If yes, then who is willing to be menthor/reviewer?
> I expect to be co-menthor or consultant. There are
We would find a mentor, and let you be a co-mentor, if it would get accepted.

> more other people at our department who already
> finished thesis or project related to given HW, so there
> is knowledge base for work. There is high chance that
> student would continue on project because he consider
> to choose it as diploma thesis and so final state should
> be very well documented and integrated at the end.
> As for the GSoC period, I expect next goals
>  - basic test and toolchain configuration
>      non-multilib version for Cortex-R4 big-endian should
>      not be problem for GCC
>  - documented patch for addition of the variant into multilib
>  - checking which conditional blocks in RTEMS ARM SCORE
>    sources best match architecture and providing patch
>    to select appropriate SCORE support.
>  - extensions of SCORE (task switch and interrupts) to support
>    the architecture
>  - implementation of serial port driver - ideally interrupt driven
Clock driver should be accomplished also.

> Then other peripheral support can be implemented during diploma
> thesis period, including basic CAN and FlexRay support. Porting
> of our Matlab/Simuling Embedded Coder target base environment
> to RTEMS POSIX or RTEMS specific API should be reachable as well.
> More about related project for actual used OS there
>   http://rtime.felk.cvut.cz/rpp-tms570/
> More about MCU there
>   http://rtime.felk.cvut.cz/hw/index.php/TMS570LS3137
> The concrete board design is owned by carmaker which
> contracted us to do the design for new potential MCU platform
> suitability test. But we have some code originally running
> on Ti's evaluation kit. It was broken during other diploma
> thesis but I expect that we can get another one from Ti
> so we should provide even BSP variant for HW which has
> full public documentation and is available from Ti.
It is necessary to provide the BSP variant for the available board. I
am not interested in funding development of BSPs for non-public
boards. Is there any possible simulator targets that can be considered
for this project? RTEMS Project should have some way to test the code
especially for SCORE additions.


> Thanks for reply or ideas even for different project
> in advance.
> Best wishes,
>                 Pavel Pisa
>     e-mail:     pisa at cmp.felk.cvut.cz
>     www:        http://cmp.felk.cvut.cz/~pisa
>     university: http://dce.fel.cvut.cz/
> PS: I am on yet another exhibition (Amper in Brno) next week
>     so my response can lag some days

More information about the devel mailing list