SeaBIOS November 2011

seabios@seabios.org

22 participants
31 discussions

by Paolo Bonzini

The fw paths for USB devices that SeaBIOS computes are off-by-one, because QEMU builds those paths with a numbering that starts from one (see usb_fill_port and usb_hub_initfn in QEMU). Fix that so that the numbering agrees. --- src/boot.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/boot.c b/src/boot.c index 946850d..434bf80 100644 --- a/src/boot.c +++ b/src/boot.c @@ -205,9 +205,9 @@ int bootprio_find_usb(struct pci_device *pci, u64 path) for (i=56; i>0; i-=8) { int port = (path >> i) & 0xff; if (port != 0xff) - p += snprintf(p, desc+sizeof(desc)-p, "/hub@%x", port); + p += snprintf(p, desc+sizeof(desc)-p, "/hub@%x", port+1); } - snprintf(p, desc+sizeof(desc)-p, "/*@%x", (u32)(path & 0xff)); + snprintf(p, desc+sizeof(desc)-p, "/*@%x", (u32)(path & 0xff)+1); return find_prio(desc); } -- 1.7.7.1

10 years

[PATCH 00/16] make SCSI and virtio layers more generic, fix usb-msc bugs

by Paolo Bonzini

Hi all, this are the preparatory bits for virtio-scsi support in SeaBIOS. They mostly aim at making code more generic in SeaBIOS for both SCSI and virtio, but (on the SCSI side) they also fix some bugs, so I'm sending them early to get more exposure. New features are mostly visible on the USB side since that's currently the main consumer of the SCSI implementation. They include more robust LUN detection, support for hard disk geometry, and USB mass storage write support. I also fixed for real the race that the RFC series was working around. For virtio, the series adds a few extra interface bits that are common to both virtio-scsi and virtio-blk. The two parts are logically separate but they have a small conflict, so I'm sending them together. Paolo Bonzini (16): cdrom: use TEST UNIT READY to detect ready medium usb-uhci: reorganize wait_qh into wait_pipe usb-uhci: fix race against host controller usb-msc: support commands without payload usb-msc: add usb_msc_send usb-msc: support WRITE commands usb-msc: move READ CAPACITY to usb_msc_init, fix off-by-one usb-msc: pass drive to setup_drive_* usb-msc: rename INQUIRY types usb-msc: go through TEST UNIT READY for hard disks. usb-msc: move common scsi code to blockcmd.c usb-msc: move cdb dispatch to block.c scsi: get physical chs geometry from mode page 0x04 always specify virtio-blk rather than virtio virtio-pci: introduce vp_init_simple virtio-pci: allocate vq in vp_find_vq v1->v2: do not send commands to CDs until they are actually selected for boot; fix usb-uhci race for real; virtio-scsi driver not yet included. src/Kconfig | 4 +- src/block.c | 34 ++++++++++-- src/blockcmd.c | 157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/blockcmd.h | 42 ++++++++++++++- src/cdrom.c | 58 +------------------- src/disk.c | 4 +- src/disk.h | 18 +++--- src/usb-msc.c | 132 ++++++++++++++------------------------------- src/usb-msc.h | 3 - src/usb-uhci.c | 91 +++++++++++++++---------------- src/virtio-blk.c | 25 +++------ src/virtio-blk.h | 2 +- src/virtio-pci.c | 33 ++++++++++-- src/virtio-pci.h | 3 +- 14 files changed, 364 insertions(+), 242 deletions(-) -- 1.7.7.1

10 years

[PATCH 0/3] Additional USB fixes

by Kevin O'Connor

This series ports Paolo's uhci fixes to the ehci code. Unfortunately, I'm still seeing an occasional hang with my flash drives on my e350m1 (ehci controller), so there's still some other bug lurking in the ehci code. I also noticed an error in the usb-uhci (missing GET_FLATPTR) which is also in this series. Kevin O'Connor (3): usb-uhci: Be sure to wrap pipe->iobase in GET_FLATPTR(). usb-ehci: Convert ehci_wait_qh to ehci_wait_pipe. usb-ehci: Fix race with host controller. src/usb-ehci.c | 70 ++++++++++++++++++++++++------------------------------- src/usb-uhci.c | 7 +++-- 2 files changed, 35 insertions(+), 42 deletions(-) -- 1.7.6.4

10 years

Booting from USB cdrom device doesn't work

by Sven Schnelle

Hi List, i have seabios running on a Thinkpad T60 with coreboot and seabios as Payload. When trying to boot from a USB cdrom, i get the following errors: Booting from DVD/CD... wait_td error - status=184007ff uhci_send_bulk failed USB transmission failed wait_td error - status=184007ff uhci_send_bulk failed USB transmission failed WARNING - Timeout at wait_td:427! uhci_send_bulk failed USB transmission failed WARNING - Timeout at wait_td:427! uhci_send_bulk failed USB transmission failed read capacity failed atapi_is_ready returned -1 WARNING - Timeout at wait_td:427! uhci_send_bulk failed USB transmission failed Boot failed: Could not read from CDROM (code 0003) I have no knowledge about USB, so if anybody could help me in interpreting those messages, or has an other idea what the problem is, that would be great. Thanks, Sven

10 years

[PATCH] USB-MSC: Support multiple LUN devices

by Sven Schnelle

Add suport for using USB storage devices with multiple LUNs. One example for such a device is the HAGIWARA UDRW stick, which has one LUN that simulates a cdrom device, and one that acts like a disk device. Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/usb-msc.c | 146 +++++++++++++++++++++++++++++++++++++++----------------- 1 files changed, 101 insertions(+), 45 deletions(-) diff --git a/src/usb-msc.c b/src/usb-msc.c index deccf35..bf5dce8 100644 --- a/src/usb-msc.c +++ b/src/usb-msc.c @@ -16,6 +16,7 @@ struct usbdrive_s { struct drive_s drive; struct usb_pipe *bulkin, *bulkout; + int lun; }; @@ -53,14 +54,32 @@ usb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize) if (!CONFIG_USB_MSC) return 0; -restart: - dprintf(16, "usb_cmd_data id=%p write=%d count=%d bs=%d buf=%p\n" - , op->drive_g, 0, op->count, blocksize, op->buf_fl); struct usbdrive_s *udrive_g = container_of( op->drive_g, struct usbdrive_s, drive); struct usb_pipe *bulkin = GET_GLOBAL(udrive_g->bulkin); struct usb_pipe *bulkout = GET_GLOBAL(udrive_g->bulkout); struct cdbres_request_sense sense; + int lun = GET_GLOBAL(udrive_g->lun); + unsigned char *data = (unsigned char *)cdbcmd; + +restart: + dprintf(16, "usb_cmd_data lun=%d id=%p write=%d count=%d bs=%d buf=%p\n" + , lun, op->drive_g, 0, op->count, blocksize, op->buf_fl); + + /* some SCSI commands have the LUN in CDB */ + if (data[0] == 0x08 || // READ(6) + data[0] == 0x12 || // INQUIRY + data[0] == 0x15 || // MODE SELECT(6) + data[0] == 0x55 || // MODE SELECT(10) + data[0] == 0x1A || // MODE SENSE(6) + data[0] == 0x28 || // READ(10) + data[0] == 0x1B || // START STOP UNIT(6) + data[0] == 0x25 || // READ CAPACITY + data[0] == 0x03 // REQUEST SENSE + ) { + data[1] &= ~0x10; + data[1] |= (lun & 7) << 5; + } // Setup command block wrapper. u32 bytes = blocksize * op->count; @@ -70,7 +89,7 @@ restart: cbw.dCBWTag = 999; // XXX cbw.dCBWDataTransferLength = bytes; cbw.bmCBWFlags = USB_DIR_IN; // XXX - cbw.bCBWLUN = 0; // XXX + cbw.bCBWLUN = lun; cbw.bCBWCBLength = USB_CDB_SIZE; memcpy(cbw.CBWCB, cdbcmd, USB_CDB_SIZE); @@ -199,44 +218,36 @@ setup_drive_hd(struct disk_op_s *op, char *desc) return 0; } -// Configure a usb msc device. -int -usb_msc_init(struct usb_pipe *pipe - , struct usb_interface_descriptor *iface, int imax) +static int +usb_msc_maxlun(struct usb_pipe *pipe, unsigned char *maxlun) { - if (!CONFIG_USB_MSC) - return -1; - - // Verify right kind of device - if ((iface->bInterfaceSubClass != US_SC_SCSI && - iface->bInterfaceSubClass != US_SC_ATAPI_8070 && - iface->bInterfaceSubClass != US_SC_ATAPI_8020) - || iface->bInterfaceProtocol != US_PR_BULK) { - dprintf(1, "Unsupported MSC USB device (subclass=%02x proto=%02x)\n" - , iface->bInterfaceSubClass, iface->bInterfaceProtocol); - return -1; - } + struct usb_ctrlrequest req; + req.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE; + req.bRequest = 0xfe; + req.wValue = 0; + req.wIndex = 0; + req.wLength = 1; + return send_default_control(pipe, &req, maxlun); +} +static int usb_msc_init_lun(struct usb_pipe *inpipe, + struct usb_pipe *outpipe, + struct usb_interface_descriptor *iface, + int lun) +{ // Allocate drive structure. struct usbdrive_s *udrive_g = malloc_fseg(sizeof(*udrive_g)); if (!udrive_g) { - warn_noalloc(); - goto fail; + warn_noalloc(); + return -1; } + memset(udrive_g, 0, sizeof(*udrive_g)); udrive_g->drive.type = DTYPE_USB; + udrive_g->lun = lun; - // Find bulk in and bulk out endpoints. - struct usb_endpoint_descriptor *indesc = findEndPointDesc( - iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_IN); - struct usb_endpoint_descriptor *outdesc = findEndPointDesc( - iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_OUT); - if (!indesc || !outdesc) - goto fail; - udrive_g->bulkin = alloc_bulk_pipe(pipe, indesc); - udrive_g->bulkout = alloc_bulk_pipe(pipe, outdesc); - if (!udrive_g->bulkin || !udrive_g->bulkout) - goto fail; + udrive_g->bulkin = inpipe; + udrive_g->bulkout = outpipe; // Validate drive and find block size and sector count. struct disk_op_s dop; @@ -245,10 +256,10 @@ usb_msc_init(struct usb_pipe *pipe struct cdbres_inquiry data; int ret = cdb_get_inquiry(&dop, &data); if (ret) - goto fail; + goto fail; if (cdb_start_stop_unit(&dop, 0, 1)) - goto fail; + goto fail; char vendor[sizeof(data.vendor)+1], product[sizeof(data.product)+1]; char rev[sizeof(data.rev)+1]; @@ -261,24 +272,69 @@ usb_msc_init(struct usb_pipe *pipe int pdt = data.pdt & 0x1f; int removable = !!(data.removable & 0x80); dprintf(1, "USB MSC vendor='%s' product='%s' rev='%s' type=%d removable=%d\n" - , vendor, product, rev, pdt, removable); + , vendor, product, rev, pdt, removable); udrive_g->drive.removable = removable; if (pdt == USB_MSC_TYPE_CDROM) { - char *desc = znprintf(MAXDESCSIZE, "DVD/CD [USB Drive %s %s %s]" - , vendor, product, rev); - ret = setup_drive_cdrom(&dop, desc); + char *desc = znprintf(MAXDESCSIZE, "DVD/CD [USB Drive %s %s %s]" + , vendor, product, rev); + ret = setup_drive_cdrom(&dop, desc); } else { - char *desc = znprintf(MAXDESCSIZE, "USB Drive %s %s %s" - , vendor, product, rev); - ret = setup_drive_hd(&dop, desc); + char *desc = znprintf(MAXDESCSIZE, "USB Drive %s %s %s" + , vendor, product, rev); + ret = setup_drive_hd(&dop, desc); } if (ret) - goto fail; + goto fail; return 0; -fail: - dprintf(1, "Unable to configure USB MSC device.\n"); + fail: free(udrive_g); return -1; } + +// Configure a usb msc device. +int +usb_msc_init(struct usb_pipe *pipe + , struct usb_interface_descriptor *iface, int imax) +{ + unsigned char maxlun, lun; + + if (!CONFIG_USB_MSC) + return -1; + + // Verify right kind of device + if ((iface->bInterfaceSubClass != US_SC_SCSI && + iface->bInterfaceSubClass != US_SC_ATAPI_8070 && + iface->bInterfaceSubClass != US_SC_ATAPI_8020) + || iface->bInterfaceProtocol != US_PR_BULK) { + dprintf(1, "Unsupported MSC USB device (subclass=%02x proto=%02x)\n" + , iface->bInterfaceSubClass, iface->bInterfaceProtocol); + return -1; + } + + // Find bulk in and bulk out endpoints. + struct usb_endpoint_descriptor *indesc = findEndPointDesc( + iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_IN); + struct usb_endpoint_descriptor *outdesc = findEndPointDesc( + iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_OUT); + + if (!indesc || !outdesc) + return -1; + + struct usb_pipe *inpipe = alloc_bulk_pipe(pipe, indesc); + if (!inpipe) + return -1; + + struct usb_pipe *outpipe = alloc_bulk_pipe(pipe, outdesc); + if (!outpipe) + return -1; + + if (usb_msc_maxlun(pipe, &maxlun)) + maxlun = 0; + + for (lun = 0; lun < maxlun+1; lun++) + usb_msc_init_lun(inpipe, outpipe, iface, lun); + + return 0; +} -- 1.7.7

10 years

[RFC PATCH 00/16] make SCSI layer more generic, introduce virtio-scsi driver

by Paolo Bonzini

Hi all, this is the first bit of working code for the mythical virtio-scsi HBA. This patch mostly aims at making code more generic in SeaBIOS for both SCSI and virtio. For SCSI, it introduces common bits for LUN detection and fixes some bugs. This is visible for example in that I can now boot the FreeDOS image on bochs.sf.net from a USB drive. For virtio, it adds a few extra interface bits that are common to both virtio-scsi and virtio-blk. The final patch adds the virtio-scsi code itself. I think the first 13 patches can go in before the virtio-scsi QEMU code, anyway I'm sending now the whole batch for review. Paolo Bonzini (16): cdrom: use TEST UNIT READY to detect ready medium usb-msc: add usb_msc_send usb-uhci: wait tick after sending data usb-msc: support WRITE and TEST UNIT READY usb-msc: move READ CAPACITY to usb_msc_init, fix off-by-one usb-msc: pass drive to setup_drive_* usb-msc: rename INQUIRY types usb-msc: always go through TEST UNIT READY usb-msc: move common scsi code to blockcmd.c scsi: get physical chs geometry from mode page 0x04 always specify virtio-blk rather than virtio virtio-pci: introduce vp_init_simple virtio-pci: allocate vq in vp_find_vq virtio-pci: add vp_set usb-msc: move cdb dispatch to block.c add virtio-scsi driver Makefile | 2 +- src/Kconfig | 10 ++- src/block.c | 35 +++++++-- src/blockcmd.c | 155 ++++++++++++++++++++++++++++++++++++++ src/blockcmd.h | 42 ++++++++++- src/boot.c | 14 ++++ src/boot.h | 1 + src/cdrom.c | 58 +-------------- src/disk.c | 5 +- src/disk.h | 19 +++-- src/pci_ids.h | 1 + src/post.c | 2 + src/usb-msc.c | 132 ++++++++++---------------------- src/usb-msc.h | 3 - src/usb-uhci.c | 1 + src/virtio-blk.c | 30 +++----- src/virtio-blk.h | 2 +- src/virtio-pci.c | 33 +++++++- src/virtio-pci.h | 13 +++- src/virtio-scsi.c | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++ src/virtio-scsi.h | 43 +++++++++++ 21 files changed, 620 insertions(+), 197 deletions(-) create mode 100644 src/virtio-scsi.c create mode 100644 src/virtio-scsi.h -- 1.7.7.1

10 years

Re: [SeaBIOS] [Xen-devel] Re: [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820

by Keir Fraser

On 14/11/2011 19:25, "Julian Pidancet" <julian.pidancet(a)gmail.com> wrote: > On Mon, Nov 14, 2011 at 1:23 PM, Keir Fraser <keir(a)xen.org> wrote: >> On 14/11/2011 08:53, "Keir Fraser" <keir.xen(a)gmail.com> wrote: >> >>> On 14/11/2011 03:36, "Kevin O'Connor" <kevin(a)koconnor.net> wrote: >>> >>>> On Xen, the PCI init code isn't used, so assuming this struct doesn't >>>> need to live in real "ram", I think it could live just about anywhere >>>> past the end of ram. Even with pciinit.c, addresses over 0xfc00000 >>>> (with the exception of a few bytes for hpet, apic, ioapic, and bios >>>> image) could be used. >>> >>> I suggest we stick it at FC000000, and shift hvmloader's mem_alloc() >>> starting address up by one page to FC001000. The acpi build code will have >>> to manually mem_hole_populate_ram() that one page before writing to it. This >>> can then be documented in hvmloader/config.h which contains a description >>> of, and defines for, the system memory map. This is by far the easiest >>> solution to this problem; manually crafting an SSDT is a right pain in the >>> arse, whereas this is maybe a 5-line patch. >> >> Like the attached patch (untested), which is a bit larger than anticipated, >> but actually allows code to be net deleted. :-) >> > > I just tested your patch with Windows 7 and Linux guest booted from iPXE. > > Everything seems to work fine. SeaBIOS reports the following e820: > > (XEN) HVM23: e820 map has 6 items: > (XEN) HVM23: 0: 0000000000000000 - 000000000009f400 = 1 RAM > (XEN) HVM23: 1: 000000000009f400 - 00000000000a0000 = 2 RESERVED > (XEN) HVM23: 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > (XEN) HVM23: 3: 0000000000100000 - 000000003f7ff000 = 1 RAM > (XEN) HVM23: 4: 000000003f7ff000 - 000000003f800000 = 2 RESERVED > (XEN) HVM23: 5: 00000000fc000000 - 0000000100000000 = 2 RESERVED > > The ACPI code in Linux reports the right PCI memory window: > > [ 0.338966] PCI: Using host bridge windows from ACPI; if necessary, > use "pci=nocrs" and report a bug > [ 0.340000] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) > [ 0.341029] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] > [ 0.341965] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] > [ 0.342965] pci_root PNP0A03:00: host bridge window [mem > 0x000a0000-0x000bffff] > [ 0.343965] pci_root PNP0A03:00: host bridge window [mem > 0xf0000000-0xfbffffff] > > Can you ship it ? Done. Xen-unstable:24143 Thanks, Keir

10 years

Re: [SeaBIOS] [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820

by Kevin O'Connor

On Mon, Nov 14, 2011 at 02:48:28AM +0000, Julian Pidancet wrote: > On Mon, Nov 14, 2011 at 2:09 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > Why does it have to be at a fixed location? What structure is > > actually placed at this address? > > Xen's hvmloader automatically computes the size of the PCI memory and > stores the PCI memory range adresses in that structure. It also > provide information about wether some devices are present (uart, hpet, > ect...). The ACPI code that we inject in the guest has the address of > this structure hardcoded, and it contains some tricks to make the AML > interpreter go read the values contained in it, and take action to > expose the right information to the guest OS. Like the right PCI root > window for example. > > I'm not at all an ACPI expert, I don't know if there's a better way to > expose to the guest the right information. Unfortunately, there aren't very many places to put a hardcoded address. The safest thing is probably to dynamically generate an SSDT with a pointer - then the DSDT can use the pointer instead of a hardcoded address. This is more work, however. > > The AML interpreter should be able to see all of ram, so that doesn't > > seem like an issue. > > Like I said, I'm not an ACPI expert. But let say we decide to move > this ACPI info structure to some other area, where there's less risk > for it to be overwritten, like somewhere above 0xFC000000, wouldn't > that prevent some Operating System with limited memory capabilities to > access it ? If the OS can handle AML it can handle 32bit addresses. > Besides, it seems that SeaBIOS manages itself the space between > 0xFC000000 and 4G, so it seems difficult to imagine to have a reserved > space with a fixed address in there. On Xen, the PCI init code isn't used, so assuming this struct doesn't need to live in real "ram", I think it could live just about anywhere past the end of ram. Even with pciinit.c, addresses over 0xfc00000 (with the exception of a few bytes for hpet, apic, ioapic, and bios image) could be used. -Kevin

10 years

Re: [SeaBIOS] PCI Option ROM debugging with Coreboot+SeaBIOS (detailed steps)

by Darmawan Salihun

However, there is one area which it lacks. The PnP function supported by SeaBIOS at the moment is only related to PXE boot. -Darmawan On 11/14/11, QingPei Wang <wangqingpei(a)gmail.com> wrote: > you may need another firmware to do the init things of hardware which > coreboot did > > > > Best wishes > QingPei Wang > Phone: 86+018930528086 > > > 2011/11/13 WangXiao <cw1501(a)hotmail.com> > >> That's a good way for debugging, >> >> ...I have a question, can SeaBIOS use on real board seperatly without >> Coreboot? >> Thanks! >> >> > Date: Sat, 12 Nov 2011 15:41:15 +0700 >> > From: darmawan.salihun(a)gmail.com >> > To: coreboot(a)coreboot.org >> > CC: seabios(a)seabios.org >> > Subject: [SeaBIOS] PCI Option ROM debugging with Coreboot+SeaBIOS >> (detailed steps) >> >> > >> > I made a blogpost detailing the steps to debug PCI Option ROM with >> > Coreboot+SeaBIOS and a GDB-server-compatible debugger: >> > >> > http://bioshacking.blogspot.com/search/label/PCI%20Option%20ROM >> > >> > Hopefully would help those in need because it takes quite a while to >> > get it right. >> > Thanks to Kevin O'Connor for the helps :-) >> > >> > Regards, >> > >> > Darmawan >> > -- >> > -------------------------------------------------------------------- >> > -= Human knowledge belongs to the world =- >> > >> > _______________________________________________ >> > SeaBIOS mailing list >> > SeaBIOS(a)seabios.org >> > http://www.seabios.org/mailman/listinfo/seabios >> >> _______________________________________________ >> SeaBIOS mailing list >> SeaBIOS(a)seabios.org >> http://www.seabios.org/mailman/listinfo/seabios >> >> > -- -------------------------------------------------------------------- -= Human knowledge belongs to the world =-

10 years

Re: [SeaBIOS] [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820

by Kevin O'Connor

On Mon, Nov 14, 2011 at 02:03:38AM +0000, Julian Pidancet wrote: > On Mon, Nov 14, 2011 at 1:11 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > > > That wont work reliably - SeaBIOS (and option roms) can grow the EBDA. > > It's not realistic to put a whole in the middle of the first 640k. > > > > When you say "grow" do you mean grow downwards ? Because if not, the > ACPI info structure lives in 9F000, so there shouldn't be any problem > reporting the 0-9F000 range as the memory size in the BDA. Yes - the EBDA grows down. Both SeaBIOS itself can grow the EBDA (see pmm.c:zonelow_expand) and option roms can grow the EBDA. > > As above, this doesn't look right - SeaBIOS will still locate the EBDA > > at 9fc00 and nothing will stop it from growing it over the 9f000 area. > > > > The EBDA is a standard bios structure, can't we safely assume that > it's size will hardly change ? If not, would you suggest that this > ACPI info structure should be placed at a different location ? The > problem with this is that it has to be in a location with a fixed > address, and preferably in a location which is accessible by any AML > interpreter. Why does it have to be at a fixed location? What structure is actually placed at this address? The AML interpreter should be able to see all of ram, so that doesn't seem like an issue. -Kevin

10 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS November 2011