SeaBIOS August 2012

seabios@seabios.org

28 participants
80 discussions

Re: [SeaBIOS] How much RAM is required?
by Markus Armbruster 10 Aug '12

10 Aug '12

Frediano Ziglio <frediano.ziglio(a)citrix.com> writes: > On Fri, 2012-08-10 at 16:24 +0200, Peter Stuge wrote: >> Fred . wrote: >> > No, I am not. >> >> Ok, so there's only a hypothesis. >> >> >> > But I believe QEMU does have the functionality to load an arbitrary >> > firmware. So the firmware doesn't necessarily have to be SeaBIOS. >> >> As you may know the 8086 reset vector is at 1MB-16 so it will be >> really difficult to run a PC-like machine with less than 1MB of >> memory. I don't believe one has ever existed. >> > > I remember that my manual of the NEC V20 (a 8086 clone with 10 MHZ!) has > settings for 256KB of RAM (jumpers of course!) > > The ROM was "mapped" (physically!) at f0000 with extended ROM at e0000. According to Wikipedia, the original IBM PC was sold with as little as 16KiB RAM. IIRC, 64KiB BIOS ROM at the top of the 1MiB address space. http://en.wikipedia.org/wiki/IBM_PC [...]

2 1

Re: [SeaBIOS] How much RAM is required?
by Peter Stuge 10 Aug '12

10 Aug '12

Fred . wrote: > No, I am not. Ok, so there's only a hypothesis. > But I believe QEMU does have the functionality to load an arbitrary > firmware. So the firmware doesn't necessarily have to be SeaBIOS. As you may know the 8086 reset vector is at 1MB-16 so it will be really difficult to run a PC-like machine with less than 1MB of memory. I don't believe one has ever existed. > Don't know if its possible to make QEMU use an UEFI or OpenFirmware > image instead, or if such an image exists. Sure, but UEFI rather requires 1GB than 1MB. //Peter

2 1

Re: [SeaBIOS] How much RAM is required?
by Peter Stuge 09 Aug '12

09 Aug '12

Fred . wrote: > But QEMU may use other firmware/payload than SeaBIOS which might > require less than 1 MB of RAM. Really? Are you working on one? //Peter

2 1

How much RAM is required?
by Markus Armbruster 09 Aug '12

09 Aug '12

Watch this: $ qemu-system-x86_64 -nodefaults -vnc :0 -monitor stdio -m 16k QEMU 1.1.50 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000000004000 Admittedly a silly thing to try. I don't really expect SeaBIOS to work with 16KiB of RAM. But I'm curious: how much does it require?

3 4

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Kevin O'Connor 08 Aug '12

08 Aug '12

On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote: > This is very interesting. If I understand correctly, you are using a > utility plus various directives to generate tables of AML offsets -- > presumably in order to dynamically change AML values, correct? Yes - exactly. We started off completely generating the SSDT dynamically, but that got awkward when we needed to generate Processor objects dynamically. So, we compiled an SSDT as template and then patched it. It was fragile to hard-code the offsets, so a tool was written to parse the IASL output and generate the offsets automatically. I'm CC'ing the coreboot list - they have also been doing SSDT runtime generation. > I have to say that I have not seen anything like this, from any BIOS vendor. > > > By the way, is there interest in adding some of the functionality that > > we get by parsing the listing to iasl directly? > > We are always interested in adding features to make the compiler > more useful. What would you suggest? The tool currently generates offsets and can rename the Amlcode[] variable to something more unique. I'm sure additional features could be thought up. -Kevin

2 1

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Gleb Natapov 08 Aug '12

08 Aug '12

On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote: > This is very interesting. If I understand correctly, you are using a utility plus various directives to generate tables of AML offsets -- presumably in order to dynamically change AML values, correct? > Yes. > I have to say that I have not seen anything like this, from any BIOS vendor. > Physical HW is not as dynamic (if at all) as virtualized one. We do not want to have separate AML table for each possible HW configuration user can create while starting QEMU. > > By the way, is there interest in adding some of the functionality that > > we get by parsing the listing to iasl directly? > > We are always interested in adding features to make the compiler more useful. What would you suggest? > The tool depends on the compiler output and thus fragile. It broke with new compiler version. It would be nice if compiler had a way to generate offsets for us. > Bob > > > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst@redhat.com] > > Sent: Sunday, August 05, 2012 1:45 PM > > To: Moore, Robert > > Cc: Idwer Vollering; Kevin O'Connor; seabios(a)seabios.org; Tang, Feng > > Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with > > its ACPI code > > > > On Sun, Aug 05, 2012 at 11:36:15PM +0300, Michael S. Tsirkin wrote: > > > On Mon, Jul 30, 2012 at 07:42:48PM +0000, Moore, Robert wrote: > > > > Yes, you are correct, the listing no longer includes the comments. > > > > > > > > Sorry for causing you a problem. > > > > > > > > What is happening is that the preprocessor parser is stripping the > > comments during the creation of the .i file. Then, the compiler is > > invoked on the .i file -- thus, the comments are gone. > > > > > > > > This is going to take a bit of work to correct, but we will do it. > > > > > > > > In the meantime, try using the -Pn flag to disable the > > preprocessor. When this flag is set, the preprocessor is completely > > bypassed and the compiler should function as it did previously. > > > > > > > > > So we are doing it this way meanwhile. If you change this > > > preprocessor behaviour like you indicated you would, please let us > > > know so e can test. > > > > > > Thanks! > > > > By the way, is there interest in adding some of the functionality that > > we get by parsing the listing to iasl directly? > > Here's what our tool currently supports: > > > > # Process mixed ASL/AML listing (.lst file) produced by iasl -l # > > Locate and execute ACPI_EXTRACT directives, output offset info # # > > Documentation of ACPI_EXTRACT_* directive tags: > > # > > # These directive tags output offset information from AML for BIOS > > runtime # table generation. > > # Each directive is of the form: > > # ACPI_EXTRACT_<TYPE> <array_name> <Operator> (...) # and causes the > > extractor to create an array # named <array_name> with offset, in the > > generated AML, # of an object of a given type in the following > > <Operator>. > > # > > # A directive must fit on a single code line. > > # > > # Object type in AML is verified, a mismatch causes a build failure. > > # > > # Directives and operators currently supported are: > > # ACPI_EXTRACT_NAME_DWORD_CONST - extract a Dword Const object from > > Name() # ACPI_EXTRACT_NAME_WORD_CONST - extract a Word Const object > > from Name() # ACPI_EXTRACT_NAME_BYTE_CONST - extract a Byte Const > > object from Name() # ACPI_EXTRACT_METHOD_STRING - extract a NameString > > from Method() # ACPI_EXTRACT_NAME_STRING - extract a NameString from > > Name() # ACPI_EXTRACT_PROCESSOR_START - start of Processor() block # > > ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from Processor() # > > ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processor() + 1 # > > ACPI_EXTRACT_PKG_START - start of Package block # # > > ACPI_EXTRACT_ALL_CODE - create an array storing the generated AML > > bytecode # # ACPI_EXTRACT is not allowed anywhere else in code, except > > in comments. > > > > > > Example: > > > > ACPI_EXTRACT_NAME_DWORD_CONST aml_adr_dword > > Name (_ADR, 0x00010000) > > > > adds the offset of 0x00010000 constant to array aml_adr_dword > > > > Example: > > > > ACPI_EXTRACT_METHOD_STRING aml_ej0_name > > Method (_EJ0, 1) { Return(PCEJ(0x0001)) } > > > > adds the offset of _EJ0 string to array aml_ej0_name > > > > ACPI_EXTRACT_ALL_CODE ssdp_pcihp_aml > > > > names the array to include the generated AML code > > > > -- > > MST > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios -- Gleb.

2 1

SeaBIOS "latest updates" broken for few weeks
by Alec Ari 08 Aug '12

08 Aug '12

Hi, I've been wanting to monitor the source code changes to SeaBIOS via web browser and lately I haven't been able to. For the past few months the occasional "unable to allocate memory for pool" error would show up, but generally after hitting the refresh button 10 to 15 times would fix the problem when browsing the following site: http://code.coreboot.org/p/seabios/ During the past few weeks however, the "latest updates" link has been broken. The error I get is: PlufErrorHandlerException making GET request to /p/seabios/timeline/all/ 8 : Undefined offset: 1 PHP/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Cache/File.php, line 102 URIGET /p/seabios/timeline/all/ Here is the stacktrace: PlufErrorHandler [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Cache/File.php, line 102] Pluf_Cache_File->get [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/src/IDF/Scm.php, line 473] IDF_Scm::syncTimeline [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/src/IDF/Views/Project.php, line 121] IDF_Views_Project::determineModelClasses [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/src/IDF/Views/Project.php, line 182] IDF_Views_Project->timeline [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Dispatcher.php, line 202] Pluf_Dispatcher::send [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Dispatcher.php, line 129] Pluf_Dispatcher::match [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Dispatcher.php, line 56] Pluf_Dispatcher::dispatch [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/www/index.php, line 28] Is it just me or is this a global problem? Checking out the source code via git and using "git log" works and has never been an issue for me. I just wanted to point this problem out as I am not sure this is a known issue. Thanks! -Alec

4 3

[PATCH v2] scsi: add AMD PCscsi driver
by Paolo Bonzini 07 Aug '12

07 Aug '12

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> --- 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 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/esp-scsi.h b/src/esp-scsi.h new file mode 100644 index 0000000..dc555f3 --- /dev/null +++ b/src/esp-scsi.h @@ -0,0 +1,8 @@ +#ifndef __ESP_SCSI_H +#define __ESP_SCSI_H + +struct disk_op_s; +int esp_scsi_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize); +void esp_scsi_setup(void); + +#endif /* __ESP_SCSI_H */ 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.11.2

2 1

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Michael S. Tsirkin 07 Aug '12

07 Aug '12

On Mon, Jul 30, 2012 at 07:42:48PM +0000, Moore, Robert wrote: > Yes, you are correct, the listing no longer includes the comments. > > Sorry for causing you a problem. > > What is happening is that the preprocessor parser is stripping the comments during the creation of the .i file. Then, the compiler is invoked on the .i file -- thus, the comments are gone. > > This is going to take a bit of work to correct, but we will do it. > > In the meantime, try using the -Pn flag to disable the preprocessor. When this flag is set, the preprocessor is completely bypassed and the compiler should function as it did previously. So we are doing it this way meanwhile. If you change this preprocessor behaviour like you indicated you would, please let us know so e can test. Thanks! -- MST

2 2

Re: [SeaBIOS] UHCI on US15W: Crazy stuff happening
by Peter Stuge 07 Aug '12

07 Aug '12

Matthew Millman wrote: > 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! Yay! Please send a patch. It may not go in as-is, but it's a good help for looking deeper into the issue. //Peter

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS August 2012