GSoC2016 organisation collaboration? RTEMS on FPGA hardware running MiSoC

[Tim Ansell]

On 10 March 2016 at 02:34, Joel Sherrill <joel at rtems.org> wrote:

> On Tue, Mar 8, 2016 at 10:55 PM, Tim Ansell <mithro at mithis.com> wrote:
>
>>   * 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.
>>
>
>>
> The or1k gcc situation is (politely) less than ideal.
>

Sadly yes :(

It does look like the situation for or1k LLVM / Clang is in a better state?
Can RTEMS be compiled with clang?

Interested enough to help with mentoring such a project? :P
>>
>
> I don't know that we have anyone active who qualifies as am lm32 expert.
> It was
> ported by Jukka Pietarinen about eight years ago. Michael Walle and Yann
> Sionneau
> have done lm32 specific fixes to it since them. Most RTEMS core developers
> have
> touched the lm32 port as part of regular maintenance though.
>

Yann Sionneau hangs out on the #m-labs channel that I also frequent (and
the channel for developers of the MiSoC system which we use) -- I've also
added him on the CC here.


> It looks like the lm32_evr BSP is supposed to run on the simulator in gdb.
> The
> rtems-testing git repository has a script to help use that in
> sim-scripts.  Because
> it is a gdb simulator, I added support for the new automated testing
> framework
> in rtems-tools git repo.  But I don't remember any test results off hand.
> So baselining
> the current situation would be useful as a starting point.
>

I'm unsure what you mean here? Are you suggesting running the tests and
seeing if they pass (and fixing ones that don't)?


> For general RTEMS advice/mentoring, there are multiple people technically
> capable of helping. But for lm32 specific knowledge, we would need to
> try to contact the original authors or learn.
>
> Is there (or will there be) a simulator for your board? Am I right in
> understanding
> that the FPGA image will be available for use by anyone interested?
>

We don't really have any simulator set up at the moment. It is something we
need to investigate further. We have an open issue at (
https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/86) to look
into using QEMU's lm32 support for simulation. Florent (from enjoy-digital)
also suggested we might be able to use verilator for that.

The firmware running on the FPGA is fully open source (and available at
https://github.com/timvideos/HDMI2USB-misoc-firmware). We have prebuilt
versions available at
https://github.com/timvideos/HDMI2USB-firmware-prebuilt but is probably
only useful for people with hardware.

I always try to find a way to get people doing development hardware they
need to make progress.

How is debugging done? If JTAG, what HW assist?
>

Test simulation of the hardware is one way and testing directly on the
hardware is another.

JTAG and printf on the UART :)


> Does RTEMS run on this now? Just trying to see what all is involved. Not
> being
> negative.
>

That is part of the question I'm trying to figure out :-). I don't really
know much about RTEMS.


> I can't volunteer for the community but I am likely willing to help.
>
> --joel
>

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