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 <j...@rtems.org> wrote: > > > On Apr 1, 2017 8:12 AM, "Tanu Hari Dixit" <tokencol...@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 <chr...@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 > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel