[SeaBIOS] [PATCH v2] scsi: add AMD PCscsi driver
This is a driver for an AMD PCscsi (am53c974) SCSI card. It can be
used together with DOS or old operating systems such as Windows NT 3.1,
Windows 3.1 or Windows 98.
Cc: Hervé Poussineau
Signed-off-by: Paolo Bonzini
---
v1->v2: now includes esp-scsi.h, and depends on !COREBOOT
Makefile | 2 +-
src/Kconfig| 6 ++
src/block.c| 1 +
src/blockcmd.c | 3 +
src/disk.h | 1 +
src/esp-scsi.c | 231 +
src/esp-scsi.h | 8 ++
src/post.c | 2 +
8 file modificati, 253 inserzioni(+). 1 rimozione(-)
create mode 100644 src/esp-scsi.c
create mode 100644 src/esp-scsi.h
diff --git a/Makefile b/Makefile
index 2383bce..a42f06b 100644
--- a/Makefile
+++ b/Makefile
@@ -13,7 +13,7 @@ SRCBOTH=misc.c stacks.c pmm.c output.c util.c block.c
floppy.c ata.c mouse.c \
pnpbios.c pirtable.c vgahooks.c ramdisk.c pcibios.c blockcmd.c \
usb.c usb-uhci.c usb-ohci.c usb-ehci.c usb-hid.c usb-msc.c \
virtio-ring.c virtio-pci.c virtio-blk.c virtio-scsi.c apm.c ahci.c \
-usb-uas.c lsi-scsi.c
+usb-uas.c lsi-scsi.c esp-scsi.c
SRC16=$(SRCBOTH) system.c disk.c font.c
SRC32FLAT=$(SRCBOTH) post.c shadow.c memmap.c coreboot.c boot.c \
acpi.c smm.c mptable.c smbios.c pciinit.c optionroms.c mtrr.c \
diff --git a/src/Kconfig b/src/Kconfig
index bc343ee..cee3bc5 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -119,6 +119,12 @@ menu "Hardware support"
default y
help
Support boot from virtio-scsi storage.
+config ESP_SCSI
+depends on DRIVES && !COREBOOT
+bool "AMD PCscsi controllers"
+default y
+help
+Support boot from AMD PCscsi storage.
config LSI_SCSI
depends on DRIVES && !COREBOOT
bool "lsi53c895a scsi controllers"
diff --git a/src/block.c b/src/block.c
index 1c200cc..243428e 100644
--- a/src/block.c
+++ b/src/block.c
@@ -335,6 +335,7 @@ process_op(struct disk_op_s *op)
case DTYPE_UAS:
case DTYPE_VIRTIO_SCSI:
case DTYPE_LSI_SCSI:
+case DTYPE_ESP_SCSI:
return process_scsi_op(op);
default:
op->count = 0;
diff --git a/src/blockcmd.c b/src/blockcmd.c
index 95406c6..f3b6c2f 100644
--- a/src/blockcmd.c
+++ b/src/blockcmd.c
@@ -15,6 +15,7 @@
#include "usb-uas.h" // usb_cmd_data
#include "virtio-scsi.h" // virtio_scsi_cmd_data
#include "lsi-scsi.h" // lsi_scsi_cmd_data
+#include "esp-scsi.h" // esp_scsi_cmd_data
#include "boot.h" // boot_add_hd
// Route command to low-level handler.
@@ -35,6 +36,8 @@ cdb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16
blocksize)
return virtio_scsi_cmd_data(op, cdbcmd, blocksize);
case DTYPE_LSI_SCSI:
return lsi_scsi_cmd_data(op, cdbcmd, blocksize);
+case DTYPE_ESP_SCSI:
+return esp_scsi_cmd_data(op, cdbcmd, blocksize);
default:
op->count = 0;
return DISK_RET_EPARAM;
diff --git a/src/disk.h b/src/disk.h
index 2b2511f..3d07372 100644
--- a/src/disk.h
+++ b/src/disk.h
@@ -234,6 +234,7 @@ struct drive_s {
#define DTYPE_USB 0x0a
#define DTYPE_UAS 0x0b
#define DTYPE_LSI_SCSI 0x0c
+#define DTYPE_ESP_SCSI 0x0d
#define MAXDESCSIZE 80
diff --git a/src/esp-scsi.c b/src/esp-scsi.c
new file mode 100644
index 000..daafa1e
--- /dev/null
+++ b/src/esp-scsi.c
@@ -0,0 +1,231 @@
+// AMD PCscsi boot support.
+//
+// Copyright (C) 2012 Red Hat Inc.
+//
+// Authors:
+// Paolo Bonzini
+//
+// based on lsi-scsi.c which is written by:
+// Gerd Hoffman
+//
+// This file may be distributed under the terms of the GNU LGPLv3 license.
+
+#include "util.h" // dprintf
+#include "pci.h" // foreachpci
+#include "config.h" // CONFIG_*
+#include "biosvar.h" // GET_GLOBAL
+#include "pci_ids.h" // PCI_DEVICE_ID
+#include "pci_regs.h" // PCI_VENDOR_ID
+#include "boot.h" // bootprio_find_scsi_device
+#include "blockcmd.h" // scsi_init_drive
+#include "disk.h"
+
+#define ESP_TCLO 0x00
+#define ESP_TCMID 0x04
+#define ESP_FIFO 0x08
+#define ESP_CMD 0x0c
+#define ESP_WBUSID0x10
+#define ESP_TCHI 0x38
+
+#define ESP_RSTAT 0x10
+#define ESP_RINTR 0x14
+#define ESP_RFLAGS0x1c
+
+#define ESP_DMA_CMD 0x40
+#define ESP_DMA_STC 0x44
+#define ESP_DMA_SPA 0x48
+#define ESP_DMA_WBC 0x4c
+#define ESP_DMA_WAC 0x50
+#define ESP_DMA_STAT 0x54
+#define ESP_DMA_SMDLA 0x58
+#define ESP_DMA_WMAC 0x58c
+
+#define ESP_CMD_DMA 0x80
+#define ESP_CMD_RESET0x02
+#define ESP_CMD_TI 0x10
+#define ESP_CMD_ICCS 0x11
+#define ESP_CMD_SELATN 0x42
+
+#define ESP_STAT_DI 0x01
+#define ESP_STAT_CD 0x02
+#define ESP_STAT_MSG 0x04
+#define ESP_STAT_TC 0x10
+
+#define ESP_INTR_DC 0x20
+
+struct esp_lun_s {
+struct drive_s drive;
+struct pci_device *pci;
+u32 iobase;
+u8 target;
+u8 lun;
+};
+
+static void
+esp_scsi_dma(u32 iobase, u32 buf, u32 len, int read)
+{
+outb(len & 0xff, iobase + ESP_TCLO)
Re: [SeaBIOS] [Seabois] BSOD during start of Win2003 installation
I think Windows 2003 uses a more modern code base than Windows XP. 2003 is more similar to XP 64-bit. On Mon, Aug 6, 2012 at 8:49 AM, Gerd Hoffmann wrote: > On 07/24/12 19:51, Alexey Korolev wrote: >> Hi, >> >> Win2003 falls to BSOD during early init stage of installer. >> It is ACPI related issue and it appears in any configuration. RAM size is 6GB >> Error code is : >> 0x00A5 (0x02, 0xfADF6A446880, 0x1, 0xFADFAA34690) >> >> The things get broken after commit 2062f2bab81915c5c1f7af12a49ad8d4b3fd23fb >> (update dsdt resources at runtime) >> >> I've tried to debug this issue but haven't succeed yet. >> >> One strange thing here is that the code doesn't reach the _CRS method. We >> have added a debug output but nothing related to CRS was printed. >> May be you have any ideas why it may fail. I would much appreciate any help >> on this. > > DBUG() didn't work for me with winxp (same code base as win2k3 iirc), so > no debug output is *not* an indicator for not reaching _CRS. > > Is this win2k3 with latest service pack? I've used winxp with sp3 for > testing ... > > cheers, > Gerd > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] UHCI on US15W: Crazy stuff happening
Thanks for the response Kevin I've spent another day trying to get to the bottom of this one, still no luck. Attempt to 16 byte align: No difference. Errata: One point mentioned with regards to UHCI but its affect would be a complete disabling of the controller, not this _sort of_ working issue I see, and, coreboot already has code which applies the workaround. Registers: Nothing much interesting here either Before: Regs: USBCMD: c1 USBSTS: 0 USBINTR: 0 USBFRNUM: 2ab USBSOF: 40 USBFLBASEAD: eaac USBPORTSC1: 1a7 USBPORTSC2: 80 After: Regs: USBCMD: c1 USBSTS: 0 USBINTR: 0 USBFRNUM: 4b3 USBSOF: 40 USBFLBASEAD: e2cc USBPORTSC1: 1a7 USBPORTSC2: 80 The more I look the more I find out _OK_ everything is. I did try another experiment which had even more interesting results, I tacked some more data onto the end of the setup packet (a5 a5 a5 a5 33 33 33 33 66 66 66 66) - what did it do? It made an exact copy of it immediately after the first one, it always does this regardless of how much data is being sent, and always writes a 'mystery' 12 bytes after that. before: 1fbc44b0: 00 05 01 00 00 00 00 00 a5 a5 a5 a5 33 33 33 33 1fbc44c0: 66 66 66 66 ff ff ff ff ff ff ff ff ff ff ff ff 1fbc44d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1fbc44e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff after: 1fbc44b0: 00 05 01 00 00 00 00 00 a5 a5 a5 a5 33 33 33 33 1fbc44c0: 66 66 66 66 00 05 01 00 00 00 00 00 a5 a5 a5 a5 1fbc44d0: 33 33 33 33 66 66 66 66 fd 03 00 00 00 00 00 00 1fbc44e0: 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff I think the setting of the ActLen to 7ff is just its way of zeroing the count when the transaction begins, perhaps it never gets incremented because the process which is meant to fetch the memory is broken. Current theory: Something is broken in the DMA process. I can't really see how a UHCI controller could ever do something this crazy. Next step, assuming no one has any ideas, start examining why Linux works OK, I had a quick look for quirks but couldn't spot anything, but realistically, that is going to be a significant effort to see through. Cheers Matt On Sun, Aug 5, 2012 at 4:44 PM, Kevin O'Connor wrote: > On Sun, Aug 05, 2012 at 12:21:13PM +0100, Matthew Millman wrote: > > Hi > > > > I'm seeing a rather interesting problem with UHCI on Intel US15W and > > wondered if anyone else had seen anything like this before. I noticed it > > when I plugged in a USB keyboard, which caused a crash due to something > > corrupting the stack? it turns out that the stack has been trashed by the > > UHCI controller via DMA?! > > > > When trying to transmit the 8 byte address setup packet, the hardware > > doesn't quite seem to be doing as it's told. SeaBIOS sets up the UHCI TDs > > exactly as per the spec - no problems there, > > > > Once the QH element is set, instead of transmitting the 8 bytes as > > described in the TD, it transmits a full 1023 bytes? (according to the > > returned TD) UHCI then goes ahead and overwrites another 35 bytes beyond > > the end of the buffer pointed to by the TD. > > > > Here's the 8 bytes of the setup packet (I've set everything after it to > > 0xFF): > > > > 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff > > 1fbc1fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 1fbc1fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 1fbc1fd0: ff ff ff ff ff > > > > Here it is after the UHCI controller has been at it. The only code to > > execute between these two dumps is this: > > > > pipe->qh.element = (u32)&tds[0]; (in uhci_control()) > > > > 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff > > 1fbc1fa0: bf 00 05 01 00 00 00 00 00 ff ff ff fd 03 00 00 > > 1fbc1fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 1fbc1fd0: ff ff ff ff ff > > > > TD Chain before: > > 1fbc4870: 84 48 bc 1f 00 00 80 1c 2d 00 e0 00 95 1f bc 1f > > 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00 > > > > TD Chain after: > > 1fbc4870: 84 48 bc 1f ff 07 80 1c 2d 00 e0 00 95 1f bc 1f > > 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00 > > My read of the spec says an actlen=0x07ff means a null transfer (not > 1023 bytes). However, given that the status is still active I don't > think it really matters what's in the td. > > > I'm wondering if I'm not the first person to have seen this. The problem > > (without detailed debugging) manifests its self exactly as described in > > this message: > > I haven't seen this type of report before. A couple of things you > could try: dump the USB controller registers as well (the controller > may have shutdown for a different reason), check to see if any other > transfer attempted to use 0x1fbc1fa0 in the past (perhaps the > controller has something stale cached), look for an errata for the > chipset, look through the linux code for the chipset to see if it is > working about something, try aligning the s
Re: [SeaBIOS] [BUG] BSOD on Win2003 Server when 64bit PCI resource is present
On 07/28/12 17:27, Kevin O'Connor wrote: > On Thu, Jul 26, 2012 at 03:38:47PM +, Alexey Korolev wrote: >> HI, >> >> Current version of Seabios is causing blue screen on Windows2003 when 64bit >> PCI resource is present and occupies high memory. >> >> BSOD Error code is: 0x00A5 (0x02, 0xfADF6A446880, 0x1, >> 0xFADFAA34690) >> >> The issue is localized, it is related to presence of 64bit resource in _CRS >> method. >> >> If we disable a 64bit region from _CRS the Win2003 load normally but this >> doesn't allow Windows to use 64bit resources. >> >> At the moment I have no idea how to fix this. Please help! > > Unfortunately, it's very difficult to debug acpi issues on Windows. > Gerd's been on vacation this week - so, lets give him a chance to look > at it when he gets back. If it can't be resolved, we'll need to > revert the patch that broke Win2003. Well, it isn't a regression, so no need to revert IMHO. It breaks on winxp / win2k3 only in case 64bit pci is actually used. Which happens only in case we run out of address space below 4G. This is a setup which isn't supported at all with older seabios versions. The very first patch revision had a static entry in the _CRS array (before _CRS became a method) which didn't work with winxp too. So we ended up with the _CRS method which (beside updating the 32bit window) adds the 64bit RessourceTemplate only in case we actually have 64bit pci ressources, so we don't disturb existing setups with a new 64bit entry they might not be able to handle. I've never seen 64bit RessourceTemplate entries work with winxp, I fear the winxp acpi code just can't handle 64bit RessourceTemplates ... cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
