Rtems-test with qemu integration for pc386
Krzysztof Mięsowicz
krzysztof.miesowicz at gmail.com
Thu Jun 26 20:59:30 UTC 2014
Gedare, thank you! This was it... I have wrong path to specified hello.exe
when invoking rtems-test... - to another build of rtems with another
config. Now, when pointing to proper rtems build, it is working!
2014-06-26 22:25 GMT+02:00 Gedare Bloom <gedare at rtems.org>:
> Maybe the rtems-test is finding a different version of the compiled
> hello.exe?
>
> On Thu, Jun 26, 2014 at 4:02 PM, Krzysztof Mięsowicz
> <krzysztof.miesowicz at gmail.com> wrote:
> > 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
> >>>>
> >>>
> >>
> >>
> >> --
> >> 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
> >
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140626/48ef9059/attachment.html>
More information about the devel
mailing list