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
