[OpenBIOS] Solaris anyone?

Artyom Tarasenko atar4qemu at gmail.com
Wed Apr 27 18:31:23 CEST 2011


On Tue, Apr 26, 2011 at 9:53 PM, Paul Brook <paul at codesourcery.com> wrote:
>> Hm. Fast/wide and synchronous should be no problem (unless there are
>> certain timings expected).
>
> Fast should be a non-issue.  Wide may be a problem if we get odd sized
> transfers wrong.  IIUC wide transfers are initiated by the target (disk) and
> qemu never does this, so should not be a problem either.

After a bit experimenting it turend out that I was wrong about
synchronous. This seems to be the problem.
The comment in the OpenSolaris esp driver
http://src.opensolaris.org/source/xref/xen-gate/onnv-3.4/usr/src/uts/sun/io/scsi/adapters/esp.c#3463
also explains one reason why:

/*
* Set up to send synch. negotiating message.  This is getting
* a bit tricky as we dma out the identify message and
 * send the other messages via the fifo buffer.
*/

Looks like the qemu esp doesn't support mixing dma/fifo messages.

>> Tagged command is a bigger issue, since afaik none of QEMU's HBAs support
>> it.
>
> Other QEMU HBAs (LSI53C895A) do support tagged command queueing, however the
> ESP does not.
>
> By my reading qemu esp emulation is missing proper handling of MESSAGE phases.
> It assumes only a single IDENTIFY byte is sent, probably interpreting
> subsequent SIMPLE queue tags as the start of the command block.
> Implementing full command queueing is fairly tricky.  However a stub
> implementation that accepts the tag but avoids disconnecting (force sequential
> execution of commands) should be somewhat simpler.

This seems to be necessary too because the OpenSolaris driver seems to
use at least two tags:

esp->e_cur_msgout[i++] = sp->cmd_tag[0];
esp->e_cur_msgout[i++] = sp->cmd_tag[1];


Artyom

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/



More information about the OpenBIOS mailing list