Rtems-test with qemu integration for pc386

Gedare Bloom gedare at rtems.org
Thu Jun 26 20:25:58 UTC 2014 

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

More information about the devel mailing list