Rtems-test with qemu integration for pc386
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Jun 26 18:09:46 UTC 2014
On 6/26/2014 12:53 PM, Krzysztof Mięsowicz wrote:
> I checked this behaviour more, and it seems that when I run test
> through rtems-test command and it invokes this qemu-system-i386....
> command through execute module, it waits after test completion for key
> press. When I'm starting qemu-system-i386... simply from command line
> or through shell script, it works fine.
>
See pc386/configure.ac for this
RTEMS_BSP_CLEANUP_OPTIONS(1, 1)
dnl argument 1 indicates the default value for BSP_PRESS_KEY_FOR_RESET
dnl argument 2 indicates the default value for BSP_RESET_BOARD_AT_EXIT
Sounds like the default should change or the test build needs to pass
in BSP_PRESS_KEY_FOR_RESET=0.
--joel
>
> 2014-06-26 18:37 GMT+02:00 Krzysztof Mięsowicz
> <krzysztof.miesowicz at gmail.com <mailto:krzysztof.miesowicz at gmail.com>>:
>
> Awesome! Does this work without the -hdb? Just curious what it is
> used for. If it can be avoided, then one less option and user
> setup
> requirement.
>
>
> I suppose the answer is yes. Hdb is second hard drive where it
> looks for grub.cfg file. When I will be sure about grub.cfg file
> content I will move it to grub.cfg inside rtems-boot.img, and then
> it should be possible to eliminate -hdb option.
>
> I encountered another problem. After creation of pc386.mc
> <http://pc386.mc> file in bsps directory of rtems-tester I was
> able to run rtems-test. I see that qemu is invoked (however when I
> type "ps -e | grep qemu" in another console process name seems to
> be cutted: qemu-system-i38 (should be i386) ), but after all tests
> are hanging. I tried to invoke command as seen in log and I got
> such result:
>
> >> qemu-system-i386 -no-reboot -monitor null -serial stdio
> -nographic -m 128 -boot b -hda
> /home/rtems/qemu/hdtest/rtems-boot.img -hdb
> fat:/home/rtems/qemu/hdtest -append "--console=com1;boot;" -kernel
> /home/rtems/development/rtems/b-pc386/i386-rtems4.11/c/pc386/testsuites/samples/hello/hello.exe
>
>
> *** BEGIN OF TEST HELLO WORLD ***
> Hello World
> *** END OF TEST HELLO WORLD ***
>
> EXECUTIVE SHUTDOWN! Any key to reboot...
>
> So it looks like qemu is waiting for entering some key to finish
> execution. This is strange to me, as it finishes without such
> input when above command is in bash script. So when I put this
> command in bash script and simply execute it, test goes easily and
> finishes cleanly without need to enter any key.
>
> Have you encountered such problem earlier? Or maybe you have idea
> how this should be solved?
>
>
> 2014-06-26 0:54 GMT+02:00 Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at oarcorp.com>>:
>
>
> On 6/25/2014 5:48 PM, Chris Johns wrote:
> > On 26/06/2014 5:56 am, Krzysztof Mięsowicz wrote:
> >> Hi again and sorry for spam. Soon after writing mail to you
> I found the
> >> solution (at least I think so :-D ).
> > Thanks for posting the solution. The pc is the only qemu bsp
> I know of
> > with a boot loader making it more complex.
> >
> >> I created rtems-boot.img using script from
> >> http://www.rtems.org/wiki/index.php/Building_Grub .
> >> I wrote grub.cfg with following lines:
> >>
> >> serial --unit=0 --speed=115200
> >> set root='hd1,msdos1'
> >> terminal_output serial; terminal_input serial;
> >>
> >> to redirect terminal output and input to serial. Then, I am
> able to run
> >> arbitrary executable using following command (example for
> ticker):
> >>
> >> qemu-system-i386 -m 128 -boot b -hda
> $HOME/qemu/hd/rtems-boot.img -hdb
> >> fat:$HOME/qemu/hd -serial stdio -no-reboot -nographic
> -monitor null
> >> --exec-trace ticker.exe.cov -kernel
> >>
> /home/rtems/development/rtems/src/b-pc386/i386-rtems4.11/c/pc386/testsuites/samples/ticker/ticker.exe
> >> -append "--console=com1;boot"
> > This is an excellent solution. Well done.
> Awesome! Does this work without the -hdb? Just curious what it is
> used for. If it can be avoided, then one less option and user
> setup
> requirement.
> >> This simply boots executable specified as -kernel argument
> and appends
> >> --console=com1;boot to grub multiboot specification. This
> results in
> >> following output:
> >>
> >> *** BEGIN OF TEST CLOCK TICK ***
> >> TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988
> >> TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
> >> TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988
> >> TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988
> >> TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988
> >> TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988
> >> TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988
> >> TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988
> >> TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988
> >> TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988
> >> TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988
> >> TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988
> >> TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988
> >> TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988
> >> *** END OF TEST CLOCK TICK ***
> >>
> >> Additionaly, ticker.exe.cov is created. I think this is
> really good
> >> soultion to use in coverage analysis within rtems-test. The
> question is
> >> where rtems-boot.img and grub.cfg should be placed?
> >>
> > I agree this is the way to go. Please send me the rtems-test
> patch
> > without the coverage option so I can add this bsp to the
> supported test
> > bsps. We can add the coverage option in further changes once
> we have
> > detecting a suitable qemu figured out.
> +1
> > Chris
>
> --
> Joel Sherrill, Ph.D. Director of Research &
> Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
> <tel:%28256%29%20722-9985>
>
>
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140626/08e2cd00/attachment-0002.html>
More information about the devel
mailing list