Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

Hey again,

I realized that my patch was malformed (diffing the wrong way). Here it is again, hopefully in a usable format. Sorry for the confusion.

--- lsi53c895a.c	2008-11-04 08:28:18.000000000 -0500
+++ lsi53c895a.c.final	2008-11-04 08:28:40.000000000 -0500
@@ -209,6 +209,7 @@
     uint8_t mbox0;
     uint8_t mbox1;
     uint8_t dfifo;
+    uint8_t ctest2;
     uint8_t ctest3;
     uint8_t ctest4;
     uint8_t ctest5;
@@ -280,6 +281,7 @@
     s->mbox0 = 0;
     s->mbox1 = 0;
     s->dfifo = 0;
+    s->ctest2 = 0;
     s->ctest3 = 0;
     s->ctest4 = 0;
     s->ctest5 = 0;
@@ -890,6 +892,7 @@
             break;
         case PHASE_DI:
             s->waiting = 2;
+            s->current_dma_len = s->dbc;
             lsi_do_dma(s, 0);
             if (s->waiting)
                 s->waiting = 3;
@@ -1279,7 +1282,7 @@
     case 0x19: /* CTEST1 */
         return 0;
     case 0x1a: /* CTEST2 */
-        tmp = LSI_CTEST2_DACK | LSI_CTEST2_CM;
+        tmp = s->ctest2 | LSI_CTEST2_DACK | LSI_CTEST2_CM;
         if (s->istat0 & LSI_ISTAT0_SIGP) {
             s->istat0 &= ~LSI_ISTAT0_SIGP;
             tmp |= LSI_CTEST2_SIGP;
@@ -1327,6 +1330,8 @@
         s->sist1 = 0;
         lsi_update_irq(s);
         return tmp;
+    case 0x46: /* MACNTL */
+        return 0x0f;
     case 0x47: /* GPCNTL0 */
         return 0x0f;
     case 0x48: /* STIME0 */
@@ -1440,6 +1445,9 @@
            SCRIPTS register move instructions are.  */
         s->sfbr = val;
         break;
+    case 0x0a: case 0x0b: 
+        /* Openserver writes to these readonly registers on startup */
+	return;    
     case 0x0c: case 0x0d: case 0x0e: case 0x0f:
         /* Linux writes to these readonly registers on startup.  */
         return;
@@ -1469,6 +1477,9 @@
     case 0x17: /* MBOX1 */
         s->mbox1 = val;
         break;
+    case 0x1a: /* CTEST2 */
+	s->ctest2 = val & LSI_CTEST2_PCICIE;
+	break;
     case 0x1b: /* CTEST3 */
         s->ctest3 = val & 0x0f;
         break;
@@ -1869,12 +1880,21 @@
         return NULL;
     }
 
+    /* PCI Vendor ID (word) */
     s->pci_dev.config[0x00] = 0x00;
     s->pci_dev.config[0x01] = 0x10;
+    /* PCI device ID (word) */
     s->pci_dev.config[0x02] = 0x12;
     s->pci_dev.config[0x03] = 0x00;
+    /* PCI base class code */
     s->pci_dev.config[0x0b] = 0x01;
-    s->pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */
+    /* PCI subsystem ID */
+    s->pci_dev.config[0x2e] = 0x00;
+    s->pci_dev.config[0x2f] = 0x10;
+    /* PCI latency timer = 255 */
+    s->pci_dev.config[0x0d] = 0xff;
+    /* Interrupt pin 1 */
+    s->pci_dev.config[0x3d] = 0x01;
 
     s->mmio_io_addr = cpu_register_io_memory(0, lsi_mmio_readfn,
                                              lsi_mmio_writefn, s);



      

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

Justin Chevrier wrote:
> Hey again,
> 
> I realized that my patch was malformed (diffing the wrong way). Here it is again, hopefully in a usable format. Sorry for the confusion.

OK, I had a chance to test your patch - correctly, this time.

It gets a lot further into detection but on my 5.0.5 system still fails at:

lsi_scsi: SCRIPTS dsp=f20021ec opcode 88080000 arg f000ff53
lsi_scsi: Call 0xf000ff53
lsi_scsi: SCRIPTS dsp=f000ff53 opcode ff0720ff arg ff0720ff
lsi_scsi: Load reg 0x7 size 7 addr 0x000720ff = 00000000
lsi_scsi: Write reg 7 = 00
lsi_scsi: Write reg 8 = 00
lsi_scsi: Write reg 9 = 00
lsi_scsi: error: Unhandled writeb 0x9 = 0x0

... which looks like execution of a script from la-la land to me.

The dodgy value comes from here, a few operations earlier:

lsi_scsi: SCRIPTS dsp=f200256c opcode f1dc0004 arg 00000024
lsi_scsi: Load reg 0xdc size 4 addr 0x00000024 = f000e987
lsi_scsi: Write reg dc = 87
lsi_scsi: Write reg dd = e9
lsi_scsi: Write reg de = 00
lsi_scsi: Write reg df = f0
lsi_scsi: SCRIPTS dsp=f2002574 opcode f1640004 arg 00000000
lsi_scsi: Load reg 0x64 size 4 addr 0x00000000 = f000ff53      <--**--
lsi_scsi: Write reg 64 = 53
lsi_scsi: Write reg 65 = ff
lsi_scsi: Write reg 66 = 00
lsi_scsi: Write reg 67 = f0
lsi_scsi: SCRIPTS dsp=f200257c opcode e0640004 arg 0101e080
lsi_scsi: Store reg 0x64 size 4 addr 0x0101e080
lsi_scsi: Read reg 64
lsi_scsi: Read reg 65
lsi_scsi: Read reg 66
lsi_scsi: Read reg 67


That's tested with:

qemu \
   -fda /archive/cdimages/SCO_5_0_5_LSI53C895A_BTLD_FLOPPY.img \
   -cdrom /archive/cdimages/SCO_5_0_5.iso \
   -drive file=/var/VMs/alder/alder.img,if=scsi,bus=0,unit=0 \
   -boot d

where the disk image is a 4GB empty (sparse) file. The other two files 
have md5sums:

SCO_5_0_5_LSI53C895A_BTLD_FLOPPY.img:
22c45122239892fefaf911caa8954bc9

SCO_5_0_5.iso:
b2a13770f7e1b46aad4ff601a56f492c

The boot command line was "defbootstr link=slha". At the BTLD prompt 
"<return>28<return>2<return>" is entered.

I get the same result with:

qemu \
   -no-fd-bootchk \
   -fda /mnt/tmp/images/boot/install.img \
   -fdb /archive/cdimages/SCO_5_0_5_LSI53C895A_BTLD_FLOPPY.img \
   -drive file=/var/VMs/alder/alder.img,if=scsi,bus=0,unit=0 \
   -boot a

and the boot string "defbootstr link=slha btld=fd(65)" . I enter 
"<return>26<return>2<return>" at the BTLD prompt, as the kernel hints.

/mnt/tmp/images/boot/install.img:
5297c59e1cd7ba9d098bfa4a929dd28f
(from the OpenServer 5.0.5 CD media)

I'm currently testing with a patched qemu 0.9.1 from Ubuntu 8.10, though 
I'll test with HEAD shortly in case something else has changed; there 
was some fuzz required when applying the patch so something's clearly 
been altered either by Ubuntu patches to qemu 0.9.1 or by changes 
between 0.9.1 and the copy of HEAD you're working on.

--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

> OK, I had a chance to test your patch - correctly, this
> time.
> 
> It gets a lot further into detection but on my 5.0.5 system
> still fails at:
> 
> lsi_scsi: SCRIPTS dsp=f20021ec opcode 88080000 arg f000ff53
> lsi_scsi: Call 0xf000ff53
> lsi_scsi: SCRIPTS dsp=f000ff53 opcode ff0720ff arg ff0720ff
> lsi_scsi: Load reg 0x7 size 7 addr 0x000720ff = 00000000
> lsi_scsi: Write reg 7 = 00
> lsi_scsi: Write reg 8 = 00
> lsi_scsi: Write reg 9 = 00
> lsi_scsi: error: Unhandled writeb 0x9 = 0x0
> 
> ... which looks like execution of a script from la-la land
> to me.
> 
> The dodgy value comes from here, a few operations earlier:
> 
> lsi_scsi: SCRIPTS dsp=f200256c opcode f1dc0004 arg 00000024
> lsi_scsi: Load reg 0xdc size 4 addr 0x00000024 = f000e987
> lsi_scsi: Write reg dc = 87
> lsi_scsi: Write reg dd = e9
> lsi_scsi: Write reg de = 00
> lsi_scsi: Write reg df = f0
> lsi_scsi: SCRIPTS dsp=f2002574 opcode f1640004 arg 00000000
> lsi_scsi: Load reg 0x64 size 4 addr 0x00000000 = f000ff53  
>    <--**--
> lsi_scsi: Write reg 64 = 53
> lsi_scsi: Write reg 65 = ff
> lsi_scsi: Write reg 66 = 00
> lsi_scsi: Write reg 67 = f0
> lsi_scsi: SCRIPTS dsp=f200257c opcode e0640004 arg 0101e080
> lsi_scsi: Store reg 0x64 size 4 addr 0x0101e080
> lsi_scsi: Read reg 64
> lsi_scsi: Read reg 65
> lsi_scsi: Read reg 66
> lsi_scsi: Read reg 67
> 
> 
> That's tested with:
> 
> qemu \
>   -fda
> /archive/cdimages/SCO_5_0_5_LSI53C895A_BTLD_FLOPPY.img \
>   -cdrom /archive/cdimages/SCO_5_0_5.iso \
>   -drive file=/var/VMs/alder/alder.img,if=scsi,bus=0,unit=0
> \
>   -boot d
> 
> where the disk image is a 4GB empty (sparse) file. The
> other two files have md5sums:
> 
> SCO_5_0_5_LSI53C895A_BTLD_FLOPPY.img:
> 22c45122239892fefaf911caa8954bc9
> 
> SCO_5_0_5.iso:
> b2a13770f7e1b46aad4ff601a56f492c
> 
> The boot command line was "defbootstr link=slha".
> At the BTLD prompt
> "<return>28<return>2<return>" is
> entered.

My md5sums match yours.

I used your exact command line and btld options (28 and 2) and it still worked on my end. At this point all I can think of is modifications done by Ubuntu, or it being qemu 0.9.10. It sounds like you're going to try again with a copy of HEAD anyway, hopefully it will work there!

Justin


      

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

Justin Chevrier wrote:

> My md5sums match yours.
> 
> I used your exact command line and btld options (28 and 2) and it still worked on my end. At this point all I can think of is modifications done by Ubuntu, or it being qemu 0.9.10. It sounds like you're going to try again with a copy of HEAD anyway, hopefully it will work there!

It works with HEAD. Ubuntu don't seem to have patched anything in the
LSI SCSI driver, so either it's an effect from elsewhere or (more
likely) a fix in HEAD.

I don't see anything in the Ubuntu patches that looks like a likely
candidate. The only significant change in the lsi driver between 0.9.1
and HEAD doesn't appear to be the cause, either, so it's presumably a
fix somewhere else between 0.9.1 and HEAD. I'm not enthusiastic enough
to go digging, since it works.

CD boot and installation fails after prompting for the CD-ROM ATA bus
location. The first time I tested, oddly, it got a lot further - I was
able to enter license codes, complete package selection and begin the
installation proper before it failed. The error (from SCO's kernel) is:

PANIC: svirtophys - page not present

Some documentation I was able to turn up on this (for OpenServer 6 not
OpenServer 5.05, but it should still be informative):

http://osr600doc.sco.com/man/html.D3oddi/phystokv.D3oddi.html

says:

If kvtophys( ) is given a virtual address that does not map to a
physical address, the kernel panics with the following message:

   svirtophys - Page not present


Booting with mem=1m-5m,128m-256m (hit upon after trying a few different
values to play with the memory regions) seems to work around it.
OpenServer isn't very good at reading the BIOS's memory mappings, and I
wouldn't be too surprised if it was trying to access memory that wasn't
mapped. mem=1m-10m,32m-128m also works, but mem=1m-15m,16m-64m doesn't.
I'll dig a bit more later, but have continued testing to try to get a
successful install.

Just before package selection, qemu prints some warning messages:

lsi_scsi: error: Unimplemented message 0x0c

but proceeds.

The installer then formats the disk. It didn't manage that before, it
crashed after displaying the formatting progress bar but before doing
any significant disk I/O.

The next issue I run into is after the root file system is formatted.
SCO doesn't seem to be able to read the floppy drive when running the
real SCO kernel; it fails to access it as /dev/fd0 (which it is) or as
/dev/fd1 . This would also explain why I can't do a floppy installation.
I haven't investigated yet, as I can skip BTLD installation, it just
means I need to link the BTLD image into the kernel at boot time to init
the machine.

If you skip copying the BTLD image to the root file system installation
continues. However, it crashes at a variable point thereafter with
errors suggesting that the newly created root file system must be
corrupt. Another SCSI issue, presumably - hooray!

*tears at hair*

At least the errors about "lsi_scsi: error: Unimplemented message 0x0c"
might provide a hint. I'll have a look, but thought I should let you
know about the possibility of getting installation to proceed further by
setting a memory mapping manually.

--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

> lsi_scsi: error: Unimplemented message 0x0c

Just a quick follow-up: I think the message 0x0c is:

SCSI Msg Bus Device Reset    0x0c

( based on
http://developer.apple.com/samplecode/SCSI_Async_Sample/listing22.html )

I guess I'll need to go diving into the debug output and SCRIPTS code
again to find out where it's coming from and what the host is expecting
it to do. It's not at all clear that the fact that this command isn't
implemented is even the cause of the problem; it could be a bug
somewhere else in the virtual LSI device or failure to emulate a
bug/quirk in the real hardware that the SCO driver is relying on.

At least it's not real hardware. I'm now beginning to get the faintest
inklings of why hardware designers/testers love FPGAs as much as they do.

--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

Craig Ringer wrote:

> CD boot and installation fails after prompting for the
> CD-ROM ATA bus
> location. The first time I tested, oddly, it got a lot
> further - I was
> able to enter license codes, complete package selection and
> begin the
> installation proper before it failed. The error (from
> SCO's kernel) is:
> 
> PANIC: svirtophys - page not present
> 

I have seen the same thing. What I found is that you need to replace your disk image with a fresh one every time you try a fresh install. My guess is that the emulated controller is writing garbage to the drive, then the installer the next time through is reading this and thinking that the garbage is valid memory locations and is getting confused. I've been using the 'Upgrade' option to debug the error below to avoid having to do this every run through.

> Just before package selection, qemu prints some warning
> messages:
> 
> lsi_scsi: error: Unimplemented message 0x0c
> 
> but proceeds.

I'm looking into this now. I've tossed a basic implementation together, but the error messages continue to flood onto the installer's screen. It appears to be getting interrupts that it isn't expecting. After going through the debug log it looks like the installer pokes a bunch of LUNs and I think that it may not want interrupts for the LUNs that don't have a drive attached to them. This is just a guess though. I've got more testing to do.

At this point I'm not sure if this error has anything to do with the failure of installation. I hate error messages like this though (which wouldn't be there if we emulated correctly), so I'm going to try and fix this first and go from there.

Justin


      

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

Hey guys,

Well I've continued to work on the:

...
WARNING: A_DeviceReset interrupt on ha=0 id=0 lun=5 tag=A6
...

errors (in the emulated OS) when installing Openserver.

I believe I have narrowed down the problem. Openserver does an INQUIRY on various LUNs above 0 (which we don't support). We return 0x7f (nothing here, move along). Openserver then proceeds to send another command to the SCSI disk. The disk then returns:

0x02 - STATUS_CHECK_CONDITION
0x05 - SENSE_ILLEGAL_REQUEST

which is as expected. The problem comes along when the controller goes into Status Phase and compares the resulting sense returned by the drive to see what the status of the drive is. What I've found is that the controller is using the status value (STATUS_CHECK_CONDITION) as the sense value. So it thinks we've recieved a sense return of 'SENSE_NOT_READY' and then it keeps probing the drive until it finally gives up, and we get the above error. See the log below:

...
lsi_scsi: SCRIPTS dsp=f20021a4 opcode 1a000000 arg1 00000018 arg2 810b0000
lsi_scsi: Send command len=6
scsi-disk: Command: lun=1 tag=0x100c1 data=0x00 0x20 0x00 0x00 0x00 0x00
scsi-disk: Unimplemented LUN 1
scsi-disk: Command complete tag=0x100c1 status=2 sense=5 <--****
lsi_scsi: Command reason: 0
lsi_scsi: Command complete sense=2 <-- ****
...

The patch below changes 'scsi_command_complete' (in scsi-disk.c) to pass a sense value along to the callbak instead of status.

I'm not sure this is where we want to go however as this basically reverses part of rev 5455 (which made a point of specifically changing this line).

Do we need to update the LSI emulation to make use of status as well?

Either way, at least we know the cause of these errors and this can be a hack at least if it's not the direction we want to take.

Alas this does not fix Openserver's install problem (not too surprised). Onto the next bug...

Justin

--- hw/scsi-disk.c      (revision 5722)
+++ hw/scsi-disk.c      (working copy)
@@ -135,7 +135,7 @@
     s->sense = sense;
     tag = r->tag;
     scsi_remove_request(r);
-    s->completion(s->opaque, SCSI_REASON_DONE, tag, status);
+    s->completion(s->opaque, SCSI_REASON_DONE, tag, sense);
 }

 /* Cancel a pending data transfer.  */



      

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Laurent Vivier]

Le vendredi 14 novembre 2008 à 12:50 -0800, Justin Chevrier a écrit :
> Hey guys,
> 
> Well I've continued to work on the:
> 
> ...
> WARNING: A_DeviceReset interrupt on ha=0 id=0 lun=5 tag=A6
> ...
> 
> errors (in the emulated OS) when installing Openserver.
> 
> I believe I have narrowed down the problem. Openserver does an INQUIRY on various LUNs above 0 (which we don't support). We return 0x7f (nothing here, move along). Openserver then proceeds to send another command to the SCSI disk. The disk then returns:
> 
> 0x02 - STATUS_CHECK_CONDITION
> 0x05 - SENSE_ILLEGAL_REQUEST
> 
> which is as expected. The problem comes along when the controller goes into Status Phase and compares the resulting sense returned by the drive to see what the status of the drive is. What I've found is that the controller is using the status value (STATUS_CHECK_CONDITION) as the sense value. So it thinks we've recieved a sense return of 'SENSE_NOT_READY' and then it keeps probing the drive until it finally gives up, and we get the above error. See the log below:

Could you explain this part ?

> ...
> lsi_scsi: SCRIPTS dsp=f20021a4 opcode 1a000000 arg1 00000018 arg2 810b0000
> lsi_scsi: Send command len=6
> scsi-disk: Command: lun=1 tag=0x100c1 data=0x00 0x20 0x00 0x00 0x00 0x00
> scsi-disk: Unimplemented LUN 1
> scsi-disk: Command complete tag=0x100c1 status=2 sense=5 <--****
> lsi_scsi: Command reason: 0
> lsi_scsi: Command complete sense=2 <-- ****
> ...

In fact the log is wrong, this is the status key.

> The patch below changes 'scsi_command_complete' (in scsi-disk.c) to pass a sense value along to the callbak instead of status.
> 
> I'm not sure this is where we want to go however as this basically reverses part of rev 5455 (which made a point of specifically changing this line).
> 
> Do we need to update the LSI emulation to make use of status as well?
> 
> Either way, at least we know the cause of these errors and this can be a hack at least if it's not the direction we want to take.
> 
> Alas this does not fix Openserver's install problem (not too surprised). Onto the next bug...
> 
> Justin
> 
> --- hw/scsi-disk.c      (revision 5722)
> +++ hw/scsi-disk.c      (working copy)
> @@ -135,7 +135,7 @@
>      s->sense = sense;
>      tag = r->tag;
>      scsi_remove_request(r);
> -    s->completion(s->opaque, SCSI_REASON_DONE, tag, status);
> +    s->completion(s->opaque, SCSI_REASON_DONE, tag, sense);
>  }
> 
>  /* Cancel a pending data transfer.  */

The sense value is retrieve using REQUEST SENSE. If you send the sense
value instead of the status key, there is no way for the upper levels to
know the status key.

Regards,
Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

Laurent Vivier wrote:
> The sense value is retrieve using REQUEST SENSE. If you
> send the sense
> value instead of the status key, there is no way for the
> upper levels to
> know the status key.
> 

You're right of course. The naming in lsi53c895a.c threw me. My assumptions were based on the naming and therefore are wrong. Back to the drawing board. Thanks for replying!

Justin


      

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

Hmmmm,

I'm kind of confused.

The patch I posted has the latency fix that you included in your patch. It also has reading of 0x46 implemented and writing to 0x1a as well.

The slha driver I used is from this URL:

http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Sco/scounix.zip

I then used the following command line to boot (using the SCO Openserver 5.0.5 install CD):

i386-softmmu/qemu -L pc-bios -m 256 -no-fd-bootchk -fda sco.dd -boot d -drive file=hd.img,if=scsi -cdrom /dev/sr0

The boot string I used was the following (at the 'boot:' prompt):

defbootstr link=slha btld=fd(61)

I also had success with a boot/root floppy combo that I believe I created at one point from a working Openserver installation. I can pass the command lines for those as well if they would be of use.

Thanks for taking a look Craig.

Here is my patch again inline (in case something got lost in the original post):

--- lsi53c895a.c.orig	2008-10-29 14:18:52.000000000 -0400
+++ lsi53c895a.c	2008-11-03 22:12:24.000000000 -0500
@@ -209,6 +209,7 @@
     uint8_t mbox0;
     uint8_t mbox1;
     uint8_t dfifo;
+    uint8_t ctest2;
     uint8_t ctest3;
     uint8_t ctest4;
     uint8_t ctest5;
@@ -280,6 +281,7 @@
     s->mbox0 = 0;
     s->mbox1 = 0;
     s->dfifo = 0;
+    s->ctest2 = 0;
     s->ctest3 = 0;
     s->ctest4 = 0;
     s->ctest5 = 0;
@@ -890,6 +892,7 @@
             break;
         case PHASE_DI:
             s->waiting = 2;
+            s->current_dma_len = s->dbc;
             lsi_do_dma(s, 0);
             if (s->waiting)
                 s->waiting = 3;
@@ -1279,7 +1282,7 @@
     case 0x19: /* CTEST1 */
         return 0;
     case 0x1a: /* CTEST2 */
-        tmp = LSI_CTEST2_DACK | LSI_CTEST2_CM;
+        tmp = s->ctest2 | LSI_CTEST2_DACK | LSI_CTEST2_CM;
         if (s->istat0 & LSI_ISTAT0_SIGP) {
             s->istat0 &= ~LSI_ISTAT0_SIGP;
             tmp |= LSI_CTEST2_SIGP;
@@ -1327,6 +1330,8 @@
         s->sist1 = 0;
         lsi_update_irq(s);
         return tmp;
+    case 0x46: /* MACNTL */
+        return 0x0f;
     case 0x47: /* GPCNTL0 */
         return 0x0f;
     case 0x48: /* STIME0 */
@@ -1440,6 +1445,9 @@
            SCRIPTS register move instructions are.  */
         s->sfbr = val;
         break;
+    case 0x0a: case 0x0b: 
+        /* Openserver writes to these readonly registers on startup */
+	return;    
     case 0x0c: case 0x0d: case 0x0e: case 0x0f:
         /* Linux writes to these readonly registers on startup.  */
         return;
@@ -1469,6 +1477,9 @@
     case 0x17: /* MBOX1 */
         s->mbox1 = val;
         break;
+    case 0x1a: /* CTEST2 */
+	s->ctest2 = val & LSI_CTEST2_PCICIE;
+	break;
     case 0x1b: /* CTEST3 */
         s->ctest3 = val & 0x0f;
         break;
@@ -1869,12 +1880,21 @@
         return NULL;
     }
 
+    /* PCI Vendor ID (word) */
     s->pci_dev.config[0x00] = 0x00;
     s->pci_dev.config[0x01] = 0x10;
+    /* PCI device ID (word) */
     s->pci_dev.config[0x02] = 0x12;
     s->pci_dev.config[0x03] = 0x00;
+    /* PCI base class code */
     s->pci_dev.config[0x0b] = 0x01;
-    s->pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */
+    /* PCI subsystem ID */
+    s->pci_dev.config[0x2e] = 0x00;
+    s->pci_dev.config[0x2f] = 0x10;
+    /* PCI latency timer = 255 */
+    s->pci_dev.config[0x0d] = 0xff;
+    /* Interrupt pin 1 */
+    s->pci_dev.config[0x3d] = 0x01;
 
     s->mmio_io_addr = cpu_register_io_memory(0, lsi_mmio_readfn,
                                              lsi_mmio_writefn, s);



      

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

Justin Chevrier wrote:
> Hmmmm,
> 
> I'm kind of confused.
> 
> The patch I posted has the latency fix that you included in your patch. It also has reading of 0x46 implemented and writing to 0x1a as well.

I've been saying this WAY too often lately, but .... ENOCOFFEE?

Please disregard everything I said. I'll test the patch on my setup
*correctly* shortly.

--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

Hey guys,

Well I've made some progress with getting the LSI53C895A emulated card working under Openserver. 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.

Give it a shot. Hopefully it doesn't break other OS's, but I haven't checked myself. If what I did makes sense and doesn't break anything I'd like to see it get merged into mainline.

Props go to Craig for the initial post and the code that he posted some of which is in this patch.


      

[-- Attachment #2: lsi_sco.diff --]
[-- Type: text/plain, Size: 2599 bytes --]

--- lsi53c895a.c.orig	2008-10-29 14:18:52.000000000 -0400
+++ lsi53c895a.c	2008-11-03 22:12:24.000000000 -0500
@@ -209,6 +209,7 @@
     uint8_t mbox0;
     uint8_t mbox1;
     uint8_t dfifo;
+    uint8_t ctest2;
     uint8_t ctest3;
     uint8_t ctest4;
     uint8_t ctest5;
@@ -280,6 +281,7 @@
     s->mbox0 = 0;
     s->mbox1 = 0;
     s->dfifo = 0;
+    s->ctest2 = 0;
     s->ctest3 = 0;
     s->ctest4 = 0;
     s->ctest5 = 0;
@@ -890,6 +892,7 @@
             break;
         case PHASE_DI:
             s->waiting = 2;
+            s->current_dma_len = s->dbc;
             lsi_do_dma(s, 0);
             if (s->waiting)
                 s->waiting = 3;
@@ -1279,7 +1282,7 @@
     case 0x19: /* CTEST1 */
         return 0;
     case 0x1a: /* CTEST2 */
-        tmp = LSI_CTEST2_DACK | LSI_CTEST2_CM;
+        tmp = s->ctest2 | LSI_CTEST2_DACK | LSI_CTEST2_CM;
         if (s->istat0 & LSI_ISTAT0_SIGP) {
             s->istat0 &= ~LSI_ISTAT0_SIGP;
             tmp |= LSI_CTEST2_SIGP;
@@ -1327,6 +1330,8 @@
         s->sist1 = 0;
         lsi_update_irq(s);
         return tmp;
+    case 0x46: /* MACNTL */
+        return 0x0f;
     case 0x47: /* GPCNTL0 */
         return 0x0f;
     case 0x48: /* STIME0 */
@@ -1440,6 +1445,9 @@
            SCRIPTS register move instructions are.  */
         s->sfbr = val;
         break;
+    case 0x0a: case 0x0b: 
+        /* Openserver writes to these readonly registers on startup */
+	return;    
     case 0x0c: case 0x0d: case 0x0e: case 0x0f:
         /* Linux writes to these readonly registers on startup.  */
         return;
@@ -1469,6 +1477,9 @@
     case 0x17: /* MBOX1 */
         s->mbox1 = val;
         break;
+    case 0x1a: /* CTEST2 */
+	s->ctest2 = val & LSI_CTEST2_PCICIE;
+	break;
     case 0x1b: /* CTEST3 */
         s->ctest3 = val & 0x0f;
         break;
@@ -1869,12 +1880,21 @@
         return NULL;
     }
 
+    /* PCI Vendor ID (word) */
     s->pci_dev.config[0x00] = 0x00;
     s->pci_dev.config[0x01] = 0x10;
+    /* PCI device ID (word) */
     s->pci_dev.config[0x02] = 0x12;
     s->pci_dev.config[0x03] = 0x00;
+    /* PCI base class code */
     s->pci_dev.config[0x0b] = 0x01;
-    s->pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */
+    /* PCI subsystem ID */
+    s->pci_dev.config[0x2e] = 0x00;
+    s->pci_dev.config[0x2f] = 0x10;
+    /* PCI latency timer = 255 */
+    s->pci_dev.config[0x0d] = 0xff;
+    /* Interrupt pin 1 */
+    s->pci_dev.config[0x3d] = 0x01;
 
     s->mmio_io_addr = cpu_register_io_memory(0, lsi_mmio_readfn,
                                              lsi_mmio_writefn, s);

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

Justin Chevrier wrote:

> Well I've made some progress with getting the LSI53C895A emulated card working under Openserver. 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

Brilliant. I was just gearing up to start tracing the SCRIPTS stuff and
figuring out how/where it was going wrong. I'm so very glad you decided
to take a look at it, especially since I'm not sure I would've spotted
that issue at all.

> 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.

I'll try your changes and test from there. I have an image of an
existing, working OpenServer install that I can try to boot by using
"link=slha" on the boot command line and see how I go, and there's the
install CD to test with as well.

--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

Craig Ringer wrote:
> Justin Chevrier wrote:
>
>> 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.
> 
> I'll try your changes and test from there. I have an image of an
> existing, working OpenServer install that I can try to boot by using
> "link=slha" on the boot command line and see how I go, and there's the
> install CD to test with as well.

OK, initial results:

With OpenServer 5.0.5 and slha driver version 4.11.00 (as a BTLD), the
controller is not probed (beyond some poking into its PCI config space)
unless the PCI latency on the device is set to non-zero, so I need to
reapply the latency change to the default PCI config that was in my
original patch.

The driver also accesses register 0x46, so I need to implement the
register read for that (it just returns 0x0f, which seems like how the
hardware should always respond in this case according to the docs). This
looks like a pretty simple, safe and sensible change.

It looks like the OS & driver version I'm using must behave very
differently to the one Justin Chevrier is working with, since he was
able to get it to boot with only the changes he posted whereas
OpenServer 5.0.5 with slha 4.11.00 won't even touch the controller
registers until the PCI latency is changed.



Anyway, once I add support for reading register 0x46 it fails shortly
after because it tries to write to register 0x1a (which is read only
except for bit 3, PCICIE). If I ignore any writes that don't attempt to
set bit 3, which is always reported as clear, execution continues for
quite some time and it appears to be enumerating LUNs, etc.

After poking at LUNs 0 - 7, doing ... something ...., it returns to
accessing LUN 0. At this point it's falling flat deep in some SCRIPTS
code. I'm still trying to figure out exactly what is going on at this
point, since it seems to be jumping into uninitialized system memory and
running garbage at some point, but I haven't been able to trace back to
why yet.

Before going completely insane it does things like a LOAD from
0x00000000 into register 0x64 then STOREs that into system memory at
0x0101e080 - I'm not sure if this might serve any purpose or if it's in
the early(?) stages of it executing garbage. I suspect the latter.




So, anyway, ... what I'm seeing with OpenServer 5.0.5 and the slha BTLD
is very different to what Justin Chevrier is encountering.

Justin, are you able to find out the exact version of OpenServer and the
slha driver that you are using? Are you booting from CD (or CD image),
or are you booting a copy installed on the hard disk? Are you using a
BTLD for the slha driver?

If you're not using the latest slha BTLD from DPT it'd be really helpful
if you could give it a go and see how it goes. Just launch qemu with the
extra argument "-fda /path/to/btld/floppy/image" and at the boot: prompt
enter "defbootstr link=slha" and press enter. If it asks you to replace
existing symbols, enter the numbers it suggests; on my 5.0.5 system
those are 28 and 2, but if there's an existing slha driver to replace
it'll tell you where it's linked into on your image.


--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[andrzej zaborowski]

Hi,

2008/11/4 Justin Chevrier <theburner1@yahoo.com>:
> Well I've made some progress with getting the LSI53C895A emulated card working under Openserver. 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.
>
> Give it a shot. Hopefully it doesn't break other OS's, but I haven't checked myself. If what I did makes sense and doesn't break anything I'd like to see it get merged into mainline.

It makes sense and doesn't break x86/Linux for me, if there's no
opposing comment for a moment, I'll merge this change.

Cheers

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

andrzej zaborowski wrote:

> It makes sense and doesn't break x86/Linux for me, if there's no
> opposing comment for a moment, I'll merge this change.

That'd be rather helpful. Thanks.

There's still more to track down, but this clearly makes the virtual 
controller behave more like the real one in a number of ways.

--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

Craig Ringer wrote:
> I tried to boot off a floppy image for this test to eliminate noise from 
> the IDE CD-ROM access, but qemu doesn't recognise the OpenServer 
> installation disk as bootable.

Hi again,

Just wanted to add that you can work around qemu refusing to boot off of the Openserver bootable floppy disks by telling it to skip the boot check on the floppy drive by using the following option:

"-no-fd-bootchk"

Justin

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Justin Chevrier]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

Hey Craig,

Just wanted to send a quick message of support and that I'm interested in booting Openserver 5.0.5 as well. I was just about to test the latest qemu against it myself (after not having tested for some time).

I'd be more than happy to do any testing if it's needed.

Thanks,

Justin



      

[-- Attachment #2: Type: text/html, Size: 449 bytes --]

[Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

Hi

I'm writing to seek some advice with getting the emulated LSI53C895A 
SCSI HBA or the emulated PIIX PATA IDE controller detected and working 
under SCO OpenServer 5.0.5 . (I'd rather not be using it it all, but we 
don't always get that much choice).

In the case of the PIIX it sees the ATAPI CD-ROM and boots from that 
fine. It just can't detect any ATA hard disks. My understanding is that 
it's probably failing while testing the emulated hardware for some wacky 
quick or misbehaviour that used to be common in some ancient IDE 
controllers.

As for the LSI53C895A, I have a boot-time loadable driver (version 
V4.11.00) that claims to support the card under OpenServer 5.0.5 . 
Following the setup instructions works and the driver is loaded, but no 
hardware appears to be detected.

I've rebuilt qemu with DEBUG_LSI, DEBUG_LSI_REG, DEBUG_SCSI and 
DEBUG_PCI defined. I've included the output that results when I *think* 
the slha driver tries to probe the virtual hardware below.

I assume it's finding something not to its liking in the responses of 
the virtual hardware and is rejecting it. However, I haven't the 
foggiest what it might be, and was really hoping someone here might have 
a bit of experience with troubleshooting hardware detection issues and 
might be able to lend a hand or offer a pointer.

In particular, is there any other tracing/debugging I could/should be 
doing to shed some light on what's going on?

Here's the debug output during (I think) the slha driver's probe of the 
hardware. Qemu (0.9.1, from Ubuntu 8.04) was invoked as:

qemu -cdrom /archive/cdimages/SCO_5_0_5.iso \
  -drive file=/var/VMs/alder/alder.img,media=disk,if=scsi,bus=0,unit=0\
  -fda /archive/cdimages/SCO_5_0_5_LSI53C895A_BTLD_FLOPPY.img \
  -boot d

and kqemu was not loaded or enabled.

pci_config_read: LSI53C895A SCSI HBA: addr=0e val=00000000 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=02 val=00000012 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=2f val=00000000 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=04 val=00000003 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=04 val=00000007 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=14 val=f2001000 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=14 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=14 val=fffffc00 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=14 val=f2001000 len=4
lsi_scsi: Mapping registers at f2001000
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=18 val=f2002000 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=2e val=00000000 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=0d val=00000000 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=0d val=00000000 len=1

The only other output during boot involving the card is repeated 
occurrances of:

pci_config_read: i440FX: addr=0e val=00000000 len=1
pci_config_read: i440FX: addr=00 val=00008086 len=2
pci_config_read: PIIX3: addr=0e val=00000080 len=1
pci_config_read: PIIX3: addr=00 val=00008086 len=2
pci_config_read: PIIX3 IDE: addr=00 val=00008086 len=2
pci_config_read: PM: addr=00 val=00008086 len=2
pci_config_read: Cirrus VGA: addr=0e val=00000000 len=1
pci_config_read: Cirrus VGA: addr=00 val=00001013 len=2
pci_config_read: NE2000: addr=0e val=00000000 len=1
pci_config_read: NE2000: addr=00 val=000010ec len=2
pci_config_read: LSI53C895A SCSI HBA: addr=0e val=00000000 len=1
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=02 val=00000012 len=2

... which looks like PCI device enumeration, probably being done by each 
driver when it initializes and looks for hardware it supports.

There's also some LSI53C895A-related output before the bootloader comes 
up, though it's probably not very interesting given that it's not 
specific to the OS:

pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=02 val=00000012 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=0a val=00000100 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=00 val=00001000 len=2
pci_config_read: LSI53C895A SCSI HBA: addr=02 val=00000012 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=10 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=10 val=ffffff01 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=10 val=ffffff01 len=4
pci_config_write: LSI53C895A SCSI HBA: addr=10 val=0000c200 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=04 val=00000000 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=04 val=00000001 len=2
lsi_scsi: Mapping IO at 0000c200
pci_config_write: LSI53C895A SCSI HBA: addr=14 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=14 val=fffffc00 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=14 val=fffffc00 len=4
pci_config_write: LSI53C895A SCSI HBA: addr=14 val=f2001000 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=04 val=00000001 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=04 val=00000003 len=2
lsi_scsi: Mapping registers at f2001000
pci_config_write: LSI53C895A SCSI HBA: addr=18 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=18 val=ffffe000 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=18 val=ffffe000 len=4
pci_config_write: LSI53C895A SCSI HBA: addr=18 val=f2002000 len=4
lsi_scsi: Mapping ram at f2002000
pci_config_read: LSI53C895A SCSI HBA: addr=04 val=00000003 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=04 val=00000003 len=2
pci_config_write: LSI53C895A SCSI HBA: addr=1c val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=1c val=00000000 len=4
pci_config_write: LSI53C895A SCSI HBA: addr=20 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=20 val=00000000 len=4
pci_config_write: LSI53C895A SCSI HBA: addr=24 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=24 val=00000000 len=4
pci_config_write: LSI53C895A SCSI HBA: addr=30 val=ffffffff len=4
pci_config_read: LSI53C895A SCSI HBA: addr=30 val=00000000 len=4
pci_config_read: LSI53C895A SCSI HBA: addr=3d val=00000001 len=1
pci_config_write: LSI53C895A SCSI HBA: addr=3c val=00000009 len=1

As for the IDE detection, here's the output with DEBUG_IDE enabled. I 
tried to boot off a floppy image for this test to eliminate noise from 
the IDE CD-ROM access, but qemu doesn't recognise the OpenServer 
installation disk as bootable.

For this test qemu was invoked as:

qemu -cdrom /archive/cdimages/SCO_5_0_5.iso \
  -hda /var/VMs/alder/alder.img \
  -boot d

The output is ... verbose. I've put it up here:

http://www.postnewspapers.com.au/~craig/qemu_ide_debug_20081029.txt

... in case it's of interest. I've included a trimmed version below that 
omits all the noise created by loading the kernel image from the CD-ROM, 
etc.

First there's a quick bit of access during PnP init (?):

ide: read addr=0x176 val=a0
ide: read addr=0x175 val=08
ide: write control addr=0x3f6 val=00
ide: read addr=0x1f7 val=50
IDE: write addr=0x1f7 val=0xf0
ide: CMD=f0
ide: read addr=0x1f7 val=41

then much more during what I think is disk probing:

IDE: write addr=0x1f6 val=0xaa
ide: read addr=0x1f6 val=aa
IDE: write addr=0x1f6 val=0xa5
ide: read addr=0x1f6 val=a5
ide: read status addr=0x3f6 val=41
ide: write control addr=0x3f6 val=0a
ide: write control addr=0x3f6 val=0e
ide: write control addr=0x3f6 val=0a
ide: read status addr=0x3f6 val=50
ide: read addr=0x1f7 val=50
ide: read addr=0x1f1 val=01
IDE: write addr=0x1f6 val=0xa0
ide: read addr=0x1f4 val=00
IDE: write addr=0x1f6 val=0xb0
ide: read addr=0x1f4 val=ff
ide: write control addr=0x3f6 val=08
IDE: write addr=0x176 val=0xaa
ide: read addr=0x176 val=aa
IDE: write addr=0x176 val=0xa5
ide: read addr=0x176 val=a5
ide: read status addr=0x376 val=40
ide: write control addr=0x376 val=0a
ide: write control addr=0x376 val=0e
ide: write control addr=0x376 val=0a
ide: read status addr=0x376 val=00
ide: read addr=0x177 val=00
ide: read addr=0x171 val=01
IDE: write addr=0x176 val=0xa0
ide: read addr=0x174 val=14
ide: read addr=0x175 val=eb
IDE: write addr=0x176 val=0xb0
ide: read addr=0x174 val=ff
ide: write control addr=0x376 val=0a
IDE: write addr=0x176 val=0xa0
IDE: write addr=0x177 val=0x08
ide: CMD=08
ide: read status addr=0x376 val=00
ide: read addr=0x177 val=00
ide: read addr=0x174 val=14
ide: read addr=0x175 val=eb
ide: write control addr=0x376 val=0a
IDE: write addr=0x176 val=0xb0
IDE: write addr=0x177 val=0x08
ide: CMD=08
ide: read status addr=0x376 val=00
ide: read addr=0x177 val=00
ide: read addr=0x174 val=ff
ide: read addr=0x171 val=01
ide: read addr=0x172 val=01
ide: read addr=0x173 val=01
ide: write control addr=0x376 val=08
IDE: write addr=0x1f3 val=0x01
IDE: write addr=0x1f4 val=0x00
IDE: write addr=0x1f5 val=0x00
IDE: write addr=0x1f6 val=0xa0
IDE: write addr=0x1f7 val=0x70
ide: CMD=70
ide: read status addr=0x3f6 val=41
ide: read addr=0x1f7 val=41
ide: read addr=0x1f1 val=04
IDE: write addr=0x1f3 val=0x01
IDE: write addr=0x1f4 val=0x00
IDE: write addr=0x1f5 val=0x00
IDE: write addr=0x1f6 val=0xb0
IDE: write addr=0x1f7 val=0x70
ide: CMD=70
ide: write control addr=0x3f6 val=04
ide: write control addr=0x3f6 val=00
ide: read status addr=0x3f6 val=00
ide: read addr=0x1f1 val=01


... after which it reports "no root disk found".


so ... ideas? Suggestions? Advice on where to go or how I might approach 
debugging this?



--
Craig Ringer

Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5

[Craig Ringer]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

Hi all

Sorry to reply to myself, but thanks to an incredibly useful tip on the 
IRC channel that the controller has public documentation, I've got it 
detecting under OpenServer 5.0.5. The OpenServer kernel panics shortly 
afterwards, so there's clearly still something not right, but it's at 
least finding the controller and talking to it to a reasonable degree.

I've attached a diff showing the changes I ended up making. It's not 
intended as a patch to be applied to qemu, at least not at this point, 
but I thought it might be informative and useful. I haven't removed the 
uncommenting of the LSI_DEBUG and LSI_DEBUG_REG flags, nor the wrapping 
of lsi_reg_readb with a function that prints the return values, so it's 
really raw.

The initial problem, by the way, was that the driver didn't like the 
controller reporting a PCI latency setting of 0. It seemed happy enough 
with 255, which is what most BIOSes seem to set according to various 
lspci results from real hardware that I found on the 'net.

After that was changed the driver started accessing the device registers 
via the memory mapping. It pokes all sorts of registers that the virtual 
hardware doesn't currently implement, so there was a long and repetitive 
compile/build/test cycle to identfy and implement each one that was 
missing. I'm far from sure I'm doing the right thing with all of them, 
especially as the driver does things it probably shouldn't, such as:

- Writing to several read-only registers
- Writing to a register where only bit 3 may be set with the value 0x51
- Writing to the reserved register 0xff; and
- Running a script that writes to registers 0x100 - 0x105, though they
   don't appear to exist. This last one looks like it might well be a
   bug in the virtual hardware.

At this point it seems to be doing quite a bit of communication with the 
controller before infinitely looping on a SCRIPTS invocation.

lsi_scsi: SCRIPTS dsp=f0010003 opcode ffffffff arg ffffffff
lsi_scsi: Load reg 0xff size 7 addr 0xffffffff = 00ff5397
lsi_scsi: SCRIPTS dsp=f001000b opcode ffffffff arg ffffffff
lsi_scsi: Load reg 0xff size 7 addr 0xffffffff = 00ff5397
lsi_scsi: SCRIPTS dsp=f0010013 opcode ffffffff arg ffffffff
lsi_scsi: Load reg 0xff size 7 addr 0xffffffff = 00ff5397
lsi_scsi: SCRIPTS dsp=f001001b opcode ffffffff arg ffffffff
lsi_scsi: Load reg 0xff size 7 addr 0xffffffff = 00ff5397
lsi_scsi: SCRIPTS dsp=f0010023 opcode ffffffff arg ffffffff
lsi_scsi: Load reg 0xff size 7 addr 0xffffffff = 00ff5397
lsi_scsi: SCRIPTS dsp=f001002b opcode ffffffff arg ffffffff
lsi_scsi: Load reg 0xff size 7 addr 0xffffffff = 00ff5397
... and so on ...

so it's presumably scanning for something or otherwise expecting one of 
these calls to produce a different result than it does.

Any tips would be appreciated. I just thought I'd put this out in public 
view in case I don't manage to get it all sorted out and someone else is 
in this delightful position later.

No idea about the IDE detection yet, I haven't had a chance to look at 
what it's doing there.

--
Craig Ringer

[-- Attachment #2: lsi_openserver_diff1.diff --]
[-- Type: text/x-diff, Size: 5483 bytes --]

--- lsi53c895a.c	2008-01-07 04:38:42.000000000 +0900
+++ /home/craig/tmp/qemu-0.9.1/hw/lsi53c895a.c	2008-10-30 00:10:40.000000000 +0900
@@ -14,8 +14,8 @@
 #include "pci.h"
 #include "scsi-disk.h"
 
-//#define DEBUG_LSI
-//#define DEBUG_LSI_REG
+#define DEBUG_LSI
+#define DEBUG_LSI_REG
 
 #ifdef DEBUG_LSI
 #define DPRINTF(fmt, args...) \
@@ -209,6 +209,7 @@
     uint8_t mbox0;
     uint8_t mbox1;
     uint8_t dfifo;
+    uint8_t ctest2; /* Only bit 3 used for PCICIE flag */
     uint8_t ctest3;
     uint8_t ctest4;
     uint8_t ctest5;
@@ -280,6 +281,7 @@
     s->mbox0 = 0;
     s->mbox1 = 0;
     s->dfifo = 0;
+    s->ctest2 = 0; /* See comment on declaration */
     s->ctest3 = 0;
     s->ctest4 = 0;
     s->ctest5 = 0;
@@ -1207,7 +1209,7 @@
     DPRINTF("SCRIPTS execution stopped\n");
 }
 
-static uint8_t lsi_reg_readb(LSIState *s, int offset)
+static uint8_t lsi_reg_readb_wrap(LSIState *s, int offset)
 {
     uint8_t tmp;
 #define CASE_GET_REG32(name, addr) \
@@ -1268,7 +1270,7 @@
     case 0x19: /* CTEST1 */
         return 0;
     case 0x1a: /* CTEST2 */
-        tmp = LSI_CTEST2_DACK | LSI_CTEST2_CM;
+        tmp = s->ctest2 | LSI_CTEST2_DACK | LSI_CTEST2_CM;
         if (s->istat0 & LSI_ISTAT0_SIGP) {
             s->istat0 &= ~LSI_ISTAT0_SIGP;
             tmp |= LSI_CTEST2_SIGP;
@@ -1316,8 +1318,12 @@
         s->sist1 = 0;
         lsi_update_irq(s);
         return tmp;
-    case 0x47: /* GPCNTL0 */
-        return 0x0f;
+    case 0x46: /* MACNTL */
+	return 0xf0;
+    case 0x47: /* GPIO */
+        /* GPIO doesn't make a great deal of sense on a virtual device.
+         * Drivers that access this seem happy with 0x0f. */
+         return 0x0f;
     case 0x48: /* STIME0 */
         return s->stime0;
     case 0x4a: /* RESPID0 */
@@ -1374,6 +1380,16 @@
 #undef CASE_GET_REG32
 }
 
+static uint8_t lsi_reg_readb(LSIState *s, int offset)
+{
+	/* Register map: page 128 */
+	/* Registers 5c-5f: scratch */
+	uint8_t tmp;
+	tmp = lsi_reg_readb_wrap(s,offset);
+	DPRINTF("  Value: %02hhx\n", tmp);
+	return tmp;
+}
+
 static void lsi_reg_writeb(LSIState *s, int offset, uint8_t val)
 {
 #define CASE_SET_REG32(name, addr) \
@@ -1385,6 +1401,7 @@
 #ifdef DEBUG_LSI_REG
     DPRINTF("Write reg %x = %02x\n", offset, val);
 #endif
+
     switch (offset) {
     case 0x00: /* SCNTL0 */
         s->scntl0 = val;
@@ -1429,6 +1446,20 @@
            SCRIPTS register move instructions are.  */
         s->sfbr = val;
         break;
+    case 0x09: /* SOCL */
+        /* OpenServer's slha driver sets this register, but it's not really meant
+         * to and we just ignore the effect. */
+	DPRINTF("SOCL set to %02hhx, ignoring\n", val);
+        break;
+    case 0x0a: /* SSID */
+        /* This register is read only, but OpenServer's slha driver writes 0 to it
+         * anyway so clearly the real hardware permits that. */
+        if (val != 0x00)
+            BADF("Write to read-only register SSID (0x0a)");
+        break;
+    case 0x0b: /* SBCL */
+        /* OpenServer's slha driver likes to write to this register, though it's read only. */
+        break;
     case 0x0c: case 0x0d: case 0x0e: case 0x0f:
         /* Linux writes to these readonly registers on startup.  */
         return;
@@ -1458,6 +1489,13 @@
     case 0x17: /* MBOX1 */
         s->mbox1 = val;
         break;
+    case 0x1a: /* CTEST2 */
+        /* Read only, except bit 3 (PCICIE) which may be written */
+        /* The docs say writing to this all other bits must be 0, 
+         * but the OpenServer driver doesn't follow that rule so we'll
+         * just mask the other bits' values. */
+        s->ctest2 = val & LSI_CTEST2_PCICIE;
+	break;
     case 0x1b: /* CTEST3 */
         s->ctest3 = val & 0x0f;
         break;
@@ -1572,6 +1610,11 @@
     CASE_SET_REG32(ia, 0xd4)
     CASE_SET_REG32(sbc, 0xd8)
     CASE_SET_REG32(csbc, 0xdc)
+    case 0xff:
+        /* SCO Openserver's slha driver writes to this for no apparent reason.
+         * The register is reserved. We ignore the write. */
+	DPRINTF("WARNING: Write to reserved register 0xff\n");
+        break;
     default:
         if (offset >= 0x5c && offset < 0xa0) {
             int n;
@@ -1580,6 +1623,10 @@
             shift = (offset & 3) * 8;
             s->scratch[n] &= ~(0xff << shift);
             s->scratch[n] |= (val & 0xff) << shift;
+        } else if (offset >= 0x100) {
+            /* This is outside the register mapping, but OpenServer's slha driver
+             * still writes to it... */
+            DPRINTF("WARNING: Write %hx = %02hhx outside existing register space; ignoring.\n", offset, val);
         } else {
             BADF("Unhandled writeb 0x%x = 0x%x\n", offset, val);
         }
@@ -1858,12 +1905,21 @@
         return NULL;
     }
 
+    /* PCI Vendor ID (word) */
     s->pci_dev.config[0x00] = 0x00;
     s->pci_dev.config[0x01] = 0x10;
+    /* PCI device ID (word) */
     s->pci_dev.config[0x02] = 0x12;
     s->pci_dev.config[0x03] = 0x00;
+    /* PCI base class code */
     s->pci_dev.config[0x0b] = 0x01;
-    s->pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */
+    /* PCI subsystem ID */
+    s->pci_dev.config[0x2e] = 0x00;
+    s->pci_dev.config[0x2f] = 0x10;
+    /* PCI latency timer = 255 */
+    s->pci_dev.config[0x0d] = 0xff;
+    /* Interrupt pin 1 */
+    s->pci_dev.config[0x3d] = 0x01;
 
     s->mmio_io_addr = cpu_register_io_memory(0, lsi_mmio_readfn,
                                              lsi_mmio_writefn, s);