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

[Craig Ringer <craig@postnewspapers.com.au>]

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