Rtems-test with qemu integration for pc386

[Krzysztof Mięsowicz]

>
> 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/8492ca16/attachment-0002.html>