<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 10:55 PM, Tim Ansell <span dir="ltr"><<a href="mailto:mithro@mithis.com" target="_blank">mithro@mithis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>  * 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?<br></div><div><br></div></div></blockquote></span></div></div></div></blockquote><div><br></div></span><div>The reasons for us currently choose the lm32 soft-cpu over the or1k soft-cpu where;</div><div> * lm32 doesn't require patching gcc</div><div> * lm32 is slightly smaller in resource requirements than the or1k</div><div> * lm32 is the default option in MiSoC :)</div><div> </div><div>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.</div><div><br></div></div></div></div></blockquote><div>The or1k gcc situation is (politely) less than ideal. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div></div></blockquote></span><div>I can speak of or1k.</div></div></div></div></blockquote><div><br></div><div>Can I ask what your relationship to it is? Where you the GSoC student who did the port previously?</div><div> </div></div></div></div></blockquote><div>Yes. It is Hesham's port. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 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. </div></div></div></div></blockquote><div><br></div><div>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 :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The generic_or1k BSP includes basic device drivers support for UART console (I/O) and clock driver. <br></div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div><div>As FPGAs are pretty configurable, any idea how to handle the fact the BSP isn't really all that stable?</div><div><br></div><div>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?</div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The project seems interesting to me given that it's an open-source hardware platform. <br></div></div></div></div></blockquote><div><br></div><div>Interested enough to help with mentoring such a project? :P</div><div><br></div></div></div></div></blockquote><div><br></div><div>I don't know that we have anyone active who qualifies as am lm32 expert. It was </div><div>ported by Jukka Pietarinen about eight years ago. Michael Walle and Yann Sionneau</div><div>have done lm32 specific fixes to it since them. Most RTEMS core developers have</div><div>touched the lm32 port as part of regular maintenance though.</div><div><br></div><div>It looks like the lm32_evr BSP is supposed to run on the simulator in gdb. The</div><div>rtems-testing git repository has a script to help use that in sim-scripts.  Because </div><div>it is a gdb simulator, I added support for the new automated testing framework</div><div>in rtems-tools git repo.  But I don't remember any test results off hand. So baselining</div><div>the current situation would be useful as a starting point.</div><div><br></div><div>For general RTEMS advice/mentoring, there are multiple people technically</div><div>capable of helping. But for lm32 specific knowledge, we would need to</div><div>try to contact the original authors or learn.</div><div><br></div><div>Is there (or will there be) a simulator for your board? Am I right in understanding</div><div>that the FPGA image will be available for use by anyone interested?</div><div><br></div><div>How is debugging done? If JTAG, what HW assist?</div><div><br></div><div>Does RTEMS run on this now? Just trying to see what all is involved. Not being</div><div>negative.</div><div><br></div><div>I can't volunteer for the community but I am likely willing to help. </div><div><br></div><div>--joel</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Tim 'mithro' Ansell</div></div></div></div>
<br>_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br></blockquote></div><br></div></div>