[GSoC] RTEMS Tester Improvements

[Tanu Hari Dixit]

Thank you for the reply, Joel. I have edited my proposal to include
gem5 as of now. If time will permit, I will look into Skyeye.

Thanks,
Tanu Hari Dixit.

On Sat, Apr 1, 2017 at 8:13 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Apr 1, 2017 8:12 AM, "Tanu Hari Dixit" <tokencolour at gmail.com> wrote:
>
> Hello Chris, All,
>
> I have added PyYAML as the tool I'll be using to parse the yml files
> in my proposal. Thank you for clearing that. Can you please look at
> the proposal and give comments on the methods I have proposed to solve
> the various problems? (In particular the "Proposed Schedule" section).
>
> I had questions regarding the simulator recipes that need to be
> supported in rtems-tester and I would be grateful if they are
> answered.
>
> The listed bsps are those that are supported by sim-scripts and not
> rtems-tester:
>
> Blackfin/bf537Stamp support on skyeye
> ARM/CSB337 support on skyeye
> MIPS/CSB350 support on skyeye
> M68K-Coldfire/CSB360
> ARM/EDB7312 support on skyeye
> Blackfin/ezkit533 support on skyeye
> ARM/Gumstix support on skyeye
> SPARC/LEON2 support on skyeye
> ARM/RTL22xx support on skyeye
> ARM/SMDK2410 support on skyeye
> arm/lm3s6965 support on qemu
> i386/pc386 support on qemu
> ARM/GumStix Connex support on qemu
> SPARC/LEON2 support on qemu
> lm32/lm32_evr support on qemu
> OpenRISC/or1k support on or1ksim
> PowerPC/QemuPPC support on qemu
> arm/realview_pbx_a9_qemu_smp support on qemu
> m68k/uc5282 support on qemu
>
>
> I see a bf537Stamp-skyeye.in in sim-scripts but I don't see it listed
> in https://devel.rtems.org/wiki/Developer/Simulators/SkyEye. Also
> couldn't find ARM/Gumstix and ARM/SMDK2410 listed there. Are these
> configurations supported? Should I be adding support for these?
>
>
> 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.
>
> 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.
>
>
>
>
> It is given on the same web-page that arm/csb337 will run hello.exe
> and ticker.exe on Skyeye. Would it be worth adding support for this
> bsp if they can run a few tests only?
> It is written that RTEMS BSP Csb350 should work once support in Skyeye
> comes further along. What does this indicate?
>
>
> That we we're hopeful. :(
>
>
> Are these the simulator recipes that the devs wanted to see in
> rtems-tester (other than for running RTEMS on gem5  for sparc64/usiii
> and arm/realview_pbx_a9_qemu BSPs) ? Should I be focusing on a few
> relevant ones? If so, which ones are more important?
>
>
> 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.
>
> 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.
>
>
> Thank you,
> Tanu Hari Dixit.
>
> On Mon, Mar 27, 2017 at 6:37 AM, Chris Johns <chrisj at rtems.org> wrote:
>> On 27/03/2017 04:34, Tanu Hari Dixit wrote:
>>>
>>> Also, do you suggest against using PyYAML to parse .yml configuration
>>> files (since that will add a dependency into rtems-tester)?
>>
>>
>> PyYAML might be perfect for the task. We will need to find a suitable
>> solution as part of the change to Yaml. The YAML support maybe added to
>> the
>> rtemstoolkit.
>>
>> Chris
>
>