<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Apr 1, 2017 8:12 AM, "Tanu Hari Dixit" <<a href="mailto:tokencolour@gmail.com">tokencolour@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Chris, All,<br>
<br>
I have added PyYAML as the tool I'll be using to parse the yml files<br>
in my proposal. Thank you for clearing that. Can you please look at<br>
the proposal and give comments on the methods I have proposed to solve<br>
the various problems? (In particular the "Proposed Schedule" section).<br>
<br>
I had questions regarding the simulator recipes that need to be<br>
supported in rtems-tester and I would be grateful if they are<br>
answered.<br>
<br>
The listed bsps are those that are supported by sim-scripts and not<br>
rtems-tester:<br>
<br>
Blackfin/bf537Stamp support on skyeye<br>
ARM/CSB337 support on skyeye<br>
MIPS/CSB350 support on skyeye<br>
M68K-Coldfire/CSB360<br>
ARM/EDB7312 support on skyeye<br>
Blackfin/ezkit533 support on skyeye<br>
ARM/Gumstix support on skyeye<br>
SPARC/LEON2 support on skyeye<br>
ARM/RTL22xx support on skyeye<br>
ARM/SMDK2410 support on skyeye<br>
arm/lm3s6965 support on qemu<br>
i386/pc386 support on qemu<br>
ARM/GumStix Connex support on qemu<br>
SPARC/LEON2 support on qemu<br>
lm32/lm32_evr support on qemu<br>
OpenRISC/or1k support on or1ksim<br>
PowerPC/QemuPPC support on qemu<br>
arm/realview_pbx_a9_qemu_smp support on qemu<br>
m68k/uc5282 support on qemu<br>
<br>
<br>
I see a bf537Stamp-skyeye.in in sim-scripts but I don't see it listed<br>
in <a href="https://devel.rtems.org/wiki/Developer/Simulators/SkyEye" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>Developer/Simulators/SkyEye</a>. Also<br>
couldn't find ARM/Gumstix and ARM/SMDK2410 listed there. Are these<br>
configurations supported? Should I be adding support for these?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Skyeye is a sad project to me. They had a lot of functionality and ran a number of RTEMS BSPs. Then they undertook an overly ambitious rearchitecting and seem to have killed the project.</div><div dir="auto"><br></div><div dir="auto">It might be worth checking the status of skyeye to see if it improved but I wouldn't put it anywhere near your critical path or put a lot of time in it. It may be that RTEMS needs to make a decision that we use old releases or simply abandon it if the current source is broken and the project inactive.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br>
It is given on the same web-page that arm/csb337 will run hello.exe<br>
and ticker.exe on Skyeye. Would it be worth adding support for this<br>
bsp if they can run a few tests only?<br>
It is written that RTEMS BSP Csb350 should work once support in Skyeye<br>
comes further along. What does this indicate?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">That we we're hopeful. :(</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Are these the simulator recipes that the devs wanted to see in<br>
rtems-tester (other than for running RTEMS on gem5  for sparc64/usiii<br>
and arm/realview_pbx_a9_qemu BSPs) ? Should I be focusing on a few<br>
relevant ones? If so, which ones are more important?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">The uc5282 had working networking at one point. In general ai would say assess and don't waste time doing more than that on any specific BSPs. Focus on the ones that work to improve the overall capabilities. If we know which BSPs need work, we can nibble at known BSP specific issues. </div><div dir="auto"><br></div><div dir="auto">I hope this helps. It would be better to have high rtems-tester functionality​ on a few BSPs than to get hung up on BSP specific issues. We just need them recorded with tickets.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
Thank you,<br>
Tanu Hari Dixit.<br>
<br>
</div><div class="elided-text">On Mon, Mar 27, 2017 at 6:37 AM, Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br>
> On 27/03/2017 04:34, Tanu Hari Dixit wrote:<br>
>><br>
>> Also, do you suggest against using PyYAML to parse .yml configuration<br>
>> files (since that will add a dependency into rtems-tester)?<br>
><br>
><br>
> PyYAML might be perfect for the task. We will need to find a suitable<br>
> solution as part of the change to Yaml. The YAML support maybe added to the<br>
> rtemstoolkit.<br>
><br>
> Chris<br>
</div></blockquote></div><br></div></div></div>