SeaBIOS October 2011

seabios@seabios.org

33 participants
56 discussions

[PATCH 2/3] AMD IOMMU support
by Kristen Eisenberg 19 Oct '11

19 Oct '11

On Fri, Feb 04, 2011 at 01:24:14AM +0200, Eduard - Gabriel Munteanu wrote: > This initializes the AMD IOMMU and creates ACPI tables for it. > > Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu at linux360.ro> > --- > src/acpi.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/config.h | 3 ++ > src/pci_ids.h | 1 + > src/pci_regs.h | 1 + > src/pciinit.c | 29 +++++++++++++++++++ > 5 files changed, 118 insertions(+), 0 deletions(-) > > diff --git a/src/acpi.c b/src/acpi.c > index 18830dc..fca152c 100644 > --- a/src/acpi.c > +++ b/src/acpi.c > @@ -196,6 +196,36 @@ struct srat_memory_affinity > u32 reserved3[2]; > } PACKED; Kristen Eisenberg Billige Flüge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de - Billige Flüge vergleichen

1 0

Re: [SeaBIOS] Help with struct disk_op_s and block drives
by Kevin O'Connor 18 Oct '11

18 Oct '11

On Tue, Oct 18, 2011 at 04:05:47PM +0900, Daniel Castro wrote: > Thanks for the reply Kevin, also can you point me to some of seabios > documentation, I am in the process of making a presentation for > XenSumit on this work, and would like to go on some detail about the > inner working of Seabios. Maybe how it interacts with qemu? anyway any > documentation would be greatly appreciated. Unfortunately, SeaBIOS is lacking a bit on developer documentation. I've been meaning to add to the wiki, but I have not gotten the chance. Right now, the best documentation is the README file and the coreboot SeaBIOS wiki page: http://www.coreboot.org/SeaBIOS -Kevin

1 0

Re: [SeaBIOS] Help with struct disk_op_s and block drives
by Kevin O'Connor 18 Oct '11

18 Oct '11

On Thu, Oct 13, 2011 at 09:17:51PM +0900, Daniel Castro wrote: > Hello, > I am working on the PV block drivers for Xen. > > I am in the point where I must write to my PV ring the requests and responses. > I need a little help to understand how this works :) > The operation comes wrapped in this structure: > struct disk_op_s { > u64 lba; > void *buf_fl; > struct drive_s *drive_g; > u16 count; > lba is the sector I need to read or write to, right? Yes. > count is how many sectors I am going to move, right? Yes. > buf_fl is the pointer to the buffer where I will put the info in case > of write, or I will get the info in case of read, right? Yes. > command is either read or write. Command can be other things as well - see some of the other drivers. > drive_s contains the descriptor of the drive. Yes. > How does seabios handle more than one drive? My case, right now is > only one drive but there will be more. During the initialization phase, your driver should create a drive_s structure for each available drive and pass it to boot_add_hd(). On an access request, the disk_op_s struct will point to the drive_s struct of the requested drive. -Kevin

2 1

Re: [SeaBIOS] [PATCHv3 4/4] acpi: automatically generated ssdt proc
by Kevin O'Connor 18 Oct '11

18 Oct '11

On Tue, Oct 04, 2011 at 03:26:19PM +0200, Michael S. Tsirkin wrote: > Get rid of manually cut and pasted ssdt_proc, > use ssdt compiled by iasl and offsets extracted > by acpi_extract instead. Thanks - I like the idea of auto-generating the offsets. [...] > +#define AmlCode static ssdp_proc_aml > +#include "ssdt-proc.hex" > +#undef AmlCode Side note - since you're post-processing the acpi data, it would be nice to update the name in the hex file too. > +/* 0x5B 0x83 ProcessorOp PkgLength NameString ProcID */ > +#define SD_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2) > +#define SD_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4) > +#define SD_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start) > +#define SD_SIZEOF (*ssdt_proc_end - *ssdt_proc_start) > +#define SD_PROC (ssdp_proc_aml + *ssdt_proc_start) [...] > DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC", "BXSSDT", 0x1) > -/* v------------------ DO NOT EDIT ------------------v */ > { > + ACPI_EXTRACT_PROCESSOR_START ssdt_proc_start > + ACPI_EXTRACT_PROCESSOR_END ssdt_proc_end > + ACPI_EXTRACT_PROCESSOR_STRING ssdt_proc_name > Processor (CPAA, 0xAA, 0x0000b010, 0x06) { Since the acpi.c code needs to know the processor object format anyway, what about making a generic "ACPI_EXTRACT" indicator that exports the location, size, and parameter location in one go. Something like: ACPI_EXTRACT ssdt_proc_obj Processor (CPAA, 0xAA, 0x0000b010, 0x06) { which would produce something like: static struct aml_object ssdt_proc_obj = {.addr=0x24, .size=0x40, .param=0x28}; As for the other parts of this patch series - I'm still leary of changing the DSDT dynamically. I'd be curious to see if we can add the following to ssdt-proc.dsl: ACPI_EXTRACT hotplug_obj Device (SL00) { ACPI_EXTRACT_NAME_DWORD_CONST hotplog_id Name (ID, 0xAABBCCDD) Name (_ADR, ID) Method (_EJ0, 1) { Return(PCEJ(ID)) } Name (_SUN, ID) } and then just memcpy the "hotplug_obj" N number of times into the ssdt for each available slot. (This would be on top of the DSDT simplification patch series that I posted previously.) -Kevin

3 5

Re: [SeaBIOS] POST Memory Manager emulation in SeaBIOS
by Darmawan Salihun 15 Oct '11

15 Oct '11

Hi Kevin, I finally got everything I needed with SeaBIOS debug level set to 8. These are the relevant snippets from the serial logging: ------------------------------------------- Scan for option roms ... Found CBFS file genroms/test.rom ... Searching CBFS for prefix genroms/ Found CBFS file cmos_layout.bin Found CBFS file fallback/romstage Found CBFS file fallback/coreboot_ram Found CBFS file fallback/payload Found CBFS file genroms/test.rom Copying data 24063@0xfffd58b8 to 157696@0x000c9800 Checking rom 0x000c9800 (sig aa55 size 47) Searching CBFS for prefix genroms/ Found CBFS file ... Checking rom 0x000c9800 (sig aa55 size 47) Searching bootorder for: /rom(a)genroms/test.rom pmm_malloc zone=0x000f4e54 handle=ffffffff size=20 align=10 ret=0x07fd4b30 (detail=0x07fd4b50) Registering bootable: Legacy option rom (type:129 prio:9999 data:c9800003) Press F12 for boot menu. Checking for bootsplash Searching CBFS for prefix bootsplash.jpg Found CBFS file cmos_layout.bin Found CBFS file fallback/romstage Found CBFS file fallback/coreboot_ram Found CBFS file fallback/payload Found CBFS file genroms/test.rom Found CBFS file Mapping cd drive 0x000fdb10 Mapping hd drive 0x000fdb40 to 0 drive 0x000fdb40: PCHS=20/16/63 translation=none LCHS=20/16/63 s=20480 Running option rom at c980:0003 pmm call arg1=0 pmm00: length=1000 handle=ffffffff flags=1 pmm_malloc zone=0x000f4e50 handle=ffffffff size=65536 align=10 ret=0x00080000 (detail=0x07fd4b00) ------------------------------------------- What I really needed is the details about the memory allocated by SeaBIOS for the PMM call in the option rom (test.rom above). Particularly, start address of the allocated memory. Thank you very much for your help Kind Regards, Darmawan -- -------------------------------------------------------------------- -= Human knowledge belongs to the world =-

1 0

Re: [SeaBIOS] POST Memory Manager emulation in SeaBIOS
by Kevin O'Connor 15 Oct '11

15 Oct '11

On Thu, Oct 13, 2011 at 12:18:08AM +0700, Darmawan Salihun wrote: > On 10/11/11, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > I suggest getting serial debugging working, and post the full log. > > The full log is in the attachment. > Anyway, I observed that the PCI ROM that I'm working with > always got it's 3rd byte set to zero prior to being executed. > I've just found where it's being modified but have yet to find > the corresponding code in the entire "debugging system" SeaBIOS wont modify the rom. However, the rom might self-modify itself when it is run. [...] > Real mode stub @00000600: 606 bytes > Calling Option ROM... > oprom: INT# 0x10 If you are using SeaBIOS, you should instruct coreboot to not execute option roms. Disable both CONFIG_VGA_ROM_RUN and CONFIG_PCI_ROM_RUN. (If both coreboot and seabios run the roms, it can confuse the hardware.) > Copying option rom (size 72192) from 0xfe020000 to c9000 > Running option rom at c900:0003 > pnp call arg1=60 > pmm call arg1=0 > pmm00: length=8000 handle=ffffffff flags=6 > pmm call arg1=2 > pmm02: buffer=7f00000 > pmm call arg1=0 > pmm00: length=10000 handle=ffffffff flags=6 I guess the boot hangs at this point? BTW, is this a gPXE rom? It seems to follow a similar pattern of allocating, deallocating, and then allocating a larger chunk. -Kevin

2 1

Re: [SeaBIOS] POST Memory Manager emulation in SeaBIOS
by Kevin O'Connor 15 Oct '11

15 Oct '11

On Thu, Oct 13, 2011 at 12:22:05AM +0700, Darmawan Salihun wrote: > I also have another question. What is the maximum logging level in SeaBIOS? > Is it 8? The debug level is compared against the value passed to the various dprintf() calls - the current code goes up to 20 I think. That said, debug levels over 8 generally cause too much debug output. If you're not finding what you need at 8, generally the next step would be to add dprintf() statements, modify existing dprintf() statements, or modify the DEBUG_xxx defines in src/config.h. -Kevin

2 1

Re: [SeaBIOS] "PCI: out of address space" with two video cards
by Kevin O'Connor 14 Oct '11

14 Oct '11

On Thu, Oct 13, 2011 at 04:52:05PM -0500, marek dudek wrote: > I am trying to get a KVM guest to work with (up to) TWO video cards > assigned to it. [...] > 02:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce > 7300 SE/7200 GS] (rev a1) (prog-if 00 [VGA controller]) > Subsystem: eVga.com. Corp. Device c429 > Flags: bus master, fast devsel, latency 0, IRQ 36 > Memory at f8000000 (32-bit, non-prefetchable) [size=16M] > Memory at b0000000 (64-bit, prefetchable) [size=256M] As a guess, you've simply run out of virtual memory because the two cards need 512M of address space. I think Gerd had some experimental patches to make this more flexible. You could try modifying src/pciinit.c: u32 start = BUILD_PCIMEM_START; to something like: u32 start = 0xc0000000; but note that this isn't a real solution (due to possible conflicts at the 0xc0000000 - 0xe0000000 address range). -Kevin

2 1

[PATCHv2 0/4] PCI init code refactoring
by Kevin O'Connor 14 Oct '11

14 Oct '11

Some cleanups to the pciinit.c code. These are some things I noticed while tracking down the recent bug reports caused by calling ALIGN_DOWN with a zero alignment. This second version of the series is less ambitious than the first version - it's limited to simpler changes that are more obvious. -Kevin Kevin O'Connor (4): Use standard formatting for PCI info during PCI init pass. Separate pciinit.c into clearly delineated sections. Use pci->header_type in pci_bar() to avoid unnecessary pci_config_readb. Simplify pci_slot_get_irq(). src/pciinit.c | 301 +++++++++++++++++++++++++++++--------------------------- 1 files changed, 156 insertions(+), 145 deletions(-) -- 1.7.6.4

1 4

"PCI: out of address space" with two video cards
by marek dudek 13 Oct '11

13 Oct '11

Hello, I am experimenting with video card PCI pass-through under KVM. I am trying to get a KVM guest to work with (up to) TWO video cards assigned to it. The goal is to have flexibility of using a single quest with two monitors, or two guests with a single monitor each, etc. Note that using a single “dual-headed” video card is not a preferred option, since it can be assigned only to one guest. So far I was successful (Debian guest OS booting ok, graphics works fine) when using a single video card (see point 3 below). However, when assigning two video cards to a guest, SeaBIOS fails with "PCI: out of address space" error during PCI new allocation pass #1 (see point 4 below). Notice that both video cards were properly detected and assigned to requested guest PCI slots 00:06.0 and 00:07.0. Any ideas how to fix or get around this problem? My coding expertise is rudimentary, but I am willing to experiment with any suggestions, try patches you might provide, etc. Is there additional info I could provide to help in the testing process? Thanks, Marek Dudek -------------------------- My setup is a follows: 1) Using latest version of Seabios (rel-1.6.3); compiled with debug level 8. As an experiment, I also tried recent “PCI init code refactoring” patch by Kevin O'Connor, with same result. 2) Both video cards are of same type (old NVidia GeForce 7300); the cards are located in the host PCI slots 02:00.0 and 03:00.0. $ sudo lspci -v -s 02:00.0 02:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 SE/7200 GS] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. Device c429 Flags: bus master, fast devsel, latency 0, IRQ 36 Memory at f8000000 (32-bit, non-prefetchable) [size=16M] Memory at b0000000 (64-bit, prefetchable) [size=256M] Memory at f7000000 (64-bit, non-prefetchable) [size=16M] Expansion ROM at f6fe0000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Kernel driver in use: pci-stub 3) When using a SINGLE video card, SeaBIOS reports as follows: $sudo kvm -drive file=/dev/sdc -device pci-assign,host=02:00.0,addr=0x6 -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios 2>&1 ------------------------ Start bios (version 1.6.3-20111012_174214-rock) enabling shadow ram qemu_cfg_present=1 Find memory size Add to e820 map: 00000000 08000000 1 Add to e820 map: 00000000 00000000 1 Add to e820 map: fffc0000 00040000 2 Add to e820 map: 000a0000 00050000 -1 Add to e820 map: 000f0000 00010000 2 Add to e820 map: feffc000 00004000 2 Ram Size=0x08000000 (0x0000000000000000 high) malloc setup Add to e820 map: 07ff0000 00010000 2 pmm_malloc zone=0x000f0930 handle=ffffffff size=63248 align=10 ret=0x07fe07d0 (detail=0x07fefee0) Relocating init from 0x000e12d0 to 0x07fe07d0 (size 63248) malloc fixup reloc init ivt init bda Add to e820 map: 0009fc00 00000400 2 init pic init timer tsc calibrate start=1004667100 end=1011214380 diff=6547280 CPU Mhz=3814 math cp init init mtrr pci setup === PCI bus & bridge init === PCI: pci_bios_init_bus_rec bus = 0x0 === PCI device probing === PCI probe pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0700 (detail=0x07fe0770) PCI device 00:00.0 (vd=8086:1237 c=0600) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0660 (detail=0x07fe06d0) PCI device 00:01.0 (vd=8086:7000 c=0601) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe05c0 (detail=0x07fe0630) PCI device 00:01.1 (vd=8086:7010 c=0101) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0520 (detail=0x07fe0590) PCI device 00:01.3 (vd=8086:7113 c=0680) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0480 (detail=0x07fe04f0) PCI device 00:02.0 (vd=1013:00b8 c=0300) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe03e0 (detail=0x07fe0450) PCI device 00:03.0 (vd=10ec:8139 c=0200) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0340 (detail=0x07fe03b0) PCI device 00:06.0 (vd=10de:01d3 c=0300) Found 7 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === pmm_malloc zone=0x07fefe30 handle=ffffffff size=528 align=10 ret=0x07fe0100 (detail=0x07fe0310) PCI: check devices bus 0 === PCI new allocation pass #2 === PCI: init bases bus 0 (primary) type io max 100 sum 110 base c000 size 100: 1 bar(s), c000 -> c0ff size 10: 1 bar(s), c100 -> c10f type mem max 10000000 sum 12022000 base e0000000 size 10000000: 1 bar(s), e0000000 -> efffffff size 1000000: 2 bar(s), f0000000 -> f1ffffff size 10000: 2 bar(s), f2000000 -> f201ffff size 1000: 2 bar(s), f2020000 -> f2021fff type prefmem max 2000000 sum 2000000 base fc000000 size 2000000: 1 bar(s), fc000000 -> fdffffff PCI: map device bus 0, bfd 0x0 PCI: map device bus 0, bfd 0x8 PCI: map device bus 0, bfd 0x9 bar 4, addr c100, size 10 [io] PCI: map device bus 0, bfd 0xb PCI: map device bus 0, bfd 0x10 bar 0, addr fc000000, size 2000000 [mem] bar 1, addr f2020000, size 1000 [mem] bar 6, addr f2000000, size 10000 [mem] PCI: map device bus 0, bfd 0x18 bar 0, addr c000, size 100 [io] bar 1, addr f2021000, size 100 [mem] bar 6, addr f2010000, size 10000 [mem] PCI: map device bus 0, bfd 0x30 bar 0, addr f0000000, size 1000000 [mem] bar 1, addr e0000000, size 10000000 [mem] bar 3, addr f1000000, size 1000000 [mem] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139 PCI: bus=0 devfn=0x30: vendor_id=0x10de device_id=0x01d3 PIIX3/PIIX4 init: elcr=00 0c pmm_free 0x07fe0100 (detail=0x07fe0310) init smm Found 1 cpu(s) max supported 1 cpu(s) init bios32 init PMM init PNPBIOS table init keyboard init mouse init PIR table init MPTable pmm_malloc zone=0x07fefe30 handle=ffffffff size=32768 align=10 ret=0x07fd8310 (detail=0x07fe0310) pmm_malloc zone=0x07fefe2c handle=ffffffff size=224 align=10 ret=0x000fdb10 (detail=0x07fd82e0) pmm_malloc zone=0x07fefe2c handle=ffffffff size=16 align=10 ret=0x000fdb00 (detail=0x07fd82b0) pmm_free 0x07fd8310 (detail=0x07fe0310) MP table addr=0x000fdb00 MPC table addr=0x000fdb10 size=224 init SMBIOS tables pmm_malloc zone=0x07fefe30 handle=ffffffff size=32768 align=10 ret=0x07fd8310 (detail=0x07fe0310) pmm_malloc zone=0x07fefe2c handle=ffffffff size=31 align=10 ret=0x000fdae0 (detail=0x07fd8280) pmm_malloc zone=0x07fefe2c handle=ffffffff size=263 align=10 ret=0x000fd9d0 (detail=0x07fd8250) SMBIOS ptr=0x000fdae0 table=0x000fd9d0 size=263 pmm_free 0x07fd8310 (detail=0x07fe0310) init ACPI tables pmm_malloc zone=0x07fefe34 handle=ffffffff size=116 align=10 ret=0x07ffff80 (detail=0x07fe0310) pmm_malloc zone=0x07fefe34 handle=ffffffff size=64 align=40 ret=0x07ffff40 (detail=0x07fe02e0) pmm_malloc zone=0x07fefe34 handle=ffffffff size=9609 align=10 ret=0x07ffd9b0 (detail=0x07fe02b0) pmm_malloc zone=0x07fefe34 handle=ffffffff size=158 align=10 ret=0x07ffd910 (detail=0x07fe0280) pmm_malloc zone=0x07fefe34 handle=ffffffff size=224 align=10 ret=0x07ffd830 (detail=0x07fe0250) pmm_malloc zone=0x07fefe34 handle=ffffffff size=56 align=10 ret=0x07ffd7f0 (detail=0x07fe0220) pmm_malloc zone=0x07fefe34 handle=ffffffff size=52 align=10 ret=0x07ffd7b0 (detail=0x07fe01f0) pmm_malloc zone=0x07fefe2c handle=ffffffff size=36 align=10 ret=0x000fd9a0 (detail=0x07fe01c0) ACPI tables: RSDP=0x000fd9a0 RSDT=0x07ffd7b0 Scan for VGA option rom Attempting to init PCI bdf 00:02.0 (vd 1013:00b8) Attempting to map option rom on dev 00:02.0 Option rom sizing returned f2000000 ffff0000 Inspecting possible rom at 0xf2000000 (vd=1013:00b8 bdf=00:02.0) Copying option rom (size 35840) from 0xf2000000 to c0000 Checking rom 0x000c0000 (sig aa55 size 70) Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version 1.6.3-20111012_174214-rock) (..cut here..) 4) When using TWO video cards, SeaBIOS reports as follows: $ sudo kvm -drive file=/dev/sdc -device pci-assign,host=02:00.0,addr=0x6 -device pci-assign,host=03:00.0,addr=0x7 -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios 2>&1 -------------------- Start bios (version 1.6.3-20111012_174214-rock) enabling shadow ram qemu_cfg_present=1 Find memory size Add to e820 map: 00000000 08000000 1 Add to e820 map: 00000000 00000000 1 Add to e820 map: fffc0000 00040000 2 Add to e820 map: 000a0000 00050000 -1 Add to e820 map: 000f0000 00010000 2 Add to e820 map: feffc000 00004000 2 Ram Size=0x08000000 (0x0000000000000000 high) malloc setup Add to e820 map: 07ff0000 00010000 2 pmm_malloc zone=0x000f0930 handle=ffffffff size=63248 align=10 ret=0x07fe07d0 (detail=0x07fefee0) Relocating init from 0x000e12d0 to 0x07fe07d0 (size 63248) malloc fixup reloc init ivt init bda Add to e820 map: 0009fc00 00000400 2 init pic init timer tsc calibrate start=2127316692 end=2133865272 diff=6548580 CPU Mhz=3815 math cp init init mtrr pci setup === PCI bus & bridge init === PCI: pci_bios_init_bus_rec bus = 0x0 === PCI device probing === PCI probe pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0700 (detail=0x07fe0770) PCI device 00:00.0 (vd=8086:1237 c=0600) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0660 (detail=0x07fe06d0) PCI device 00:01.0 (vd=8086:7000 c=0601) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe05c0 (detail=0x07fe0630) PCI device 00:01.1 (vd=8086:7010 c=0101) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0520 (detail=0x07fe0590) PCI device 00:01.3 (vd=8086:7113 c=0680) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0480 (detail=0x07fe04f0) PCI device 00:02.0 (vd=1013:00b8 c=0300) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe03e0 (detail=0x07fe0450) PCI device 00:03.0 (vd=10ec:8139 c=0200) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0340 (detail=0x07fe03b0) PCI device 00:06.0 (vd=10de:01d3 c=0300) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe02a0 (detail=0x07fe0310) PCI device 00:07.0 (vd=10de:01d3 c=0300) Found 8 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === pmm_malloc zone=0x07fefe30 handle=ffffffff size=528 align=10 ret=0x07fe0060 (detail=0x07fe0270) PCI: check devices bus 0 PCI: out of address space

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS October 2011