SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] Linux-ready Firmware Kit does not work?
by Peter Stuge 17 Jun '12

17 Jun '12

Fred . wrote: > when I tried it under QEMU it did not work So what happens? What does the serial debug log look like? If you don't provide details about the problem it is impossible to give any advice. Please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html //Peter

2 1

Re: [SeaBIOS] Linux-ready Firmware Kit does not work?
by ron minnich 17 Jun '12

17 Jun '12

you have to take the firmware kit with a bit of skepticism however. We found things that contradicted other douments ... ron

1 0

Linux-ready Firmware Kit does not work?
by Fred . 17 Jun '12

17 Jun '12

http://phoronix.com/forums/showthread.php?59218-DB-BIOS-ACPI-data-collecting A guy collect output of the Linux-ready Firmware Kit and aggregates the results into a online document. https://spreadsheets.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0ArD2… Intel provides a Linux-ready Firmware Kit, available on a LiveCD (79 MB) ( http://linuxfirmwarekit.org/download/firmwarekit-r3.iso ). You only have to launch it, wait 1 or 2 minutes, and there is a summary of the results based on different topics (memory handling, PCI resources, HPET, ACPI tables, and more). The results is a number of "Fail", "Warn" and "Pass" flags. This Linux-ready Firmware Kit seems to not be developed anymore, but I guess it can give us a idea of the quality of the BIOS. But when I tried it under QEMU it did not work. Anyone know why the Linux-ready Firmware Kit does not work? Is it SeaBIOS fault or QEMU fault or KVM fault? Maybe would nice if it worked to assess the quality of SeaBIOS.

1 0

Problem accessing a small virtio disk
by Gleb Natapov 15 Jun '12

15 Jun '12

I noticed that SeaBIOS fails to boot from virtio disk smaller than 512K. The attempt to access a disk fails at basic_access(). (cylinder >= nlc || head >= nlh || sector > nlspt) is true because nlc is zero. The problem seams to be in how SeaBIOS calculates lchs from pchs in get_translation(). Both QEMU and SeaBIOS fake disk geometry from real disk size, but it seams that they do it differently and when they disagree part of the disk may not be readable. What would be the best way to fix that? -- Gleb.

3 4

BIOS calls in 16bit protected mode
by Kevin O'Connor 14 Jun '12

14 Jun '12

Hi, I am trying to determine if there are legacy applications or operating systems that invoke standard BIOS real-mode interrupt handlers while in 16bit protected mode. (The legacy real-mode entry points - like "int 0x13" - not the declared 16bit protected mode entry points defined by the PnP and APM specs.) I am considering changes to SeaBIOS that would make 16bit protected mode callers much less likely to work. (Specifically, enhancing SeaBIOS to use memory in the e-segment which is unlikely to be mapped in protected mode.) Most documents I've seen state that calling the real-mode entry points in protected mode will not work. Though, I am aware that the PCI BIOS spec specifically requires this support for calls to "int 0x1a ah=0xb1". The advantage of making these changes is that it will allow SeaBIOS to use notably less stack space and therefore be more compatible with old applications that call the BIOS with very little stack space. For example, these changes enable DOS 1.0 to boot and run under SeaBIOS. What would really help is pointers to applications and/or program images that use 16bit protected mode calls to real-mode entry points. Specifications or documents detailing valid or invalid uses would also be helpful. For those that are willing to run tests, one can compare the standard SeaBIOS v1.7.0 image (for KVM/QEMU) at: http://git.seabios.org/downloads/get/bios.bin-1.7.0.gz to a test image with the new code at: http://git.seabios.org/downloads/get/bios.bin-test-20120613.gz Thanks, -Kevin

3 3

[RFC][PATCH 0/2] Use extra stack for all regular real-mode entry points
by Kevin O'Connor 14 Jun '12

14 Jun '12

This simple series changes SeaBIOS to use its extra stack for all regular real-mode software interrupt entry points. This has the advantage of using significantly less stack space, which can make old programs more likely to run. As an example, SeaBIOS can boot and run DOS 1.0 with this series applied. However, by using the extra stack (which resides in the e-segment), the code will likely not work for any code that invokes the real-mode software interrupts while in 16bit protected mode. I don't believe that is common, but it is difficult to know if there are any users. I will send a separate email on that topic. -Kevin Kevin O'Connor (2): Check for and handle PCI BIOS calls separately from handle_1a path. Jump into extra stack for all regular real-mode software irq entry points. src/clock.c | 2 +- src/config.h | 2 +- src/pcibios.c | 12 ++++++++-- src/post.c | 2 +- src/romlayout.S | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++---- src/util.h | 1 - 6 files changed, 76 insertions(+), 11 deletions(-) -- 1.7.10.2

1 2

[PATCH] Support USB MSC devices with multiples LUNs
by Sven Schnelle 14 Jun '12

14 Jun '12

There are USB Mass storage devices which have more than one device. Examples are CD Changers, or USB sticks which are partitioned in a CDROM and Harddisk device. Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/usb-msc.c | 100 +++++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 28 deletions(-) diff --git a/src/usb-msc.c b/src/usb-msc.c index c53a1f5..6025a03 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; }; @@ -78,7 +79,7 @@ usb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize) cbw.dCBWTag = 999; // XXX cbw.dCBWDataTransferLength = bytes; cbw.bmCBWFlags = cdb_is_read(cdbcmd, blocksize) ? USB_DIR_IN : USB_DIR_OUT; - cbw.bCBWLUN = 0; // XXX + cbw.bCBWLUN = GET_GLOBAL(udrive_g->lun); cbw.bCBWCBLength = USB_CDB_SIZE; // Transfer cbw to device. @@ -117,6 +118,47 @@ fail: return DISK_RET_EBADTRACK; } +static int +usb_msc_maxlun(struct usb_pipe *pipe, unsigned char *maxlun) +{ + if (!CONFIG_USB_MSC) + 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 usbdevice_s *usbdev, + int lun) +{ + // Allocate drive structure. + struct usbdrive_s *udrive_g = malloc_fseg(sizeof(*udrive_g)); + if (!udrive_g) { + warn_noalloc(); + return -1; + } + memset(udrive_g, 0, sizeof(*udrive_g)); + udrive_g->drive.type = DTYPE_USB; + udrive_g->lun = lun; + + udrive_g->bulkin = inpipe; + udrive_g->bulkout = outpipe; + + if (scsi_init_drive(&udrive_g->drive, + "USB MSC", bootprio_find_usb(usbdev))) { + dprintf(1, "Unable to configure USB MSC device.\n"); + free(udrive_g); + return -1; + } + return 0; +} /**************************************************************** * Setup @@ -126,6 +168,11 @@ fail: int usb_msc_init(struct usbdevice_s *usbdev) { + struct usb_pipe *inpipe = NULL, *outpipe = NULL; + struct usb_endpoint_descriptor *indesc, *outdesc; + unsigned char maxlun, lun; + int pipesused = 0; + if (!CONFIG_USB_MSC) return -1; @@ -140,39 +187,36 @@ usb_msc_init(struct usbdevice_s *usbdev) return -1; } - // Allocate drive structure. - struct usbdrive_s *udrive_g = malloc_fseg(sizeof(*udrive_g)); - if (!udrive_g) { - warn_noalloc(); - goto fail; - } - memset(udrive_g, 0, sizeof(*udrive_g)); - udrive_g->drive.type = DTYPE_USB; - // Find bulk in and bulk out endpoints. - struct usb_endpoint_descriptor *indesc = findEndPointDesc( - usbdev, USB_ENDPOINT_XFER_BULK, USB_DIR_IN); - struct usb_endpoint_descriptor *outdesc = findEndPointDesc( - usbdev, USB_ENDPOINT_XFER_BULK, USB_DIR_OUT); - if (!indesc || !outdesc) - goto fail; - udrive_g->bulkin = usb_alloc_pipe(usbdev, indesc); - udrive_g->bulkout = usb_alloc_pipe(usbdev, outdesc); - if (!udrive_g->bulkin || !udrive_g->bulkout) + if (!(indesc = findEndPointDesc(usbdev, USB_ENDPOINT_XFER_BULK, + USB_DIR_IN))) goto fail; - int prio = bootprio_find_usb(usbdev); - int ret = scsi_init_drive(&udrive_g->drive, "USB MSC", prio); - if (ret) + if (!(outdesc = findEndPointDesc(usbdev, USB_ENDPOINT_XFER_BULK, + USB_DIR_OUT))) goto fail; + if (!(inpipe = usb_alloc_pipe(usbdev, indesc))) + goto fail; + + + if (!(outpipe = usb_alloc_pipe(usbdev, outdesc))) + goto fail; + + if (usb_msc_maxlun(usbdev->defpipe, &maxlun)) + maxlun = 0; + + for(lun = 0; lun < maxlun + 1; lun++) { + if (!usb_msc_init_lun(inpipe, outpipe, usbdev, lun)) + pipesused = 1; + } + + if (!pipesused) + goto fail; + return 0; fail: - dprintf(1, "Unable to configure USB MSC device.\n"); - if (udrive_g) { - free_pipe(udrive_g->bulkin); - free_pipe(udrive_g->bulkout); - free(udrive_g); - } + free_pipe(inpipe); + free_pipe(outpipe); return -1; } -- 1.7.10

3 8

[PATCH] EHCI: Add support for 64 bit capability
by Sven Schnelle 14 Jun '12

14 Jun '12

Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/usb-ehci.c | 6 ++---- src/usb-ehci.h | 9 ++++++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/usb-ehci.c b/src/usb-ehci.c index 4cb3e6a..8267a63 100644 --- a/src/usb-ehci.c +++ b/src/usb-ehci.c @@ -334,10 +334,6 @@ ehci_init(struct pci_device *pci, int busid, struct pci_device *comppci) u32 baseaddr = pci_config_readl(bdf, PCI_BASE_ADDRESS_0); struct ehci_caps *caps = (void*)(baseaddr & PCI_BASE_ADDRESS_MEM_MASK); u32 hcc_params = readl(&caps->hccparams); - if (hcc_params & HCC_64BIT_ADDR) { - dprintf(1, "No support for 64bit EHCI\n"); - return -1; - } struct usb_ehci_s *cntl = malloc_tmphigh(sizeof(*cntl)); if (!cntl) { @@ -349,6 +345,8 @@ ehci_init(struct pci_device *pci, int busid, struct pci_device *comppci) cntl->usb.pci = pci; cntl->usb.type = USB_TYPE_EHCI; cntl->caps = caps; + if (hcc_params & HCC_64BIT_ADDR) + cntl->regs->ctrldssegment = 0; cntl->regs = (void*)caps + readb(&caps->caplength); dprintf(1, "EHCI init on dev %02x:%02x.%x (regs=%p)\n" diff --git a/src/usb-ehci.h b/src/usb-ehci.h index b295c78..924bbd8 100644 --- a/src/usb-ehci.h +++ b/src/usb-ehci.h @@ -102,7 +102,7 @@ struct ehci_qh { u32 alt_next; u32 token; u32 buf[5]; - // u32 buf_hi[5]; + u32 buf_hi[5]; } PACKED; #define QH_CONTROL (1 << 27) @@ -140,8 +140,11 @@ struct ehci_qtd { u32 alt_next; u32 token; u32 buf[5]; - //u32 buf_hi[5]; -} PACKED; + u32 buf_hi[5]; + /* keep struct size a multiple of 32 Bytes, as we're allocating + arrays. Without this padding, the second qtd would have the + wrong alignment. */ +} PACKED __aligned(32); #define QTD_TOGGLE (1 << 31) #define QTD_LENGTH_SHIFT 16 -- 1.7.10

2 6

[PATCH] pci: runtime i/o window sizing
by Gerd Hoffmann 14 Jun '12

14 Jun '12

Update the pci i/o windows at runtime, depending on the amount memory the machine has. The 32bit window starts above low memory and ends at the ioapic map address, the 64bit window is placed above high memory. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/pciinit.c | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) diff --git a/src/pciinit.c b/src/pciinit.c index dc33f83..68f302a 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -592,6 +592,8 @@ static void pci_region_map_entries(struct pci_bus *busses, struct pci_region *r) static void pci_bios_map_devices(struct pci_bus *busses) { + pcimem_start = RamSize; + if (pci_bios_init_root_regions(busses)) { struct pci_region r64_mem, r64_pref; r64_mem.list = NULL; @@ -604,14 +606,21 @@ static void pci_bios_map_devices(struct pci_bus *busses) if (pci_bios_init_root_regions(busses)) panic("PCI: out of 32bit address space\n"); - r64_mem.base = pcimem64_start; - u64 sum = pci_region_sum(&r64_mem); - u64 align = pci_region_align(&r64_pref); - r64_pref.base = ALIGN(r64_mem.base + sum, align); - if (r64_pref.base + pci_region_sum(&r64_pref) > pcimem64_end) - panic("PCI: out of 64bit address space\n"); + u64 sum_mem = pci_region_sum(&r64_mem); + u64 sum_pref = pci_region_sum(&r64_pref); + u64 align_mem = pci_region_align(&r64_mem); + u64 align_pref = pci_region_align(&r64_pref); + + r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem); + r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref); + pcimem64_start = r64_mem.base; + pcimem64_end = r64_pref.base + sum_pref; + pci_region_map_entries(busses, &r64_mem); pci_region_map_entries(busses, &r64_pref); + } else { + // no bars mapped high -> drop 64bit window (see dsdt) + pcimem64_start = 0; } // Map regions on each device. int bus; -- 1.7.1

2 1

One ROM for multiple devices
by Steve Goodrich 13 Jun '12

13 Jun '12

Please be aware that this is cross-posted to both the SeaBIOS and coreboot mailing lists. I know this is generally frowned upon, but I believe the subject is valid for discussion in both forums. I have a coreboot/SeaBIOS image containing an option ROM that works for multiple graphics devices (seven or eight of them). These graphics devices come from the same vendor but each device has its own (unique) PCI Device ID. If I'm going to load the driver from SeaBIOS, I need to have a copy of the option ROM file, each with the name of the target PCI device (e.g. "pci1234,5678.rom"). Having seven or eight copies in the BIOS image file is a waste of space. Stefan R. submitted a solution to coreboot to enable mapping one ROM's vendor/device ID to another and this solution has worked well for coreboot-centric uses. Unfortunately, this does not address the problem in SeaBIOS. I have started working on a solution that extends what Stefan has done, but moves the data into a single "translate" file in CBFS. This file contains simple data to allow coreboot and/or SeaBIOS to take a PCI device's vendor/device info and retrieve alternate vendor/device values. Since both coreboot and SeaBIOS understand CBFS, the basic translation code would be identical. The data file consists of sets of four 16-bit binary values: u16 vendor1, device1; // translate FROM this PCI v/d u16 vendor2, device2; // translate TO this PCI v/d If you have a single ROM which could support three devices, you would have two sets of data: 0x1234, 0x0001, 0x1234, 0x0002 0x1234, 0x0001, 0x1234, 0x0003 This data would let the ROM for vendor 0x1234, device 0x0001 support devices 0x0002 and 0x0003. NOTE: there is no data for device 0x0001, since it would be handled without translation. The code would work something like this: sprintf(name, "pci%04x,%04x.rom", pci->vendor, pci->device); rom = cbfs_findfile(name); // load the file if (!rom) { // ROM not found... try translation ven = pci->vendor; dev = pci->device; if (translate_findFirst(&ven, &dev)) { do { sprintf(name, "pci%04x,%04x.rom", ven, dev); rom = cbfs_findfile(name); // load the file while ((rom == null) && translate_findNext(&ven, &dev)); } } I'm not tied to the findFirst/findNext mechanism nor to the specific format of the data. What I would like to see is some mechanism in both coreboot and SeaBIOS that would allow a given ROM to be used for multiple devices. In coreboot this would affect the map_oprom_vendev() function. In SeaBIOS this would affect both lookup_hardcode() and map_pcirom(). Since this problem exists in both codebases, is it reasonable to come up with a solution that will work in both codebases? Thoughts? -- Steve G.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS