testing pc386 with qemu?

[Chris Johns]

On 20/06/2016 10:34, Pavel Pisa wrote:
> Hello Chris,
>
> On Monday 20 of June 2016 01:58:09 Chris Johns wrote:
>> On 20/06/2016 09:08, Joel Sherrill wrote:
>>> Does this append to the boot arguments?
>>
>> Yes.
>>
>>> If so, shouldn't it be /dev/com1? Or did you fix that Chris to work both
>>> ways on the master?
>>
>> Yes. I noticed this after I sent the email. The doco in the wiki is
>> correct ...
>>
>> https://devel.rtems.org/wiki/Developer/Simulators/QEMU#BootinganRTEMSexecut
>> abledirectlywithqemu
>
> I have not looked into code but I have feeling that
>
>    --console=com1

I do not think it actually works so maybe a BSPTOPS default is working.

>
> worked for me. Is there support for both or only
>
>    --console=/dev/com1 is p
>
> is guaranteed now?
>

The support removed pre-pending '/dev' to the device names so now the 
command line option and the '/dev' directory match. This also means the 
command line and the entries in the console device tables match. I do 
not expect any further changes.

I made the change to clean up the code when sorting out the legacy and 
PCI uart support when used with the GDB stub support. The gdb stub 
previously did not support the PCI UARTS. You now have --gdb=/dev/com2 
or --gdb=/dev/pcicom1 plus --gdb-break for running on real-hardware (I 
know qemu has gdb support built in). We may also have other devices in 
the future, for example the UEFI API has console and device interfaces 
which I see as being useful and may become available when support is 
added. On the Minnow Max board you can direct the UEFI console to a UART 
making the board headless and I see RTEMS's UEFI support having it's 
console use the UEFI console. This is important for target testing.

> As for my usual options
>
>    -net nic,vlan=0,model=e1000 -net user,vlan=0
>
> I have feeling that they are incorrect for RTEMS because
> I have found e1000 PCI support only in some PowerPC RTME BSP.

You may be correct.

> So the line should be changed to something which
> is supported by current RTEMS.

OK. If something knows a command that works please let me know.

Chris