On Mon, Nov 5, 2012 at 11:42 AM, Elvis Dowson
<elvis.dowson@xxxxxxxxx> wrote:
Hi Joel,
On Nov 5, 2012, at 9:22 PM, Joel Sherrill <
joel.sherrill@xxxxxxxxx> wrote:
> Speaking from an RTEMS perspective, the various *BSD trees are great
> sources for driver code that should be licensed appropriately for Pok.
>
> It is also possible that the RTEMS source tree would be able to offer some
> help here.
RTEMS support for arm processors and adapt it for POK.
http://git.rtems.org/rtems/tree/cpukit/score/cpu/arm
It would provide some help. Not all but a starting point.
> Just depends on what ARM SoC you are looking at. Getting even the
> basics in with a COM port would be a great addition.
The CPU is an ARM Cortex A9 processor, which implements the
armv7a architecture. I need to check if it implements the optional
divide instructions.
I have to admit that I am not an ARM expert. I am the RTEMS maintainer
and depend on others to handle the horrific number of ARM variants.
If you are interested, join the rtems-users or rtems-devel mailing list
and see what answers folks give.
I believe that one GSOC project even worked on some basic MMU support
which might prove useful.
Which processor platforms was RTEMS ported to:
- TI OMAP 3530 (ARM Cortex A8)
- TI OMAP 4430 (ARM Cotex A9)
If one of those is the BeagleBoard, then a student did at least a partial
BSP for GSOC.
I've got both these platforms with me, but i was thinking of trying a port
with the Freescale i.MX 6 quad core platform (ARM Cortex A9).
Getting the first core up on any of those would be a good challenge.
But leveraging driver code, context switch, etc from other projects
would reduce it to filling in pieces.
Moving Pok to Multicore would require feedback from Julien on the
challenges.
--joel
Best regards,
Elvis Dowson