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-0001.html>


More information about the devel mailing list