Rtems-test with qemu integration for pc386

[Krzysztof Mięsowicz]

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.


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140626/847b9d76/attachment-0002.html>