<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">Awesome! Does this work without the -hdb? Just curious what it is<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">used for. If it can be avoided, then one less option and user setup<br></span><span style="font-family:arial,sans-serif;font-size:13px">requirement.</span></blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>I encountered another problem. After creation of <a href="http://pc386.mc">pc386.mc</a> 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:</div>
<div><br></div><div><div>>> 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</div>
<div><br></div><div><br></div><div>*** BEGIN OF TEST HELLO WORLD ***</div><div>Hello World</div><div>*** END OF TEST HELLO WORLD ***</div><div><br></div><div>EXECUTIVE SHUTDOWN! Any key to reboot...</div><div><br></div></div>
<div>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. </div>
<div><br></div><div>Have you encountered such problem earlier? Or maybe you have idea how this should be solved?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-26 0:54 GMT+02:00 Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><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 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 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 -hdb<br>
>> fat:$HOME/qemu/hd -serial stdio -no-reboot -nographic -monitor null<br>
>> --exec-trace ticker.exe.cov -kernel<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>
</div>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>
<div><div class="h5">>> This simply boots executable specified as -kernel argument and 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 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 test<br>
> bsps. We can add the coverage option in further changes once we have<br>
> detecting a suitable qemu figured out.<br>
</div></div>+1<br>
> Chris<br>
<span class="HOEnZb"><font color="#888888"><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>
</font></span></blockquote></div><br></div>