Porting to Cortex-R4F - Thesis and GSoC project proposal

[Pavel Pisa]

Hello all,

On Tuesday 18 of March 2014 01:17:06 Gedare Bloom wrote:
> Also, Premysl should start FSF paperwork for submitting patches to
> GCC/binutils. -Gedare

I hope that GCC/FSF paperwork in not necessary.
GCC has strong support for Cortex-R4F, we used it on
this CPU with Artic Core Autosar OS and I have seen
comments form MBED community about sucesfull GCC
use on Cortex-R4 big/endian system.

So I hope that for single target setup GCC and Newlib
should not be a problem. The adaptation for GCC included
RTEMS ARM multilib config is necessary but there
three or four lines could be send by Ralf, Joel
or somebody else with FSF papares signed.

On Tuesday 18 of March 2014 13:40:19 Sebastian Huber wrote:
> Hello Pavel,
> I don't have time to mentor this year.

Thanks for reply and help, I am aware that you
would not menthor for this year.

> > 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.
>
> I only looked briefly at the Cortex-R4, but there is one architecture
> manual for the A and R variants, so I expect that some code of the
> Cortex-A9 BSPs can be re-used.  Has the processor a MMU or only a MPU?

The MCU has only MPU. I expect that most of the code can be reused
with ARMv4 thumb, Cortex-A thumb2 RTEMS support, but I expect that
there can be some differences and obstacles. 

> In case the chip has a network interface, then I think it would be enough
> for a GSoC project.

OK, the chip has ETHERNET support and we have student working
on its support for FreeRTOS. But it was quite hard and support
was newer reliable. I hope and expect that RTEMS stack is much
better and that result will be fully usable under pressure
(We have experienced no problems with RTEMS stack on PPC and LPC). 

The Ti's Hercules / TMS570 family is wide so I hope that work
will be usesfull.

The other more demanding task is implementation of FPU support.
If I know actual RTEMS state, there is no ARM port running
with hard-float setup yet. But I am not sure if it fits
into GSoC scope. I expect that we would work on it and finish
this task if student takes thesis GSoC follow-up.

On the other hand, if there is RTEMS team consensus that proposed
tasks for this BSP class does not worth GSoC slot then student
can offer work on other area. We have there PPC5200 and LPC1788/LPC4088
boards suitable for RTEMS. Because we do not want to limit
student work to emulator only, we would like to stay with these.

Alternative option is some work on LPC4088, i.e. FPU support
for Cortex-M4 which is missing in RTEMS. But Cortex-M4 FPU is
single precision only so it has relatively limited use
for control tasks. It can be interesting for some current
graphic libraries.

As for mentors, is there somebody who can step in? He/she
should be mainly reviewer of students work and even my
consultant role, because I and student are too close for
this role.

All comments, suggestions and even arguments again work
and suggestion to do something else welcomed.

Best wishes,

                Pavel