Porting to Cortex-R4F - Thesis and GSoC project proposal

[Gedare Bloom]

Also, Premysl should start FSF paperwork for submitting patches to GCC/binutils.
-Gedare

On Sun, Mar 16, 2014 at 8:30 PM, Gedare Bloom <gedare at rtems.org> wrote:
> 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.
>
> -Gedare
>
>> 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