Rtems-test with qemu integration for pc386

Thu Jun 26 20:02:11 UTC 2014

I had it configured with BSP_PRESS_KEY_FOR_RESET=0, but I will try it once
again. It seems like a problem with execute module - when running qemu
simply from command line it works properly, only when running through
rtems-test it waits for key. Maybe Chris would know why this happens?

2014-06-26 20:09 GMT+02:00 Joel Sherrill <joel.sherrill at oarcorp.com>:

>
> 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>:
>
>>  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 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>:
>>
>>
>>> 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 <%28256%29%20722-9985>
>>>
>>>
>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Developmentjoel.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/bd4fa479/attachment-0002.html>