SeaBIOS February 2016

seabios@seabios.org

21 participants
30 discussions

by Stefan Berger

This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. v2->v3: - Converted TPM_VERSION_* from enum's to #define's and removed unnecessary cases with TPM_VERSION_NONE in switch statements. - Convert the log_entry internal representation to TPM 2 native format. - Added patch that looks at command tags in the TPM_Passthrough API call and return error code in case of TPM version mismatch. v1->v2: - Addressed most of Kevin's comments. - Added patch for writing logs in TPM 2 format Stefan Stefan Berger (11): tpm: Extend TPM TIS with TPM 2 support. tpm: Factor out tpm_extend tpm: Prepare code for TPM 2 functions tpm: Implement tpm20_startup and tpm20_s3_resume tpm: Implement tpm20_set_timeouts tpm: Implement tpm20_prepboot tpm: Implement tpm20_extend tpm: Implement tpm20_menu tpm: Implement TPM 2's tpm_set_failure part tpm: Write logs in TPM 2 format Filter TPM commands in passthrough API src/hw/tpm_drivers.c | 38 ++- src/hw/tpm_drivers.h | 26 +- src/std/tcg.h | 147 +++++++++ src/tcgbios.c | 900 ++++++++++++++++++++++++++++++++++++++++++--------- 4 files changed, 961 insertions(+), 150 deletions(-) -- 2.4.3

5 years, 10 months

[PATCH 1/2] ehci: Only delay UHCI/OHCI port scan until after EHCI setup completes

by Kevin O'Connor

EHCI controller setup needs to occur prior to checking any UHCI or OHCI ports to ensure a high speed device is not mistakenly configured on a full speed "companion" controller. However, only the UHCI/OHCI port scan needs to be delayed, not the full UHCI/OHCI controller init. This change moves back the ehci controller setup check until port scan in UHCI/OHCI. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/usb-ehci.c | 8 ++++++-- src/hw/usb-ehci.h | 1 + src/hw/usb-ohci.c | 3 +++ src/hw/usb-uhci.c | 4 ++++ 4 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/hw/usb-ehci.c b/src/hw/usb-ehci.c index 41f8579..010746c 100644 --- a/src/hw/usb-ehci.c +++ b/src/hw/usb-ehci.c @@ -337,9 +337,13 @@ ehci_setup(void) if (pci_classprog(pci) == PCI_CLASS_SERIAL_USB_EHCI) ehci_controller_setup(pci); } +} - // Wait for all EHCI controllers to initialize. This forces OHCI/UHCI - // setup to always be after any EHCI ports are routed to EHCI. +// Wait for all EHCI controllers to initialize. This forces OHCI/UHCI +// setup to always be after any EHCI ports are routed to EHCI. +void +ehci_wait_controllers(void) +{ while (PendingEHCI) yield(); } diff --git a/src/hw/usb-ehci.h b/src/hw/usb-ehci.h index 88f7b6a..0442188 100644 --- a/src/hw/usb-ehci.h +++ b/src/hw/usb-ehci.h @@ -3,6 +3,7 @@ // usb-ehci.c void ehci_setup(void); +void ehci_wait_controllers(void); struct usbdevice_s; struct usb_endpoint_descriptor; struct usb_pipe; diff --git a/src/hw/usb-ohci.c b/src/hw/usb-ohci.c index 42f8a06..7ed964f 100644 --- a/src/hw/usb-ohci.c +++ b/src/hw/usb-ohci.c @@ -14,6 +14,7 @@ #include "pci_regs.h" // PCI_BASE_ADDRESS_0 #include "string.h" // memset #include "usb.h" // struct usb_s +#include "usb-ehci.h" // ehci_wait_controllers #include "usb-ohci.h" // struct ohci_hcca #include "util.h" // msleep #include "x86.h" // readl @@ -96,6 +97,8 @@ static int check_ohci_ports(struct usb_ohci_s *cntl) { ASSERT32FLAT(); + // Wait for ehci init - in case this is a "companion controller" + ehci_wait_controllers(); // Turn on power for all devices on roothub. u32 rha = readl(&cntl->regs->roothub_a); rha &= ~(RH_A_PSM | RH_A_OCPM); diff --git a/src/hw/usb-uhci.c b/src/hw/usb-uhci.c index 69c33ee..6d8aa47 100644 --- a/src/hw/usb-uhci.c +++ b/src/hw/usb-uhci.c @@ -13,6 +13,7 @@ #include "pci_regs.h" // PCI_BASE_ADDRESS_4 #include "string.h" // memset #include "usb.h" // struct usb_s +#include "usb-ehci.h" // ehci_wait_controllers #include "usb-uhci.h" // USBLEGSUP #include "util.h" // msleep #include "x86.h" // outw @@ -94,6 +95,9 @@ static int check_uhci_ports(struct usb_uhci_s *cntl) { ASSERT32FLAT(); + // Wait for ehci init - in case this is a "companion controller" + ehci_wait_controllers(); + struct usbhub_s hub; memset(&hub, 0, sizeof(hub)); hub.cntl = &cntl->usb; -- 2.5.0

5 years, 10 months

[PATCH 0/4] Some additional PCI cleanups

by Kevin O'Connor

Some additional PCI code cleanup - most notable is the first patch which adds a '%pP' modifier to the 'printf' code for outputting 'struct pci_device' pointers. This series is on top of the previous series; it is also at: https://github.com/KevinOConnor/seabios/tree/testing -Kevin Kevin O'Connor (4): pci: Implement '%pP' printf handler for 'struct pci_device' pointers pci: Move code in pci.c that is specific to pciinit.c to pciinit.c pci: Split low-level pci code from higher-level 'struct pci_device' code scsi: Always use MAXDESCSIZE when building drive description Makefile | 2 +- src/boot.c | 1 + src/fw/acpi.c | 2 +- src/fw/coreboot.c | 2 +- src/fw/csm.c | 3 +- src/fw/mptable.c | 5 +- src/fw/mtrr.c | 1 - src/fw/paravirt.c | 3 +- src/fw/pciinit.c | 63 ++++++++--- src/fw/smm.c | 1 + src/hw/ahci.c | 8 +- src/hw/ata.c | 3 +- src/hw/esp-scsi.c | 10 +- src/hw/floppy.c | 2 +- src/hw/lsi-scsi.c | 10 +- src/hw/megasas.c | 12 +-- src/hw/pci.c | 241 +----------------------------------------- src/hw/pci.h | 104 ++---------------- src/hw/{pci.c => pcidevice.c} | 137 +----------------------- src/hw/{pci.h => pcidevice.h} | 71 ++----------- src/hw/pvscsi.c | 10 +- src/hw/sdcard.c | 2 +- src/hw/usb-ehci.c | 6 +- src/hw/usb-ohci.c | 6 +- src/hw/usb-uhci.c | 7 +- src/hw/usb-xhci.c | 9 +- src/hw/virtio-blk.c | 41 +++---- src/hw/virtio-pci.c | 12 +-- src/hw/virtio-scsi.c | 15 +-- src/optionroms.c | 22 ++-- src/output.c | 19 ++++ src/pcibios.c | 1 + src/util.h | 2 + src/vgahooks.c | 3 +- 34 files changed, 173 insertions(+), 663 deletions(-) copy src/hw/{pci.c => pcidevice.c} (64%) copy src/hw/{pci.h => pcidevice.h} (59%) -- 2.5.0

5 years, 10 months

[RFC PATCH v2] fw/pci: Add support for mapping Intel IGD OpRegion via QEMU

by Alex Williamson

When assigning Intel IGD graphics via QEMU/vfio, the OpRegion for the device may be exposed as a fw_cfg file. Allocate space for this, copy the contents and write the ASL Storage register (0xFC) to point to this buffer. NB, it's possible for QEMU to use the write to the ASL Storage register to map access to the host OpRegion overlapping the allocated buffer, but we shouldn't care if it does. References: kernel vfio opregion support: https://lkml.org/lkml/2016/2/1/884 QEMU vfio opregion support (revised v2 of 7/7 adds fw_cfg): https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg00202.html Gerd's IGD assignment series: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg00244.html Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- src/fw/pciinit.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index c31c2fa..92170d5 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -257,6 +257,32 @@ static void ich9_smbus_setup(struct pci_device *dev, void *arg) pci_config_writeb(bdf, ICH9_SMB_HOSTC, ICH9_SMB_HOSTC_HST_EN); } +static void intel_igd_opregion_setup(struct pci_device *dev, void *arg) +{ + struct romfile_s *file = romfile_find("etc/igd-opregion"); + void *opregion; + u16 bdf = dev->bdf; + + if (!file || !file->size) + return; + + opregion = memalign_high(PAGE_SIZE, file->size); + if (!opregion) { + warn_noalloc(); + return; + } + + if (file->copy(file, opregion, file->size) < 0) { + free(opregion); + return; + } + + pci_config_writel(bdf, 0xFC, cpu_to_le32((u32)opregion)); + + dprintf(1, "Intel IGD OpRegion enabled on %02x:%02x.%x\n", + pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf)); +} + static const struct pci_device_id pci_device_tbl[] = { /* PIIX3/PIIX4 PCI to ISA bridge */ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0, @@ -290,6 +316,10 @@ static const struct pci_device_id pci_device_tbl[] = { PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0017, 0xff00, apple_macio_setup), PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0022, 0xff00, apple_macio_setup), + /* Intel IGD OpRegion setup */ + PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA, + intel_igd_opregion_setup), + PCI_DEVICE_END, };

5 years, 10 months

[PATCH] block: Move drive setup to new function block_setup()

by Kevin O'Connor

Move the list of drive setup calls from post.c to a new function in block.c. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/block.c | 16 ++++++++++++++++ src/block.h | 1 + src/post.c | 22 ++-------------------- 3 files changed, 19 insertions(+), 20 deletions(-) diff --git a/src/block.c b/src/block.c index b4530fc..b231c01 100644 --- a/src/block.c +++ b/src/block.c @@ -487,6 +487,22 @@ fill_edd(struct segoff_s edd, struct drive_s *drive_gf) * Disk driver dispatch ****************************************************************/ +void +block_setup(void) +{ + floppy_setup(); + ata_setup(); + ahci_setup(); + sdcard_setup(); + ramdisk_setup(); + virtio_blk_setup(); + virtio_scsi_setup(); + lsi_scsi_setup(); + esp_scsi_setup(); + megasas_setup(); + pvscsi_setup(); +} + // Fallback handler for command requests not implemented by drivers int default_process_op(struct disk_op_s *op) diff --git a/src/block.h b/src/block.h index 2ff359f..8f4c1aa 100644 --- a/src/block.h +++ b/src/block.h @@ -111,6 +111,7 @@ void map_hd_drive(struct drive_s *drive); void map_cd_drive(struct drive_s *drive); struct int13dpt_s; int fill_edd(struct segoff_s edd, struct drive_s *drive_gf); +void block_setup(void); int default_process_op(struct disk_op_s *op); int process_op(struct disk_op_s *op); int send_disk_op(struct disk_op_s *op); diff --git a/src/post.c b/src/post.c index e5fa4be..c82ab17 100644 --- a/src/post.c +++ b/src/post.c @@ -6,24 +6,17 @@ // This file may be distributed under the terms of the GNU LGPLv3 license. #include "biosvar.h" // SET_BDA +#include "block.h" // block_setup #include "bregs.h" // struct bregs #include "config.h" // CONFIG_* #include "e820map.h" // e820_add #include "fw/paravirt.h" // qemu_cfg_preinit #include "fw/xen.h" // xen_preinit -#include "hw/ahci.h" // ahci_setup -#include "hw/ata.h" // ata_setup -#include "hw/esp-scsi.h" // esp_scsi_setup -#include "hw/lsi-scsi.h" // lsi_scsi_setup -#include "hw/megasas.h" // megasas_setup -#include "hw/pvscsi.h" // pvscsi_setup #include "hw/pic.h" // pic_setup #include "hw/ps2port.h" // ps2port_setup #include "hw/rtc.h" // rtc_write #include "hw/serialio.h" // serial_debug_preinit #include "hw/usb.h" // usb_setup -#include "hw/virtio-blk.h" // virtio_blk_setup -#include "hw/virtio-scsi.h" // virtio_scsi_setup #include "malloc.h" // malloc_init #include "memmap.h" // SYMBOL #include "output.h" // dprintf @@ -136,19 +129,8 @@ device_hardware_setup(void) ps2port_setup(); lpt_setup(); serial_setup(); - - floppy_setup(); - ata_setup(); - ahci_setup(); - sdcard_setup(); + block_setup(); cbfs_payload_setup(); - ramdisk_setup(); - virtio_blk_setup(); - virtio_scsi_setup(); - lsi_scsi_setup(); - esp_scsi_setup(); - megasas_setup(); - pvscsi_setup(); } static void -- 2.5.0

5 years, 10 months

Re: [SeaBIOS] [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

by Kevin O'Connor

On Tue, Feb 02, 2016 at 09:56:20AM +0100, Gerd Hoffmann wrote: > Hi, > > > > I'd have qemu copy the data on 0xfc write then, so things continue to > > > work without updating seabios. So, the firmware has to allocate space, > > > reserve it etc., and programming the 0xfc register. Qemu has to make > > > sure the opregion appears at the address written by the firmware, by > > > whatever method it prefers. > > > > Yup. It's Qemu's responsibility to expose opregion content. > > > > btw, prefer to do copying here. It's pointless to allow write from guest > > side. One write example is SWSCI mailbox, thru which gfx driver can > > trigger some SCI event to communicate with BIOS (specifically ACPI > > methods here), mostly for some monitor operations. However it's > > not a right thing for guest to trigger host SCI and thus kick host > > ACPI methods. > > Thanks. > > So, question again how we do that best. Option one being the mmap way, > i.e. basically what the patches posted by alex are doing. Option two > being the fw_cfg way, i.e. place a opregion copy in fw_cfg and have > seabios not only set 0xfc, but also store the opregion there by copying > from fw_cfg. What about option 2a - SeaBIOS copies from fw_cfg to memory and then programs 0xfc. QEMU can detect the write to 0xfc and choose to map that ram (thus completely ignoring the contents that were just copied in) or it can choose not to map that ram (thus guest uses the contents just copied in). The advantage of this approach is that it is a bit simpler in the firmware (no size probing is needed as the size comes from fw_cfg) and it allows for future flexibility as the choice of mapping can be deferred. Totally untested seabios code below as example. As an aside, if this type of "program a pci register" with a memory address becomes common, we could enhance the acpi-style "linker script" system to automate this.. -Kevin static void intel_igd_opregion_setup(struct pci_device *dev, void *arg) { struct romfile_s *file = romfile_find("etc/igd-opregion"); if (!file) return; void *data = memalign_high(PAGE_SIZE, file->size); if (!data) { warn_noalloc(); return; } int ret = file->copy(file, data, file->size); if (ret < 0) { free(data); return; } pci_config_writel(dev->bdf, 0xFC, (u32)data); }

5 years, 10 months

[RFC PATCH] fw/pci: Add support for mapping Intel IGD OpRegion via QEMU

by Alex Williamson

The proposed IGD OpRegion support in QEMU via vfio maps the host OpRegion into VM system memory at the address written to the ASL Storage register (0xFC). The OpRegion contains a 16-byte signature followed by a 4-byte size field. Therefore SeaBIOS can allocate a buffer of the typical size (8KB), this results in a matching e820 reserved entry for the range, then write the buffer address to the ASL Storage register, blinking the OpRegion into the VM address space. At that point SeaBIOS can validate the signature and size and remap if necessary. If the OpRegion is larger than 8KB, this would result in any conflicting ranges being temporarily mapped with the OpRegion, which probably needs further discussion on what that could break. Other options might be to use the same algorithm with an obscenely sized initial buffer to make sure we do not overlap, always re-allocating the proper sized buffer, or perhaps we could pass the OpRegion itself or information about the OpRegion through fw_cfg. With the posted kernel series[1] and QEMU series[2] (on top of Gerd's IGD patches[3]), this makes the OpRegion available to the VM and tracing shows that the guest driver does access it. [1] https://lkml.org/lkml/2016/2/1/884 [2] https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg00202.html [3] https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg00244.html Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- src/fw/pciinit.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index c31c2fa..4f3251e 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -257,6 +257,52 @@ static void ich9_smbus_setup(struct pci_device *dev, void *arg) pci_config_writeb(bdf, ICH9_SMB_HOSTC, ICH9_SMB_HOSTC_HST_EN); } +static void intel_igd_opregion_setup(struct pci_device *dev, void *arg) +{ + u16 bdf = dev->bdf; + u32 orig; + void *opregion; + int size = 8; + + if (!CONFIG_QEMU) + return; + + orig = pci_config_readl(bdf, 0xFC); + +realloc: + opregion = malloc_high(size * 1024); + if (!opregion) { + warn_noalloc(); + return; + } + + /* + * QEMU maps the OpRegion into system memory at the address written here, + * this overlaps our malloc, which marks the range e820 reserved. + */ + pci_config_writel(bdf, 0xFC, cpu_to_le32((u32)opregion)); + + if (memcmp(opregion, "IntelGraphicsMem", 16)) { + pci_config_writel(bdf, 0xFC, orig); + free(opregion); + return; /* the opregion didn't magically appear, not supported */ + } + + if (size == le32_to_cpu(*(u32 *)(opregion + 16))) { + dprintf(1, "Intel IGD OpRegion enabled on %02x:%02x.%x\n", + pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf)); + return; /* success! */ + } + + pci_config_writel(bdf, 0xFC, orig); + free(opregion); + + if (size == 8) { /* try once more with a new size */ + size = le32_to_cpu(*(u32 *)(opregion + 16)); + goto realloc; + } +} + static const struct pci_device_id pci_device_tbl[] = { /* PIIX3/PIIX4 PCI to ISA bridge */ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0, @@ -290,6 +336,10 @@ static const struct pci_device_id pci_device_tbl[] = { PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0017, 0xff00, apple_macio_setup), PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0022, 0xff00, apple_macio_setup), + /* Intel IGD OpRegion setup */ + PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA, + intel_igd_opregion_setup), + PCI_DEVICE_END, };

5 years, 10 months

Re: [SeaBIOS] [RFC PATCH v1 0/9] Add TPM 2 support

by Kevin O'Connor

On Fri, Jan 22, 2016 at 03:27:28PM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 01/21/2016 05:37:29 PM: > > Thanks Stefan. In general it looks good to me. I have a few > > comments, which I'll send separately. All of my comments could be > > addressed after committing this series if desired. > > I can address those comments and repost a V2 with the 10th patch adding > the part for the logging. Hi Stefan. Sorry for the delay in responding. I have a couple of comments on the new patch series which I will respond with separately. > > How does one test and/or use this support? Does QEMU have support, or > > is there hardware available on coreboot with the tpm2 hardware? > > I did all the testing of these patches with the vTPM with CUSE interface > integrated into QEMU. Unfortunately the vTPM-QEMU integration train seems > a wreck now following comments on QEMU mailing list. So, I don't know of > any TPM 2 hardware out there, less so hardware where coreboot runs. So > that's probably currently the number one problem. Normally, I prefer to wait until upstream has committed the equivalent patches. I think there is some leeway here, however, because this series could be considered as adding support for additional hardware. That said, if you don't know of any TPM2 hardware that is shipping, it does raise the possibility that the specs might change by the time actual hardware does ship. What is your feel for the trade-off between merging now and merging after actual implementations exist? > You know the TPM 1.2 PC BIOS specification, right? I think we can say that > many of the functions implemented in this series for TPM 2 are necessary > because of how it's done for TPM 1.2 as well as properties of the TPM 2 > device. This includes the TPM initialization, S3 support, setting of > timeouts, menu items, etc. The problem with TPM 2 is that there's no > official spec for TPM 2 for a BIOS. So it's not quite clear to me how much > leeway we have to go about this in the areas of ACPI tables for logging > and the API. Regarding these topics: > > ACPI tables for logging: The (U)EFI specification for TPM 2 don't require > a TCPA table with the logging area because there seems to be an API for > the OS for retrieving the log. UEFI seems to log into just some buffer, > not connected to any ACPI table. For the BIOS we would still need that > TCPA table. QEMU currently provides that. The Linux kernel (and all other > OSes -- uuuh) would then have to allow a TCPA table for logging for TPM 2 > even though we cannot point to a spec for that. Not sure whether we can > create a standard for this little gap here... It sounds like the creators of the spec assumed only EFI machines would have a TPM2 device. Unless there is evidence that OSes will accept the ACPI/TCPA table in the new format, I'd be inclined to leave it in the old format. > BIOS API: Some functions pass the entry to write into the log via the > function directly. Patch 10 handles that and transforms that entry into > the log entry format as required for TPM 1.2 or TPM 2 (log entries are > differently formatted for TPM 1.2 and for TPM 2). So the only remaining > problem I know of is the function that allows one to pass TPM commands > through to the TPM. This may end up causing problems in the application if > it was written for TPM 1.2 and now there's a TPM 2 running underneath, > which doesn't understand the TPM 1.2 commands. I would say this is likely > the smaller of the problems also considering that there are not many > applications out there that use that API call. Possibility to just shut > down that function call is certainly there. I'd say returning an error code for pass-through command requests is the safest solution. -Kevin

5 years, 10 months

[PATCH v2 00/10] Add TPM 2 support

by Stefan Berger

This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. v1->v2: - Addressed most of Kevin's comments. - Added patch for writing logs in TPM 2 format Stefan Stefan Berger (10): tpm: Extend TPM TIS with TPM 2 support. tpm: Factor out tpm_extend tpm: Prepare code for TPM 2 functions tpm: Implement tpm20_startup and tpm20_s3_resume tpm: Implement tpm20_set_timeouts tpm: Implement tpm20_prepboot tpm: Implement tpm20_extend tpm: Implement tpm20_menu tpm: Implement TPM 2's set_failure tpm: Write logs in TPM 2 format src/hw/tpm_drivers.c | 38 ++- src/hw/tpm_drivers.h | 26 +- src/std/tcg.h | 145 +++++++++ src/tcgbios.c | 890 +++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 955 insertions(+), 144 deletions(-) -- 2.4.3

5 years, 10 months

[PATCH] Fix comment typo

by Cao jin

Signed-off-by: Cao jin <caoj.fnst(a)cn.fujitsu.com> --- src/fw/pciinit.c | 2 +- src/fw/pirtable.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index c31c2fa..6b1c902 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -274,7 +274,7 @@ static const struct pci_device_id pci_device_tbl[] = { PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE, storage_ide_setup), - /* PIC, IBM, MIPC & MPIC2 */ + /* PIC, IBM, MPIC & MPIC2 */ PCI_DEVICE_CLASS(PCI_VENDOR_ID_IBM, 0x0046, PCI_CLASS_SYSTEM_PIC, pic_ibm_setup), PCI_DEVICE_CLASS(PCI_VENDOR_ID_IBM, 0xFFFF, PCI_CLASS_SYSTEM_PIC, diff --git a/src/fw/pirtable.c b/src/fw/pirtable.c index a494408..bf8c047 100644 --- a/src/fw/pirtable.c +++ b/src/fw/pirtable.c @@ -66,7 +66,7 @@ static struct pir_table PIR_TABLE = { }, .slot_nr = 3, }, { - // 5th slot entry: 4rd PCI slot + // 5th slot entry: 4th PCI slot .dev = 5<<3, .links = { {.link = 0x60, .bitmap = 0xdef8}, // INTA# @@ -76,7 +76,7 @@ static struct pir_table PIR_TABLE = { }, .slot_nr = 4, }, { - // 6th slot entry: 5rd PCI slot + // 6th slot entry: 5th PCI slot .dev = 6<<3, .links = { {.link = 0x61, .bitmap = 0xdef8}, // INTA# -- 2.1.0

5 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS February 2016