Re: [Qemu-devel] [5706] Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier).

[andrzej zaborowski]

Hi,

2008/11/25 Ryan Harper <address@hidden>:
> * Ryan Harper <address@hidden> [2008-11-24 17:19]:
>> * Ryan Harper <address@hidden> [2008-11-24 17:12]:
>> > * Andrzej Zaborowski <address@hidden> [2008-11-12 10:50]:
>> > > Revision: 5706
>> > >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5706
>> > > Author:   balrog
>> > > Date:     2008-11-12 16:41:32 +0000 (Wed, 12 Nov 2008)
>> > >
>> > > Log Message:
>> > > -----------
>> > > Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier).
>> > >
>> > > After going through the debug log and scratching my head for quite some
>> > > time. I found the following:
>> > >
>> > > The problem was with this block move:
>> > >
>> > > lsi_scsi: SCRIPTS dsp=0fae8e50 opcode 01000028 arg 00f63c40
>> > > lsi_scsi: DMA addr=0x00f63c40 len=36
>> > >
>> > > The number of bytes to be transferred (len) should be 40 which 
>> > > corresponds
>> > > to the block transfer of length 0x28 (from opcode 01000028). Instead we
>> > > have a length of 36 (0x24). The code responsible for this is (in
>> > > 'lsi_do_dma'):
>> > >
>> > > if (count > s->current_dma_len)
>> > >    count = s->current_dma_len;
>> > >
>> > > Basically we're overwriting the length 40 with the value 36 which I
>> > > think we just left over in that variable from an earlier transfer. In my
>> > > patch below I initialize s->current_dma_len to s->dbc before we begin
>> > > the DMA transfer during Data In phase.
>> > >
>> > > The attached patch gets Openserver 5.0.5 past the hardware detection
>> > > (and it lists the hard drive to boot, woohoo). It appears to stop a
>> > > little while later (doesn't seem SCSI related), but it's been so long 
>> > > since
>> > > I've booted Openserver I'm not sure what's supposted to happen after the 
>> > > HW
>> > > detection using the boot/root disks.
>> > >
>> > > Props go to Craig Ringer for the initial post and the code that he posted
>> > > some of which is in this patch.
>> >
>> > This patch breaks WinXP SP3 32-bit install to scsi device.  After
>> > attempting to format a partition on the scsi device, Windows says there
>> > is an error formating the partition.  If I revert the patch, formating
>> > and installation to a scsi disk works ok.

Laurent Desnogues also found an issue with SCSI under versatilepb
(ARM) and narrowed it down to the addition of the line

 s->current_dma_len = s->dbc;

He let me know about it on IRC, sorry for not telling the list until
now.  I haven't yet had time to dig into the problem but I emailed the
author of the patch and he found something interesting, see below.

>> >
>> > I haven't dug into what part of the patch is breaking it just yet, but
>> > plan to do so.
>>
>> Looks like dropping this line gets the install working again:
>
> That isn't it.  Actually, dropping the dma len update fixes it 100% of
> the time.
>
> -            s->current_dma_len = s->dbc;

I'm afraid that works because it largely nullifies the effect of the
patch, so it's like reverting it.

Justin Chevrier who came up with the original patch, also looked into
the issue with versatilepb and proposed the following temporary
workaround:
--- hw/lsi53c895a.c     (revision 5781)
+++ hw/lsi53c895a.c     (working copy)
@@ -920,7 +920,8 @@
            break;
        case PHASE_DI:
            s->waiting = 2;
-            s->current_dma_len = s->dbc;
+            if (!(insn & (1 << 28))) /* TIA Hack */
+                s->current_dma_len = s->dbc;
            lsi_do_dma(s, 0);
            if (s->waiting)
                s->waiting = 3;

He noticed that the patch uncovered an endiannes issue somewhere in
lsi53c895a.c due to which the comparison that we added doesn't work on
some target/host pairs.  This is the issue that should be fixed next.

Cheers