GSoC2016 organisation collaboration? RTEMS on FPGA hardware running MiSoC

[Tim Ansell]

>
>   * It looks like RTEMS already has support for both the lm32 and or1k CPU
>> architectures (from looking at cpukit/score/cpu?). Is there a way to find
>> out the current "state" of these ports and how far along / what
>> functionality might be missing?
>>
>>
The reasons for us currently choose the lm32 soft-cpu over the or1k
soft-cpu where;
 * lm32 doesn't require patching gcc
 * lm32 is slightly smaller in resource requirements than the or1k
 * lm32 is the default option in MiSoC :)

The big risk for us if we went with the or1k is that the student has to
initially get our old firmware running on that architecture before other
work can proceed. In theory this should be pretty trivial but I can see it
consuming more time then we expect.

I can speak of or1k.
>

Can I ask what your relationship to it is? Where you the GSoC student who
did the port previously?


> The current BSP (SoC) is generic. It runs on or1ksim, QEMU and Atlys FPGA
> board (including the or1k FuseSoC, formerly orpsoc3 with or1200 core). The
> cpukit/score/cpu includes the shared ISA code. The BSP/board code lies on
> c/src/lib/libbsp/or1k. I read that Milkymist runs on XC6SLX45 Spartan-6
> FPGA which is the same as on the Atlys board.
>

Our firmware actually supports both the Digilent Atlys and the Numato Opsis
boards. The Numato Opsis board is very similar in design to the Atlys
board, but is actually FOSS hardware. It would be awesome if more people
doing or1k work where using the Opsis boards instead of the Atlys :)

The generic_or1k BSP includes basic device drivers support for UART console
> (I/O) and clock driver.
>
> If you considered or1k (as an architecture), your project will most likely
> be a new BSP (like generic_or1k) with more new device drivers for your SoC,
> and you can get the benefits of the other RTEMS target-independent
> libraries/features.
>

As FPGAs are pretty configurable, any idea how to handle the fact the BSP
isn't really all that stable?

I'm guessing we probably want the "components drivers" for things like the
HDMI frame buffers, Ethernet interfaces "upstream" and then generate a BSP
based on the actual configuration? IE If it has 2 HDMI frame buffers, we
should instantiate 2 copies of the driver or something?


> The project seems interesting to me given that it's an open-source
> hardware platform.
>

Interested enough to help with mentoring such a project? :P

Tim 'mithro' Ansell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160309/6638e83a/attachment.html>