<div dir="ltr">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! </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-26 22:25 GMT+02:00 Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe the rtems-test is finding a different version of the compiled hello.exe?<br>
<div><div class="h5"><br>
On Thu, Jun 26, 2014 at 4:02 PM, Krzysztof Mięsowicz<br>
<<a href="mailto:krzysztof.miesowicz@gmail.com">krzysztof.miesowicz@gmail.com</a>> wrote:<br>
> I had it configured with BSP_PRESS_KEY_FOR_RESET=0, but I will try it once<br>
> again. It seems like a problem with execute module - when running qemu<br>
> simply from command line it works properly, only when running through<br>
> rtems-test it waits for key. Maybe Chris would know why this happens?<br>
><br>
><br>
> 2014-06-26 20:09 GMT+02:00 Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>:<br>
><br>
>><br>
>> On 6/26/2014 12:53 PM, Krzysztof Mięsowicz wrote:<br>
>><br>
>> I checked this behaviour more, and it seems that when I run test through<br>
>> rtems-test command and it invokes this qemu-system-i386.... command through<br>
>> execute module, it waits after test completion for key press. When I'm<br>
>> starting qemu-system-i386... simply from command line or through shell<br>
>> script, it works fine.<br>
>><br>
>> See pc386/<a href="http://configure.ac" target="_blank">configure.ac</a> for this<br>
>><br>
>> RTEMS_BSP_CLEANUP_OPTIONS(1, 1)<br>
>><br>
>> dnl argument 1 indicates the default value for BSP_PRESS_KEY_FOR_RESET<br>
>> dnl argument 2 indicates the default value for BSP_RESET_BOARD_AT_EXIT<br>
>><br>
>> Sounds like the default should change or the test build needs to pass<br>
>> in BSP_PRESS_KEY_FOR_RESET=0.<br>
>><br>
>> --joel<br>
>><br>
>><br>
>><br>
>> 2014-06-26 18:37 GMT+02:00 Krzysztof Mięsowicz<br>
>> <<a href="mailto:krzysztof.miesowicz@gmail.com">krzysztof.miesowicz@gmail.com</a>>:<br>
>>>><br>
>>>> Awesome! Does this work without the -hdb? Just curious what it is<br>
>>>> used for. If it can be avoided, then one less option and user setup<br>
>>>> requirement.<br>
>>><br>
>>><br>
>>> I suppose the answer is yes. Hdb is second hard drive where it looks for<br>
>>> grub.cfg file. When I will be sure about grub.cfg file content I will move<br>
>>> it to grub.cfg inside rtems-boot.img, and then it should be possible to<br>
>>> eliminate -hdb option.<br>
>>><br>
>>> I encountered another problem. After creation of <a href="http://pc386.mc" target="_blank">pc386.mc</a> file in bsps<br>
>>> directory of rtems-tester I was able to run rtems-test. I see that qemu is<br>
>>> invoked (however when I type "ps -e | grep qemu" in another console process<br>
>>> name seems to be cutted: qemu-system-i38 (should be i386) ), but after all<br>
>>> tests are hanging. I tried to invoke command as seen in log and I got such<br>
>>> result:<br>
>>><br>
>>> >> qemu-system-i386 -no-reboot -monitor null -serial stdio -nographic -m<br>
>>> >> 128 -boot b -hda /home/rtems/qemu/hdtest/rtems-boot.img -hdb<br>
>>> >> fat:/home/rtems/qemu/hdtest -append "--console=com1;boot;" -kernel<br>
>>> >> /home/rtems/development/rtems/b-pc386/i386-rtems4.11/c/pc386/testsuites/samples/hello/hello.exe<br>
>>><br>
>>><br>
>>> *** BEGIN OF TEST HELLO WORLD ***<br>
>>> Hello World<br>
>>> *** END OF TEST HELLO WORLD ***<br>
>>><br>
>>> EXECUTIVE SHUTDOWN! Any key to reboot...<br>
>>><br>
>>> So it looks like qemu is waiting for entering some key to finish<br>
>>> execution. This is strange to me, as it finishes without such input when<br>
>>> above command is in bash script. So when I put this command in bash script<br>
>>> and simply execute it, test goes easily and finishes cleanly without need to<br>
>>> enter any key.<br>
>>><br>
>>> Have you encountered such problem earlier? Or maybe you have idea how<br>
>>> this should be solved?<br>
>>><br>
>>><br>
>>> 2014-06-26 0:54 GMT+02:00 Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>:<br>
>>><br>
>>>><br>
>>>> On 6/25/2014 5:48 PM, Chris Johns wrote:<br>
>>>> > On 26/06/2014 5:56 am, Krzysztof Mięsowicz wrote:<br>
>>>> >> Hi again and sorry for spam. Soon after writing mail to you I found<br>
>>>> >> the<br>
>>>> >> solution (at least I think so :-D ).<br>
>>>> > Thanks for posting the solution. The pc is the only qemu bsp I know of<br>
>>>> > with a boot loader making it more complex.<br>
>>>> ><br>
>>>> >> I created rtems-boot.img using script from<br>
>>>> >> <a href="http://www.rtems.org/wiki/index.php/Building_Grub" target="_blank">http://www.rtems.org/wiki/index.php/Building_Grub</a> .<br>
>>>> >> I wrote grub.cfg with following lines:<br>
>>>> >><br>
>>>> >> serial --unit=0 --speed=115200<br>
>>>> >> set root='hd1,msdos1'<br>
>>>> >> terminal_output serial; terminal_input serial;<br>
>>>> >><br>
>>>> >> to redirect terminal output and input to serial. Then, I am able to<br>
>>>> >> run<br>
>>>> >> arbitrary executable using following command (example for ticker):<br>
>>>> >><br>
>>>> >> qemu-system-i386 -m 128 -boot b -hda $HOME/qemu/hd/rtems-boot.img<br>
>>>> >> -hdb<br>
>>>> >> fat:$HOME/qemu/hd -serial stdio -no-reboot -nographic -monitor null<br>
>>>> >> --exec-trace ticker.exe.cov -kernel<br>
>>>> >><br>
>>>> >> /home/rtems/development/rtems/src/b-pc386/i386-rtems4.11/c/pc386/testsuites/samples/ticker/ticker.exe<br>
>>>> >> -append "--console=com1;boot"<br>
>>>> > This is an excellent solution. Well done.<br>
>>>> Awesome! Does this work without the -hdb? Just curious what it is<br>
>>>> used for. If it can be avoided, then one less option and user setup<br>
>>>> requirement.<br>
>>>> >> This simply boots executable specified as -kernel argument and<br>
>>>> >> appends<br>
>>>> >> --console=com1;boot to grub multiboot specification. This results in<br>
>>>> >> following output:<br>
>>>> >><br>
>>>> >> *** BEGIN OF TEST CLOCK TICK ***<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988<br>
>>>> >> TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988<br>
>>>> >> TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988<br>
>>>> >> TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988<br>
>>>> >> TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988<br>
>>>> >> TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988<br>
>>>> >> TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988<br>
>>>> >> TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988<br>
>>>> >> TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988<br>
>>>> >> *** END OF TEST CLOCK TICK ***<br>
>>>> >><br>
>>>> >> Additionaly, ticker.exe.cov is created. I think this is really good<br>
>>>> >> soultion to use in coverage analysis within rtems-test. The question<br>
>>>> >> is<br>
>>>> >> where rtems-boot.img and grub.cfg should be placed?<br>
>>>> >><br>
>>>> > I agree this is the way to go. Please send me the rtems-test patch<br>
>>>> > without the coverage option so I can add this bsp to the supported<br>
>>>> > test<br>
>>>> > bsps. We can add the coverage option in further changes once we have<br>
>>>> > detecting a suitable qemu figured out.<br>
>>>> +1<br>
>>>> > Chris<br>
>>>><br>
>>>> --<br>
>>>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>>>> joel.sherrill@OARcorp.com On-Line Applications Research<br>
>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>>>> Support Available <a href="tel:%28256%29%20722-9985" value="+12567229985">(256) 722-9985</a><br>
>>>><br>
>>><br>
>><br>
>><br>
>> --<br>
>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>> joel.sherrill@OARcorp.com On-Line Applications Research<br>
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>> Support Available <a href="tel:%28256%29%20722-9985" value="+12567229985">(256) 722-9985</a><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div><br></div>