August 2012 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] UHCI on US15W: Crazy stuff happening
by Matthew Millman Aug. 7, 2012

Aug. 7, 2012

Got it: This line in usb-uhci.c (reset_uhci()) broke it: pci_config_writew(bdf, USBLEGSUP, USBLEGSUP_RWC); According to the US15W datasheet, there is no register at this offset, there does seem to be something there because it reads 0x0400 after that write, but I don't think it's what SeaBIOS is thinking it is... USB Keyboard is working. Woohoo! On Mon, Aug 6, 2012 at 4:08 PM, Matthew Millman <inaxeon(a)gmail.com> wrote: > 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 <kevin(a)koconnor.net> 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 setup packet buffer to 16 >> bytes. >> >> -Kevin >> > >

1 0

Re: [SeaBIOS] UHCI on US15W: Crazy stuff happening
by Kevin O'Connor Aug. 6, 2012

Aug. 6, 2012

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 setup packet buffer to 16 bytes. -Kevin

2 1

Re: [SeaBIOS] [Seabois] BSOD during start of Win2003 installation
by Gerd Hoffmann Aug. 6, 2012

Aug. 6, 2012

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 : > 0x000000A5 (0x02, 0xFFFFfADF6A446880, 0x1, 0xFFFFFADFAA34690) > > 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

2 1

Re: [SeaBIOS] [BUG] BSOD on Win2003 Server when 64bit PCI resource is present
by Kevin O'Connor Aug. 6, 2012

Aug. 6, 2012

On Thu, Jul 26, 2012 at 03:38:47PM +0000, 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: 0x000000A5 (0x02, 0xFFFFfADF6A446880, 0x1, 0xFFFFFADFAA34690) > > 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. > P/S > Yet another issue is related to debug messages. > If I add any DBUG call in acpi-dst it will cause BSOD on win2003 (win2008 works fine) I've seen this as well (on WinXP - I don't have Win2003). Unfortunately, I haven't been able to find out why the debug macro fails on these older versions of Windows. -Kevin

4 3

UHCI on US15W: Crazy stuff happening
by Matthew Millman Aug. 5, 2012

Aug. 5, 2012

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 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: http://comments.gmane.org/gmane.linux.bios/55336 Thanks! Matt

1 0

Re: [SeaBIOS] IEEE 1394 interface booting
by Peter Stuge Aug. 4, 2012

Aug. 4, 2012

Fred . wrote: > I see. > It should be added to an TODO list though. > Or "things-you-work-on" list. TODO is for things that existing project participants plan to do. FireWire and TPM is not neccessarily planned by anyone. If you plan to do it, then please just send a patch which introduces something to the code, even if just documentation about current progress. If "you" in "things-you-work-on" means existing project participants then the same is true. If someone was working on these features, there would be sign of that in the repository or on the mailing list. Neither is true. If you want to work on either of these features then I suggest to send some patches to make your effort visible, even if you are still nowhere near submitting final patches for inclusion. Just like in every other open source project. //Peter

2 1

[PATCH] scsi: add AMD PCscsi driver
by Paolo Bonzini Aug. 4, 2012

Aug. 4, 2012

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 <hpoussin(a)reactos.org> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- Makefile | 2 +- src/Kconfig | 6 ++ src/block.c | 1 + src/blockcmd.c | 3 + src/disk.h | 1 + src/esp-scsi.c | 231 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/post.c | 2 + 7 files changed, 245 insertions(+), 1 deletion(-) create mode 100644 src/esp-scsi.c diff --git a/Makefile b/Makefile index 1167799..4dce77b 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 + 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 4365650..97c72a6 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 0000000..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 <pbonzini(a)redhat.com> +// +// based on lsi-scsi.c which is written by: +// Gerd Hoffman <kraxel(a)redhat.com> +// +// 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_WBUSID 0x10 +#define ESP_TCHI 0x38 + +#define ESP_RSTAT 0x10 +#define ESP_RINTR 0x14 +#define ESP_RFLAGS 0x1c + +#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_RESET 0x02 +#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); + outb((len >> 8) & 0xff, iobase + ESP_TCMID); + outb((len >> 16) & 0xff, iobase + ESP_TCHI); + outl(buf, iobase + ESP_DMA_SPA); + outl(len, iobase + ESP_DMA_STC); + outb(read ? 0x83 : 0x03, iobase + ESP_DMA_CMD); +} + +static int +esp_scsi_cmd(struct esp_lun_s *llun, struct disk_op_s *op, + u8 *cdbcmd, u16 target, u16 lun, u16 blocksize) +{ + u32 iobase = GET_GLOBAL(llun->iobase); + int i, state; + u8 status; + + outb(target, iobase + ESP_WBUSID); + + /* + * We need to pass the LUN at the beginning of the command, and the FIFO + * is only 16 bytes, so we cannot support 16-byte CDBs. The alternative + * would be to use DMA for the 17-byte command too, which is quite + * overkill. + */ + outb(lun, iobase + ESP_FIFO); + cdbcmd[1] &= 0x1f; + cdbcmd[1] |= lun << 5; + for (i = 0; i < 12; i++) + outb(cdbcmd[i], iobase + ESP_FIFO); + outb(ESP_CMD_SELATN, iobase + ESP_CMD); + + for (state = 0;;) { + u8 stat = inb(iobase + ESP_RSTAT); + + /* Detect disconnected device. */ + if (state == 0 && (inb(iobase + ESP_RINTR) & ESP_INTR_DC)) { + return DISK_RET_ENOTREADY; + } + + /* HBA reads command, clears CD, sets TC -> do DMA if needed. */ + if (state == 0 && (stat & ESP_STAT_TC)) { + state++; + if (op->count && blocksize) { + /* Data phase. */ + u32 count = (u32)op->count * blocksize; + esp_scsi_dma(iobase, (u32)op->buf_fl, count, + cdb_is_read(cdbcmd, blocksize)); + outb(ESP_CMD_TI | ESP_CMD_DMA, iobase + ESP_CMD); + continue; + } + } + + /* At end of DMA TC is set again -> complete command. */ + if (state == 1 && (stat & ESP_STAT_TC)) { + state++; + outb(ESP_CMD_ICCS, iobase + ESP_CMD); + continue; + } + + /* Finally read data from the message in phase. */ + if (state == 2 && (stat & ESP_STAT_MSG)) { + state++; + status = inb(iobase + ESP_FIFO); + inb(iobase + ESP_FIFO); + break; + } + usleep(5); + } + + if (status == 0) { + return DISK_RET_SUCCESS; + } + + return DISK_RET_EBADTRACK; +} + +int +esp_scsi_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize) +{ + if (!CONFIG_ESP_SCSI) + return DISK_RET_EBADTRACK; + + struct esp_lun_s *llun = + container_of(op->drive_g, struct esp_lun_s, drive); + + return esp_scsi_cmd(llun, op, cdbcmd, + GET_GLOBAL(llun->target), GET_GLOBAL(llun->lun), + blocksize); +} + +static int +esp_scsi_add_lun(struct pci_device *pci, u32 iobase, u8 target, u8 lun) +{ + struct esp_lun_s *llun = malloc_fseg(sizeof(*llun)); + if (!llun) { + warn_noalloc(); + return -1; + } + memset(llun, 0, sizeof(*llun)); + llun->drive.type = DTYPE_ESP_SCSI; + llun->drive.cntl_id = pci->bdf; + llun->pci = pci; + llun->target = target; + llun->lun = lun; + llun->iobase = iobase; + + char *name = znprintf(16, "esp %02x:%02x.%x %d:%d", + pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf), + pci_bdf_to_fn(pci->bdf), target, lun); + int prio = bootprio_find_scsi_device(pci, target, lun); + int ret = scsi_init_drive(&llun->drive, name, prio); + free(name); + if (ret) + goto fail; + return 0; + +fail: + free(llun); + return -1; +} + +static void +esp_scsi_scan_target(struct pci_device *pci, u32 iobase, u8 target) +{ + esp_scsi_add_lun(pci, iobase, target, 0); +} + +static void +init_esp_scsi(struct pci_device *pci) +{ + u16 bdf = pci->bdf; + u32 iobase = pci_config_readl(pci->bdf, PCI_BASE_ADDRESS_0) + & PCI_BASE_ADDRESS_IO_MASK; + + dprintf(1, "found esp at %02x:%02x.%x, io @ %x\n", + pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), + pci_bdf_to_fn(bdf), iobase); + + // reset + outb(ESP_CMD_RESET, iobase + ESP_CMD); + + int i; + for (i = 0; i <= 7; i++) + esp_scsi_scan_target(pci, iobase, i); + + return; +} + +void +esp_scsi_setup(void) +{ + ASSERT32FLAT(); + if (!CONFIG_ESP_SCSI) + return; + + dprintf(3, "init esp\n"); + + struct pci_device *pci; + foreachpci(pci) { + if (pci->vendor != PCI_VENDOR_ID_AMD + || pci->device != PCI_DEVICE_ID_AMD_SCSI) + continue; + init_esp_scsi(pci); + } +} diff --git a/src/post.c b/src/post.c index 0f31b4c..924b311 100644 --- a/src/post.c +++ b/src/post.c @@ -28,6 +28,7 @@ #include "virtio-blk.h" // virtio_blk_setup #include "virtio-scsi.h" // virtio_scsi_setup #include "lsi-scsi.h" // lsi_scsi_setup +#include "esp-scsi.h" // esp_scsi_setup /**************************************************************** @@ -196,6 +197,7 @@ init_hw(void) virtio_blk_setup(); virtio_scsi_setup(); lsi_scsi_setup(); + esp_scsi_setup(); } // Begin the boot process by invoking an int0x19 in 16bit mode. -- 1.7.10.4

2 3

[PATCH 0/2] SCSI fixes
by Paolo Bonzini Aug. 4, 2012

Aug. 4, 2012

Here are two simple fixes for the SCSI driver, so that the LSI adapter is able to boot FreeDOS. Paolo Bonzini (2): lsi: do not reset on error scsi: fix detection of QEMU src/blockcmd.c | 2 +- src/lsi-scsi.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) -- 1.7.10.4

2 3

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Kevin O'Connor Aug. 4, 2012

Aug. 4, 2012

On Tue, Jul 31, 2012 at 08:02:45PM +0200, Idwer Vollering wrote: > 2012/7/31 Moore, Robert <robert.moore(a)intel.com>: > > Please let me know if the -Pn option works for you. > > Thanks, > > Bob > > -Pn works for me, on acpica-20120420-64. It looks like "-Pn" only works on newer versions of iasl. Can you confirm the SeaBIOS patch below works with a newer iasl? -Kevin --- a/Makefile +++ b/Makefile @@ -221,11 +221,14 @@ $(OUT)vgabios.bin: $(OUT)vgabios.bin.raw tools/buildrom.py ################ DSDT build rules +iasl-option=$(shell if test -z "`$(1) $(2) -h 2>&1 > /dev/null" \ + ; then echo "$(2)"; else echo "$(3)"; fi ;) + $(OUT)%.hex: src/%.dsl ./tools/acpi_extract_preprocess.py ./tools/acpi_extract.py @echo " Compiling IASL $@" $(Q)cpp -P $< > $(OUT)$*.dsl.i.orig $(Q)$(PYTHON) ./tools/acpi_extract_preprocess.py $(OUT)$*.dsl.i.orig > $(OUT)$*.dsl.i - $(Q)$(IASL) -vs -l -tc -p $(OUT)$* $(OUT)$*.dsl.i + $(Q)$(IASL) $(iasl-option,$(IASL),-Pn,) -vs -l -tc -p $(OUT)$* $(OUT)$*.dsl.i $(Q)$(PYTHON) ./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off $(Q)cat $(OUT)$*.off > $@

4 4

Re: [SeaBIOS] IEEE 1394 interface booting
by Peter Stuge Aug. 4, 2012

Aug. 4, 2012

Fred . wrote: > Add support for booting from IEEE 1394 (aka FireWire) interface. Same here - noone is likely to do this until they want to have it themselves. When someone is doing an implementation we can talk about details. //Peter

2 1