SeaBIOS March 2016

seabios@seabios.org

17 participants
21 discussions

[PATCH] sdcard: abort controller setup if capabilities invalid
by Matt DeVillier 21 Mar '16

21 Mar '16

If the version and low/high capabilities flags of a sdcard controller are invalid (0xFFFF), assume the controller address is invalid, and exit setup before attempting to reset the controller, which would introduce an unnecessary delay, since the reset would ultimately fail after timing out. This eliminates the delay in displaying the boot menu message on Baytrail ChromeOS devices, where multiple /etc/sdcard entries are present in a single payload to cover the range of eMMC controller addresses used. Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> --- src/hw/sdcard.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c index 38d05c4..e6090b8 100644 --- a/src/hw/sdcard.c +++ b/src/hw/sdcard.c @@ -486,9 +486,13 @@ sdcard_controller_setup(struct sdhci_s *regs, int prio) if (!(present_state & SP_CARD_INSERTED)) // No card present return; - dprintf(3, "sdhci@%p ver=%x cap=%x %x\n", regs - , readw(&regs->controller_version) - , readl(&regs->cap_lo), readl(&regs->cap_hi)); + u16 ver = readw(&regs->controller_version); + u32 cap_lo = readl(&regs->cap_lo); + u32 cap_hi = readl(&regs->cap_hi); + dprintf(3, "sdhci@%p ver=%x cap=%x %x\n", regs, ver, cap_lo, cap_hi); + if (ver == 0xffff && cap_lo == 0xffffffff && cap_hi == 0xffffffff) + //invalid controller address + return; sdcard_reset(regs, SRF_ALL); writew(&regs->irq_signal, 0); writew(&regs->irq_enable, 0x01ff); -- 2.5.0

2 1

[patch v2 - reformatted] sdcard: skip detection of PCI sdhci controllers if etc/sdcard used
by Matt DeVillier 21 Mar '16

21 Mar '16

Some BayTrail ChromeOS devices have the eMMC controller hidden (thus requiring the use of etc/sdcard), while others do not, making it problematic to have a single payload which serves all devices properly. Therefore, if the CBFS contains etc/sdcard entries, skip detection of any visible PCI sdhci controllers in order to avoid duplicate entries in the boot menu. patch implementation suggested by Kevin O'Connor :) Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> --- src/hw/sdcard.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c index 7e0875f..38d05c4 100644 --- a/src/hw/sdcard.c +++ b/src/hw/sdcard.c @@ -550,18 +550,23 @@ sdcard_setup(void) return; struct romfile_s *file = NULL; + int num_romfiles = 0; for (;;) { file = romfile_findprefix("etc/sdcard", file); if (!file) break; run_thread(sdcard_romfile_setup, file); + num_romfiles++; } - struct pci_device *pci; - foreachpci(pci) { - if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2) - // Not an SDHCI controller following SDHCI spec - continue; - run_thread(sdcard_pci_setup, pci); + //only scan for PCI controllers if etc/sdcard not used + if (num_romfiles == 0) { + struct pci_device *pci; + foreachpci(pci) { + if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2) + // Not an SDHCI controller following SDHCI spec + continue; + run_thread(sdcard_pci_setup, pci); + } } } -- 2.5.0

2 1

Re: [SeaBIOS] [Xen-devel] Xen PV block device support in Seabios
by Jan Beulich 16 Mar '16

16 Mar '16

>>> On 16.03.16 at 14:15, <konrad.wilk(a)oracle.com> wrote: > On Wed, Mar 16, 2016 at 12:22:32PM +0000, Ian Campbell wrote: >> On Wed, 2016-03-16 at 20:13 +0800, Shannon Zhao wrote: >> > >> > On 2016/3/16 19:20, Ian Campbell wrote: >> > > >> > > (nb, my citrix.com email is no longer valid) >> > > On Wed, 2016-03-16 at 11:33 +0800, Shannon Zhao wrote: >> > > > >> > > > > >> > > > > Hi, >> > > > > >> > > > > I noticed there are some efforts to add Xen PV block device support in >> > > > > Seabios in a GSoC project and there is a wiki page [1] for it. I found >> > > > > some patches [2] to add Xenstore R/W support for Seabios. But I didn't >> > > > > find the patches to add PV block device driver in Seabios. >> > > > > >> > > > > If you know please tell me where I can find these patches. And I noticed >> > > > > that the patches [2] and this GSoC project work didn't get applied to >> > > > > Seabios eventually, is there any reason? Does it mean that there are >> > > > > some difficulties to support Xen PV block device in Seabios? >> > > This work was never finished, IIRC (and it was a long time ago so this >> > > might be a faulty recollection) the main stumbling block was that there >> > > is no reasonable BIOS level event which could be used to tear down the >> > > PV interfaces in order to hand them over to the OS (unlike, say, EFI >> > > where there is ExitBootServices). >> > > >> > Ian, thanks for your reply! It looks like the problem is how and when to >> > clear PV resources in seabios before handing over to guest. But I wonder >> > why virtio works in seabios. Does seabios using virtio need to clear >> > things like vrings? Or seabios doesn't clear the things and guest just >> > covers the configuration with new values? >> >> I think virtio covered this use case from day 1 by having the reset, >> but also by not having a xenstore ring etc. >> >> > > So making this work would require something like a complete set of >> > > parallel PV infrastructure (devices, corresponding xenstore nodes, >> > > grant table) for the use of the BIOS firmware, or perhaps a (tricky >> > > to >> > > retrofit in a backwards compatible manner) PV facility for the >> > > guest to >> > > reset everything before starting to use them. >> > > >> > Like guest front-end driver checks if the backend state is >> > XenbusStateInitWait, if not, tell the backend to reset to >> > XenbusStateInitWait state? >> >> Before it can do this the guest needs to recover the xenbus ring (which >> was used by SeaBIOS) into a usable state -- so you need to be thinking >> at least one layer further down before you can start to think about >> individual devices, and don't forget the grant table (which may have in >> use entries from the BIOS) and event channels (which the BIOS may have >> setup). >> >> I'm afraid I don't have any concrete answer for what exactly needs to >> be done to make this work, but I do know that it is a (IMHO very) non- >> trivial amount of investigation, prototyping and coding. > > But it does work with OVMF. That is it implements the full PV driver > for block. So it surely is possible. And grub2, iirc. Jan

2 1

Xen PV block device support in Seabios
by Shannon Zhao 16 Mar '16

16 Mar '16

Hi, I noticed there are some efforts to add Xen PV block device support in Seabios in a GSoC project and there is a wiki page [1] for it. I found some patches [2] to add Xenstore R/W support for Seabios. But I didn't find the patches to add PV block device driver in Seabios. If you know please tell me where I can find these patches. And I noticed that the patches [2] and this GSoC project work didn't get applied to Seabios eventually, is there any reason? Does it mean that there are some difficulties to support Xen PV block device in Seabios? Thanks in advance! [1] http://wiki.xenproject.org/wiki/SeaBIOS [2] http://www.seabios.org/pipermail/seabios/2011-August/002214.html -- Shannon

4 6

[patch] sdcard: skip detection of PCI sdhci controllers if etc/sdcard used
by Matt DeVillier 12 Mar '16

12 Mar '16

Some BayTrail ChromeOS devices have the eMMC controller hidden (thus requiring the use of etc/sdcard), while others do not, making it problematic to have a single payload which serves all devices properly. Therefore, if the CBFS contains etc/sdcard entries, skip detection of any visible PCI sdhci controllers in order to avoid duplicate entries in the boot menu. patch implementation suggested by Kevin O'Connor :) Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> --- src/hw/sdcard.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c index 7e0875f..32cdb14 100644 --- a/src/hw/sdcard.c +++ b/src/hw/sdcard.c @@ -557,11 +557,14 @@ sdcard_setup(void) run_thread(sdcard_romfile_setup, file); } - struct pci_device *pci; - foreachpci(pci) { - if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2) - // Not an SDHCI controller following SDHCI spec - continue; - run_thread(sdcard_pci_setup, pci); + //only scan for PCI controllers if etc/sdcard* not used + if (file == NULL) { + struct pci_device *pci; + foreachpci(pci) { + if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2) + // Not an SDHCI controller following SDHCI spec + continue; + run_thread(sdcard_pci_setup, pci); + } } } -- 2.5.0

3 3

[patch v2] sdcard: skip detection of PCI sdhci controllers if etc/sdcard used
by Matt DeVillier 11 Mar '16

11 Mar '16

2 1

Re: [SeaBIOS] [PATCH] coreboot: Add support for FMAP and multiple CBFS
by Kevin O'Connor 11 Mar '16

11 Mar '16

On Thu, Mar 10, 2016 at 11:11:59AM -0600, Ben Gardner wrote: > Hi Kevin, > > I plan to have the default CBFS contain only coreboot and SeabIOS and > a few payloads (coreinfo, memtest86, PXE) that I don't intend to > change often. > That would be protected with a hash and would be kept small for > performance reasons. > ChromeOS appears to do something similar and take it a step further > and write-protect that "read only" region of flash. > > The other CBFS would contain larger images that I'm likely to change, > such as Linux. > > There is a chance of name conflicts and that may cause problems. > In my use case, the answer is "don't do that". > > From a random sampling of FMD files in the coreboot tree > (google/glados/chromeos.fmd), I see that ChromeOS uses three: > FW_MAIN_A, FW_MAIN_B, and the default COREBOOT. > Assuming FW_MAIN_A and FW_MAIN_B contain files with similar names, > that would cause confusion if they use SeaBIOS. > But I think that ChromeOS is switching to use the Depthcharge bootloader. > > So, maybe this wouldn't work well for everyone. Thanks. If this may not work for everyone, then I suggest adding a build time (kconfig) or runtime (cbfs) setting to enable/disable it. Normally runtime settings are preferred, but that may not work here. -Kevin

1 0

Re: [SeaBIOS] mame
by Gerd Hoffmann 11 Mar '16

11 Mar '16

Hi, > My name is Miodrag and I am coordinator of MAME project > (www.mamedev.org), we would like to distribute seabios roms if > possible together with our binaries to show PC capable emulation. All > is free and project is under GPL2+ license. seabios is GPL, so this is perfectly fine as long as you also provide the source code used to build the binaries (as required by GPL). If you are using seabios unmodified I'd recommend to place a upstream git mirror next to the mame repos @ github. qemu does the same on http://git.qemu.org/, for GPL compliance reasons, and also because it's more convenient that way for the seabios submodule we have in qemu. If you have patched seabios you have to publish the changes too of course, and I recommend to sent the patches for review and upstream merge to the seabios mailing list (which I've added to Cc). thanks, Gerd

2 1

[PATCH] coreboot: Add support for FMAP and multiple CBFS
by Ben Gardner 10 Mar '16

10 Mar '16

ROM images with a FMAP may have multiple CBFS. Scan all available CBFS so that, say, a SeaBIOS bootable image doesn't have to be in the main CBFS. Coreboot puts the FMAP location in the BOOT_MEDIA_PARAMS entry in the coreboot table. We can grab that and can all regions for CBFS files. Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com> --- src/fw/coreboot.c | 148 +++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 124 insertions(+), 24 deletions(-) diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c index 4957b80..0309832 100644 --- a/src/fw/coreboot.c +++ b/src/fw/coreboot.c @@ -86,6 +86,41 @@ struct cbmem_console { } PACKED; static struct cbmem_console *cbcon = NULL; +#define CB_TAG_BOOT_MEDIA_PARAMS 0x0030 +struct cb_boot_media_params { + u32 tag; + u32 size; + /* offsets are relative to start of boot media */ + u64 fmap_offset; + u64 cbfs_offset; + u64 cbfs_size; + u64 boot_media_size; +}; + +#define FMAP_SIGNATURE "__FMAP__" +#define FMAP_VER_MAJOR 1 /* this header's FMAP minor version */ +#define FMAP_VER_MINOR 1 /* this header's FMAP minor version */ +#define FMAP_STRLEN 32 /* maximum length for strings, */ + +/* Mapping of volatile and static regions in firmware binary */ +struct fmap_area { + u32 offset; /* offset relative to base */ + u32 size; /* size in bytes */ + u8 name[FMAP_STRLEN]; /* descriptive name */ + u16 flags; /* flags for this area */ +} PACKED; + +struct fmap { + u8 signature[8]; /* "__FMAP__" (0x5F5F464D41505F5F) */ + u8 ver_major; /* major version */ + u8 ver_minor; /* minor version */ + u64 base; /* address of the firmware binary */ + u32 size; /* size of firmware binary in bytes */ + u8 name[FMAP_STRLEN]; /* name of this firmware binary */ + u16 nareas; /* number of areas described by fmap_areas[] below */ + struct fmap_area areas[]; +} PACKED; + static u16 ipchksum(char *buf, int count) { @@ -159,6 +194,39 @@ find_cb_table(void) static struct cb_memory *CBMemTable; const char *CBvendor = "", *CBpart = ""; +struct fmap *CBfmap; + +static void +fmap_init(struct fmap *fm) +{ + if (memcmp(fm->signature, FMAP_SIGNATURE, sizeof(fm->signature)) != 0) { + dprintf(1, "FMAP: bad signature\n"); + return; + } + if ((fm->ver_major != FMAP_VER_MAJOR) || + (fm->ver_minor != FMAP_VER_MINOR)) { + dprintf(1, "FMAP: bad version %d.%d\n", fm->ver_major, fm->ver_minor); + return; + } + + /* print out the FMAP contents */ + void *base = (void *)(uintptr_t)fm->base; + dprintf(1, "FMAP: %p 0x%08x 0x%04x %s\n", + base, fm->size, fm->nareas, fm->name); + + int idx; + for (idx = 0; idx < fm->nareas; idx++) { + struct fmap_area *fa = &fm->areas[idx]; + const u8 *ptr = base + fa->offset; + int is_cbfs = (fa->size > 4096) && (memcmp(ptr, "LARCHIVE", 8) == 0); + dprintf(is_cbfs ? 1 : 3, + " [%d] %p 0x%08x 0x%04x %s%s\n", + idx, ptr, fa->size, fa->flags, fa->name, + is_cbfs ? "(CBFS)" : ""); + } + /* looks good -- save the FMAP pointer for later */ + CBfmap = fm; +} // Populate max ram and e820 map info by scanning for a coreboot table. void @@ -205,6 +273,17 @@ coreboot_preinit(void) dprintf(1, "Found mainboard %s %s\n", CBvendor, CBpart); } + struct cb_boot_media_params *cbbmb = find_cb_subtable(cbh, CB_TAG_BOOT_MEDIA_PARAMS); + if (cbbmb) { + /* ~0 is used to indicate 'not present' */ + if ((cbbmb->fmap_offset + 1) != 0) { + /* Assuming the ROM map ends at 4 GB */ + u8 *base = (u8 *)(u32)~(cbbmb->boot_media_size - 1); + struct fmap *fm = (void *)(base + cbbmb->fmap_offset); + fmap_init(fm); + } + } + return; fail: @@ -414,30 +493,11 @@ process_links_file(void) free(links); } -void -coreboot_cbfs_init(void) +static void +coreboot_cbfs_scan(struct cbfs_file *fhdr, u32 romsize, u32 align) { - if (!CONFIG_COREBOOT_FLASH) - return; - - struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4); - if ((u32)hdr & 0x03) { - dprintf(1, "Invalid CBFS pointer %p\n", hdr); - return; - } - if (CONFIG_CBFS_LOCATION && (u32)hdr > CONFIG_CBFS_LOCATION) - // Looks like the pointer is relative to CONFIG_CBFS_LOCATION - hdr = (void*)hdr + CONFIG_CBFS_LOCATION; - if (hdr->magic != cpu_to_be32(CBFS_HEADER_MAGIC)) { - dprintf(1, "Unable to find CBFS (ptr=%p; got %x not %x)\n" - , hdr, hdr->magic, cpu_to_be32(CBFS_HEADER_MAGIC)); - return; - } - dprintf(1, "Found CBFS header at %p\n", hdr); + u32 romstart = (u32)fhdr; - u32 romsize = be32_to_cpu(hdr->romsize); - u32 romstart = CONFIG_CBFS_LOCATION - romsize; - struct cbfs_file *fhdr = (void*)romstart + be32_to_cpu(hdr->offset); for (;;) { if ((u32)fhdr - romstart > romsize) break; @@ -464,8 +524,48 @@ coreboot_cbfs_init(void) } romfile_add(&cfile->file); - fhdr = (void*)ALIGN((u32)cfile->data + cfile->rawsize - , be32_to_cpu(hdr->align)); + fhdr = (void*)ALIGN((u32)cfile->data + cfile->rawsize, align); + } +} + +void +coreboot_cbfs_init(void) +{ + if (!CONFIG_COREBOOT_FLASH) + return; + + if (CBfmap) { + void *base = (void *)(uintptr_t)CBfmap->base; + int idx; + + for (idx = 0; idx < CBfmap->nareas; idx++) { + struct fmap_area *fa = &CBfmap->areas[idx]; + struct cbfs_file *cf = (struct cbfs_file *)(base + fa->offset); + if (fa->size > 4096) { + coreboot_cbfs_scan(cf, fa->size, 64); + } + } + } else { + /* no FMAP - read CBFS header location from last 4 bytes of ROM */ + struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4); + if ((u32)hdr & 0x03) { + dprintf(1, "Invalid CBFS pointer %p\n", hdr); + return; + } + if (CONFIG_CBFS_LOCATION && (u32)hdr > CONFIG_CBFS_LOCATION) + // Looks like the pointer is relative to CONFIG_CBFS_LOCATION + hdr = (void*)hdr + CONFIG_CBFS_LOCATION; + if (hdr->magic != cpu_to_be32(CBFS_HEADER_MAGIC)) { + dprintf(1, "Unable to find CBFS (ptr=%p; got %x not %x)\n", + hdr, hdr->magic, cpu_to_be32(CBFS_HEADER_MAGIC)); + return; + } + dprintf(1, "Found CBFS header at %p\n", hdr); + + u32 romsize = be32_to_cpu(hdr->romsize); + u32 romstart = CONFIG_CBFS_LOCATION - romsize; + struct cbfs_file *fhdr = (void*)romstart + be32_to_cpu(hdr->offset); + coreboot_cbfs_scan(fhdr, romsize, be32_to_cpu(hdr->align)); } process_links_file(); -- 1.9.1

3 3

[PATCH V2] fw/pci: add Q35 S3 support
by Marcel Apfelbaum 07 Mar '16

07 Mar '16

Following the i440fx example, save the LPC, SMBUS and PCIEXBAR bdfs between OS sleeps and use them to re-configure the corresponding registers. Tested-by: Gal Hammer <ghammer(a)redhat.com> Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- Hi, v1 -> v2: - made ICH9SmbusBDF static (Laszlo) - use "patience" diff for git-format (Laszlo) (no change this time, maybe will help next time, I added it to my script) The patch was tested with Win7 and Fedora 23 guests. Any comments are welcomed. Thanks, Marcel src/fw/pciinit.c | 73 +++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 56 insertions(+), 17 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 5da6cf6..b2a546b 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -149,6 +149,22 @@ static void piix_isa_bridge_setup(struct pci_device *pci, void *arg) dprintf(1, "PIIX3/PIIX4 init: elcr=%02x %02x\n", elcr[0], elcr[1]); } +static void mch_isa_lpc_setup(u16 bdf) +{ + /* pm io base */ + pci_config_writel(bdf, ICH9_LPC_PMBASE, + acpi_pm_base | ICH9_LPC_PMBASE_RTE); + + /* acpi enable, SCI: IRQ9 000b = irq9*/ + pci_config_writeb(bdf, ICH9_LPC_ACPI_CTRL, ICH9_LPC_ACPI_CTRL_ACPI_EN); + + /* set root complex register block BAR */ + pci_config_writel(bdf, ICH9_LPC_RCBA, + ICH9_LPC_RCBA_ADDR | ICH9_LPC_RCBA_EN); +} + +static int ICH9LpcBDF = -1; + /* ICH9 LPC PCI to ISA bridge */ /* PCI_VENDOR_ID_INTEL && PCI_DEVICE_ID_INTEL_ICH9_LPC */ static void mch_isa_bridge_setup(struct pci_device *dev, void *arg) @@ -176,16 +192,10 @@ static void mch_isa_bridge_setup(struct pci_device *dev, void *arg) outb(elcr[1], ICH9_LPC_PORT_ELCR2); dprintf(1, "Q35 LPC init: elcr=%02x %02x\n", elcr[0], elcr[1]); - /* pm io base */ - pci_config_writel(bdf, ICH9_LPC_PMBASE, - acpi_pm_base | ICH9_LPC_PMBASE_RTE); + ICH9LpcBDF = bdf; - /* acpi enable, SCI: IRQ9 000b = irq9*/ - pci_config_writeb(bdf, ICH9_LPC_ACPI_CTRL, ICH9_LPC_ACPI_CTRL_ACPI_EN); + mch_isa_lpc_setup(bdf); - /* set root complex register block BAR */ - pci_config_writel(bdf, ICH9_LPC_RCBA, - ICH9_LPC_RCBA_ADDR | ICH9_LPC_RCBA_EN); e820_add(ICH9_LPC_RCBA_ADDR, 16*1024, E820_RESERVED); acpi_pm1a_cnt = acpi_pm_base + 0x04; @@ -244,11 +254,8 @@ static void piix4_pm_setup(struct pci_device *pci, void *arg) pmtimer_setup(acpi_pm_base + 0x08); } -/* ICH9 SMBUS */ -/* PCI_VENDOR_ID_INTEL && PCI_DEVICE_ID_INTEL_ICH9_SMBUS */ -static void ich9_smbus_setup(struct pci_device *dev, void *arg) +static void ich9_smbus_enable(u16 bdf) { - u16 bdf = dev->bdf; /* map smbus into io space */ pci_config_writel(bdf, ICH9_SMB_SMB_BASE, (acpi_pm_base + 0x100) | PCI_BASE_ADDRESS_SPACE_IO); @@ -257,6 +264,17 @@ static void ich9_smbus_setup(struct pci_device *dev, void *arg) pci_config_writeb(bdf, ICH9_SMB_HOSTC, ICH9_SMB_HOSTC_HST_EN); } +static int ICH9SmbusBDF = -1; + +/* ICH9 SMBUS */ +/* PCI_VENDOR_ID_INTEL && PCI_DEVICE_ID_INTEL_ICH9_SMBUS */ +static void ich9_smbus_setup(struct pci_device *dev, void *arg) +{ + ICH9SmbusBDF = dev->bdf; + + ich9_smbus_enable(dev->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, @@ -293,6 +311,9 @@ static const struct pci_device_id pci_device_tbl[] = { PCI_DEVICE_END, }; +static int MCHMmcfgBDF = -1; +static void mch_mmconfig_setup(u16 bdf); + void pci_resume(void) { if (!CONFIG_QEMU) { @@ -302,6 +323,18 @@ void pci_resume(void) if (PiixPmBDF >= 0) { piix4_pm_config_setup(PiixPmBDF); } + + if (ICH9LpcBDF >= 0) { + mch_isa_lpc_setup(ICH9LpcBDF); + } + + if (ICH9SmbusBDF >= 0) { + ich9_smbus_enable(ICH9SmbusBDF); + } + + if(MCHMmcfgBDF >= 0) { + mch_mmconfig_setup(MCHMmcfgBDF); + } } static void pci_bios_init_device(struct pci_device *pci) @@ -388,18 +421,24 @@ static void i440fx_mem_addr_setup(struct pci_device *dev, void *arg) pci_slot_get_irq = piix_pci_slot_get_irq; } -static void mch_mem_addr_setup(struct pci_device *dev, void *arg) +static void mch_mmconfig_setup(u16 bdf) { u64 addr = Q35_HOST_BRIDGE_PCIEXBAR_ADDR; - u32 size = Q35_HOST_BRIDGE_PCIEXBAR_SIZE; - - /* setup mmconfig */ - u16 bdf = dev->bdf; u32 upper = addr >> 32; u32 lower = (addr & 0xffffffff) | Q35_HOST_BRIDGE_PCIEXBAREN; pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, 0); pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR + 4, upper); pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, lower); +} + +static void mch_mem_addr_setup(struct pci_device *dev, void *arg) +{ + u64 addr = Q35_HOST_BRIDGE_PCIEXBAR_ADDR; + u32 size = Q35_HOST_BRIDGE_PCIEXBAR_SIZE; + + /* setup mmconfig */ + MCHMmcfgBDF = dev->bdf; + mch_mmconfig_setup(dev->bdf); e820_add(addr, size, E820_RESERVED); /* setup pci i/o window (above mmconfig) */ -- 2.4.3

3 2

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS March 2016