<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 11:02 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 10 March 2016 at 02:34, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</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>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><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></div></div></blockquote></span></div></div></div></blockquote><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 class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote></span></div></div></div></blockquote><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 or1k gcc situation is (politely) less than ideal. </div></div></div></div></blockquote><div><br></div></span><div>Sadly yes :(</div><div><br></div><div>It does look like the situation for or1k LLVM / Clang is in a better state? Can RTEMS be compiled with clang?</div><span class=""><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"><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 class="gmail_extra"><div class="gmail_quote"><div>Interested enough to help with mentoring such a project? :P</div></div></div></div></blockquote><div><br></div></span><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></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>Great! If Yann is willing to mentor, it would be great!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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"><div>It looks like the lm32_evr BSP is supposed to run on the simulator in gdb. The<br></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></div></div></blockquote><div><br></div></span><div>I'm unsure what you mean here? Are you suggesting running the tests and seeing if they pass (and fixing ones that don't)?</div><span class=""><div> </div></span></div></div></div></blockquote><div>I just meant that I hadn't personally run any tests on the lm32 recently so had no idea</div><div>if it worked. I just checked the lm32 on the simulator in gdb and it seems to be working.</div><div>So there are no obvious fundamental issues to worry about before any "real work"</div><div>can occur.</div><div><br></div><div>FWIW the simulator in gdb is very slow and some of the tests I tried ran too long but</div><div>when I broke in gdb, they were making progress. If we don't have "fast idle for</div><div>simulator" mode turned on for the gdb BSP variant, we need to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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"><div>For general RTEMS advice/mentoring, there are multiple people technically<br></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></div></div></blockquote><div> </div></span><div>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 (<a href="https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/86" target="_blank">https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/86</a>) 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.</div><div><br></div><div>The firmware running on the FPGA is fully open source (and available at <a href="https://github.com/timvideos/HDMI2USB-misoc-firmware" target="_blank">https://github.com/timvideos/HDMI2USB-misoc-firmware</a>). We have prebuilt versions available at <a href="https://github.com/timvideos/HDMI2USB-firmware-prebuilt" target="_blank">https://github.com/timvideos/HDMI2USB-firmware-prebuilt</a> but is probably only useful for people with hardware.</div><div> <br></div><div>I always try to find a way to get people doing development hardware they need to make progress.</div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>This sounds great and was what I was looking for.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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>How is debugging done? If JTAG, what HW assist?<br></div></div></div></div></blockquote><div><br></div></span><div>Test simulation of the hardware is one way and testing directly on the hardware is another.</div><div><br></div><div>JTAG and printf on the UART :)</div><span class=""><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></div><div>Does RTEMS run on this now? Just trying to see what all is involved. Not being<br></div><div>negative.</div></div></div></div></blockquote><div><br></div></span><div>That is part of the question I'm trying to figure out :-). I don't really know much about RTEMS.</div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>It sounds like you need a Board Support Package for your SoC. I expect that</div><div>some of the code can be reused from the milkymist with the sharing preferably </div><div>by moving source to a proper shareable location. We don't encourage direct</div><div>copying from one BSP to another. It makes maintenance harder.</div><div><br></div><div>A BSP is the crt0 code, linker script, console driver, clock tick driver, etc. It</div><div>is not beyond a GSoC project to develop this and more. Especially if the</div><div>SoC is similar to existing lm32 BSPs we have.</div><div><br></div><div>--joel</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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"><div>I can't volunteer for the community but I am likely willing to help. <br></div><span><font color="#888888"><div><br></div><div>--joel</div></font></span></div></div></div></blockquote><div><br></div><div>Tim 'mithro' Ansell</div></span></div></div></div>
</blockquote></div><br></div></div>