From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxGoU-0001p1-BL for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:58:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxGoS-0001oO-Px for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:58:58 -0500 Received: from [199.232.76.173] (port=34371 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxGoS-0001oI-Fx for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:58:56 -0500 Received: from mx20.gnu.org ([199.232.41.8]:51775) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KxGoR-0003iK-Ls for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:58:55 -0500 Received: from www.postnewspapers.com.au ([202.61.230.242]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxGoO-0001Lf-UN for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:58:53 -0500 Received: from mail.postnewspapers.com.au (202-89-185-120.static.dsl.amnet.net.au [202.89.185.120]) by www.postnewspapers.com.au (Postfix) with ESMTP id F24BF5C0CA for ; Tue, 4 Nov 2008 16:57:42 +0900 (WST) Received: from localhost (access [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id CF5E11E0434 for ; Tue, 4 Nov 2008 16:57:42 +0900 (WST) Received: from mail.postnewspapers.com.au ([127.0.0.1]) by localhost (access.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v5v24ugXMs-B for ; Tue, 4 Nov 2008 16:57:38 +0900 (WST) Received: from [192.168.44.80] (203-59-94-220.perm.iinet.net.au [203.59.94.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Craig Ringer", Issuer "POST Certificate Authority" (verified OK)) by mail.postnewspapers.com.au (Postfix) with ESMTP id 0FD551E0435 for ; Tue, 4 Nov 2008 16:57:38 +0900 (WST) Message-ID: <49100071.5090002@postnewspapers.com.au> Date: Tue, 04 Nov 2008 16:57:37 +0900 From: Craig Ringer MIME-Version: 1.0 Subject: Re: [Qemu-devel] LSI53C895A, IDE HDD detection under SCO OpenServer 5.0.5 References: <287825.75973.qm@web51112.mail.re2.yahoo.com> <490FC479.7090600@postnewspapers.com.au> In-Reply-To: <490FC479.7090600@postnewspapers.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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