SeaBIOS November 2011

seabios@seabios.org

22 participants
31 discussions

[BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)

by Alexey Korolev

Hi, We have got some issues with 64bit PCI devices support under Windows guests. Windows fails to start any PCI devices with 64bit BARs when size exceeds 512MB with error code 12 (can't allocate resources). In other words it fails when the PCI memory region is located above 4GB. I tried to investigate this problem and found document from Microsoft: http://msdn.microsoft.com/en-us/windows/hardware/gg462986 It states that the _DSM method must be implemented to support devices above 4GB. Unfortunately I'm not familiar with ACPI code of seabios, so can't implement the _DSM method. May be you have other ideas what needs to be done to fix it? Any help is appreciated. Thanks, Alexey

8 years, 9 months

Re: [SeaBIOS] usb boot issue

by Kevin O'Connor

On Thu, Oct 13, 2011 at 03:56:48PM +0200, Wolfgang Kamp - datakamp wrote: > > Hi, > > is there any solution for the usb boot issue of the AMD SB800 Persimmon platform > with SeaBIOS 1.6.3 and actual Coreboot version? I'm unfamiliar with the issue. Can you post the SeaBIOS debug output along with a description of the issue you are seeing? -Kevin

8 years, 9 months

Re: [SeaBIOS] [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI DSDT tables

by Michael S. Tsirkin

On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote: > ----- Original Message ----- > > On Tue, Sep 20, 2011 at 06:45:57AM -0400, Amos Kong wrote: > > > From 48ea1c9188334b89a60b4f9e853e86fc04fda4a5 Mon Sep 17 00:00:00 > > > 2001 > > > From: Amos Kong <akong(a)redhat.com> > > > Date: Tue, 20 Sep 2011 15:38:43 +0800 > > > Subject: [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI > > > DSDT tables > > > > > > Only func 0 is registered to guest driver (we can > > > only found func 0 in slot->funcs list of driver), > > > the other functions could not be cleaned when > > > hot-removing the whole slot. This patch adds > > > device per function in ACPI DSDT tables. > > > > > > Have tested with linux/winxp/win7, hot-adding/hot-remving, > > > single/multiple function device, they are all fine. > > > --- > > > Changes from v1: > > > - cleanup the macros, bios.bin gets back to 128K > > > - notify only when func0 is added and removed > > > > How about moving code into functions so that it isn't duplicated for > > each PCI device. See the patch below as an example (100% untested). Hmm, I sent patches that did a similar thing but in a slightly more compact way. Message ids: 20110919092932.GB4501(a)redhat.com 20110919093644.GC4501(a)redhat.com 20110919100434.GA6764(a)redhat.com Did they not reach you or something's wrong with them? > > Tested, it works as my original patch-v2. > > > The CPU hotplug stuff works this way, except it run-time generates > > the > > equivalent of "Device(S???)" and "PCNT". (It may make sense to > > run-time generate the PCI hotplug as well - it consumes about 10K of > > space to statically generate the 31 devices.) > > I'm ok with the new version. > > Acked-by: Amos Kong <akong(a)redhat.com> > > > -Kevin > > > > > > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl > > index 08412e2..31ac5eb 100644 > > --- a/src/acpi-dsdt.dsl > > +++ b/src/acpi-dsdt.dsl > > @@ -128,48 +128,6 @@ DefinitionBlock ( > > PCRM, 32, > > } > > > > -#define hotplug_slot(name, nr) \ > > - Device (S##name) { \ > > - Name (_ADR, nr##0000) \ > > - Method (_EJ0,1) { \ > > - Store(ShiftLeft(1, nr), B0EJ) \ > > - Return (0x0) \ > > - } \ > > - Name (_SUN, name) \ > > - } > > - > > - hotplug_slot(1, 0x0001) > > - hotplug_slot(2, 0x0002) > > - hotplug_slot(3, 0x0003) > > - hotplug_slot(4, 0x0004) > > - hotplug_slot(5, 0x0005) > > - hotplug_slot(6, 0x0006) > > - hotplug_slot(7, 0x0007) > > - hotplug_slot(8, 0x0008) > > - hotplug_slot(9, 0x0009) > > - hotplug_slot(10, 0x000a) > > - hotplug_slot(11, 0x000b) > > - hotplug_slot(12, 0x000c) > > - hotplug_slot(13, 0x000d) > > - hotplug_slot(14, 0x000e) > > - hotplug_slot(15, 0x000f) > > - hotplug_slot(16, 0x0010) > > - hotplug_slot(17, 0x0011) > > - hotplug_slot(18, 0x0012) > > - hotplug_slot(19, 0x0013) > > - hotplug_slot(20, 0x0014) > > - hotplug_slot(21, 0x0015) > > - hotplug_slot(22, 0x0016) > > - hotplug_slot(23, 0x0017) > > - hotplug_slot(24, 0x0018) > > - hotplug_slot(25, 0x0019) > > - hotplug_slot(26, 0x001a) > > - hotplug_slot(27, 0x001b) > > - hotplug_slot(28, 0x001c) > > - hotplug_slot(29, 0x001d) > > - hotplug_slot(30, 0x001e) > > - hotplug_slot(31, 0x001f) > > - > > Name (_CRS, ResourceTemplate () > > { > > WordBusNumber (ResourceProducer, MinFixed, MaxFixed, > > PosDecode, > > @@ -762,6 +720,119 @@ DefinitionBlock ( > > Zero /* reserved */ > > }) > > > > + /* PCI hotplug */ > > + Scope(\_SB.PCI0) { > > + /* Methods called by bulk generated PCI devices below */ > > + Method (PCEJ, 1, NotSerialized) { > > + // _EJ0 method - eject callback > > + Store(ShiftLeft(1, Arg0), B0EJ) > > + Return (0x0) > > + } > > + > > + /* Bulk generated PCI hotplug devices */ > > +#define hotplug_func(nr, fn) \ > > + Device (S##nr##fn) { \ > > + Name (_ADR, 0x##nr##000##fn) \ > > + Method (_EJ0, 1) { Return(PCEJ(0x##nr)) } \ > > + Name (_SUN, 0x##nr) \ > > + } The fundamental question is still why would we have _EJ0 methods in functions >0 when they are not individually hotpluggable. I think only function 0 should have _EJ0. > > + > > +#define hotplug_slot(nr) \ > > + hotplug_func(nr, 0) \ > > + hotplug_func(nr, 1) \ > > + hotplug_func(nr, 2) \ > > + hotplug_func(nr, 3) \ > > + hotplug_func(nr, 4) \ > > + hotplug_func(nr, 5) \ > > + hotplug_func(nr, 6) \ > > + hotplug_func(nr, 7) > > + > > + hotplug_slot(01) > > + hotplug_slot(02) > > + hotplug_slot(03) > > + hotplug_slot(04) > > + hotplug_slot(05) > > + hotplug_slot(06) > > + hotplug_slot(07) > > + hotplug_slot(08) > > + hotplug_slot(09) > > + hotplug_slot(0a) > > + hotplug_slot(0b) > > + hotplug_slot(0c) > > + hotplug_slot(0d) > > + hotplug_slot(0e) > > + hotplug_slot(0f) > > + hotplug_slot(10) > > + hotplug_slot(11) > > + hotplug_slot(12) > > + hotplug_slot(13) > > + hotplug_slot(14) > > + hotplug_slot(15) > > + hotplug_slot(16) > > + hotplug_slot(17) > > + hotplug_slot(18) > > + hotplug_slot(19) > > + hotplug_slot(1a) > > + hotplug_slot(1b) > > + hotplug_slot(1c) > > + hotplug_slot(1d) > > + hotplug_slot(1e) > > + hotplug_slot(1f) > > + > > + /* PCI hotplug notify method */ > > + Method(PCNF, 0) { > > + // Local0 = iterator > > + Store (Zero, Local0) > > + While (LLess(Local0, 31)) { > > + Increment(Local0) > > + If (And(PCIU, ShiftLeft(1, Local0))) { > > + PCNT(Local0, 1) > > + } > > + If (And(PCID, ShiftLeft(1, Local0))) { > > + PCNT(Local0, 3) > > + } > > + } > > + Return(One) > > + } > > + > > +#define hotplug_notify(nr) \ > > + If (LEqual(Arg0, 0x##nr)) {Notify(S##nr##0, Arg1)} > > + > > + Method(PCNT, 2) { > > + hotplug_notify(01) > > + hotplug_notify(02) > > + hotplug_notify(03) > > + hotplug_notify(04) > > + hotplug_notify(05) > > + hotplug_notify(06) > > + hotplug_notify(07) > > + hotplug_notify(08) > > + hotplug_notify(09) > > + hotplug_notify(0a) > > + hotplug_notify(0b) > > + hotplug_notify(0c) > > + hotplug_notify(0d) > > + hotplug_notify(0e) > > + hotplug_notify(0f) > > + hotplug_notify(10) > > + hotplug_notify(11) > > + hotplug_notify(12) > > + hotplug_notify(13) > > + hotplug_notify(14) > > + hotplug_notify(15) > > + hotplug_notify(16) > > + hotplug_notify(17) > > + hotplug_notify(18) > > + hotplug_notify(19) > > + hotplug_notify(1a) > > + hotplug_notify(1b) > > + hotplug_notify(1c) > > + hotplug_notify(1d) > > + hotplug_notify(1e) > > + hotplug_notify(1f) > > + } > > + } > > + > > /* CPU hotplug */ > > Scope(\_SB) { > > /* Objects filled in by run-time generated SSDT */ > > @@ -842,49 +913,9 @@ DefinitionBlock ( > > Return(0x01) > > } > > > > -#define gen_pci_hotplug(nr) \ > > - If (And(\_SB.PCI0.PCIU, ShiftLeft(1, nr))) { \ > > - Notify(\_SB.PCI0.S##nr, 1) \ > > - } \ > > - If (And(\_SB.PCI0.PCID, ShiftLeft(1, nr))) { \ > > - Notify(\_SB.PCI0.S##nr, 3) \ > > - } > > - > > Method(_L01) { > > - gen_pci_hotplug(1) > > - gen_pci_hotplug(2) > > - gen_pci_hotplug(3) > > - gen_pci_hotplug(4) > > - gen_pci_hotplug(5) > > - gen_pci_hotplug(6) > > - gen_pci_hotplug(7) > > - gen_pci_hotplug(8) > > - gen_pci_hotplug(9) > > - gen_pci_hotplug(10) > > - gen_pci_hotplug(11) > > - gen_pci_hotplug(12) > > - gen_pci_hotplug(13) > > - gen_pci_hotplug(14) > > - gen_pci_hotplug(15) > > - gen_pci_hotplug(16) > > - gen_pci_hotplug(17) > > - gen_pci_hotplug(18) > > - gen_pci_hotplug(19) > > - gen_pci_hotplug(20) > > - gen_pci_hotplug(21) > > - gen_pci_hotplug(22) > > - gen_pci_hotplug(23) > > - gen_pci_hotplug(24) > > - gen_pci_hotplug(25) > > - gen_pci_hotplug(26) > > - gen_pci_hotplug(27) > > - gen_pci_hotplug(28) > > - gen_pci_hotplug(29) > > - gen_pci_hotplug(30) > > - gen_pci_hotplug(31) > > - > > - Return (0x01) > > - > > + // PCI hotplug event > > + Return(\_SB.PCI0.PCNF()) > > } > > Method(_L02) { > > // CPU hotplug event > >

8 years, 9 months

[PATCH] fix make help

by Sebastian Herbszt

Add help target to top-level makefile. Signed-off-by: Sebastian Herbszt <herbszt(a)gmx.de> diff --git a/Makefile b/Makefile index ef8e15d..c3ba2f3 100644 --- a/Makefile +++ b/Makefile @@ -219,6 +219,9 @@ $(KCONFIG_CONFIG): $(Q)mkdir -p $(OUT)/include/config $(Q)$(MAKE) -C $(OUT) -f $(CURDIR)/tools/kconfig/Makefile srctree=$(CURDIR) src=tools/kconfig obj=tools/kconfig Q=$(Q) Kconfig=$(CURDIR)/src/Kconfig $@ +help: + $(Q)$(MAKE) -f $(CURDIR)/tools/kconfig/Makefile help + ####### Generic rules clean: $(Q)rm -rf $(OUT)

8 years, 9 months

Re: [SeaBIOS] About hotplug multifunction

by Amos Kong

On 09/09/11 15:08, Amos Kong wrote: > Hello all, > > I'm working on hotplug pci multifunction. > > 1. qemu cmdline: > ./x86_64-softmmu/qemu-system-x86_64 -snapshot -m 2000 /home/kvm_autotest_root/images/rhel61-64-virtio.qcow2 -vnc :0 -monitor unix:/tmp/a,server,nowait --enable-kvm -net none > > 2. script to add virtio-blk devices: > for i in `seq 1 7` 0;do > qemu-img create /tmp/resize$i.qcow2 1G -f qcow2 > echo drive_add 0x6.$i id=drv$i,if=none,file=/tmp/resize$i.qcow2 | nc -U /tmp/a > echo device_add virtio-blk-pci,id=dev$i,drive=drv$i,addr=0x6.$i,multifunction=on | nc -U /tmp/a > done > > 3. script to add virio-nic devices: > for i in `seq 1 7` 0;do > echo netdev_add tap,id=drv$i | nc -U /tmp/a > echo device_add virtio-net-pci,id=dev$i,netdev=drv$i,addr=0x6.$i,multifunction=on | nc -U /tmp/a > done > > 4. current qemu behaviors > 4.1. add func 1~7 one by one, then add func 0 > virtio-nic : success, all funcs are added > virtio-blk : success > > 4.2. add func 0~7 one by one > virtio-nic : failed, only func 0 is added > virtio-blk : success > > 4.3. removing any single func in monitor > virtio-nic: func 0 are not found in 'lspci', func 1~7 also exist. eth1~eth7 also exist. > virtio-blk: func 0 are not found in 'lspci', func 1~7 also exist. the device. /dev/vda disappears, > vdb,vdc,vde,vdf,vdg,vdh,vdi,vdj also exist. If I re-add 8 funcs to guest, they all works. > # lspci (00:06.1 ~ 00:06.7 exist, 00:06.0 doesn't exit) > 00:06.1 SCSI storage controller: Red Hat, Inc Virtio block device (rev ff) > > qemu sends an acpi event to guest, then guest will remove all funcs in the slot. > linux-2.6/drivers/pci/hotplug/acpiphp_glue.c: > static int disable_device(struct acpiphp_slot *slot) { > list_for_each_entry(func,&slot->funcs, sibling) { > ... Hello all, I re-tested the multifunction hotplug of winxp,rhel6,win7 guest. (upstream qemu-kvm) For all the guests, func0 needs to be added, otherwise no func can be found in guest. RHEL6 needs to add fun0 in the end, otherwise, the funcs added after hot-adding func0 could not be found in guest. For winxp,win7, add func0 in any time, all the funcs can be found in guest. This is the test result( hogplug order of funcs & funcs can be found in guest): hotplug order xp win7 rhel6 ------------ -- ---- ----- func 0~7 0~7 0~7 0~7 func 0~5 0~6 0~6 0~6 func 1~4,0,5 0~5 0~5 0~4 func 1~4 no no no It looks like the 'problem' of linux guest, or could we accept to add func0 after adding other funcs for linux guest? Thanks, Amos > Questions: > 1. why func1~7 still can be found after hot-remove? is it same as real hardware? > 2. why the func 1~7 could not be added to guest (addingfunc 0~7 one by one)? > 3. how about this interface to hotplug/hot-unplug multifunction: > 1) Add func 1-7 by monitor, add func 0, then send an acpi event to notice guest > 2) Remove func0, send an acpi event to guest. (all funcs can be removed) > 4. what does "reversion 0xff" stand for? > > Thanks in advance, > Amos

8 years, 10 months

[PATCHv4 0/3] acpi: DSDT/SSDT runtime patching

by Michael S. Tsirkin

Here's an updated revision of acpi runtime patching patchset. Lightly tested. changes in v4: - split PCI hotplug handling out to a separate SSDT Changes in v3: - change ssdt generation code to get rid of hardcoded offsets - enhancements to acpi_extract: add more extract methods 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_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 Changes in v2: - tools rewritten in python - Original ASL retains _EJ0 methods, BIOS patches that to EJ0_ - generic ACP_EXTRACT infrastructure that can match Method and Name Operators - instead of matching specific method name, insert tags in original DSL source and match that to AML ----- Here's a bug: guest thinks it can eject VGA device and ISA bridge. [root@dhcp74-172 ~]#lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 PCI bridge: Red Hat, Inc. Device 0001 00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device 00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/ adapter address attention latch module power [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/ adapter address attention latch module power [root@dhcp74-172 ~]# echo 0 > /sys/bus/pci/slots/2/power [root@dhcp74-172 ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:03.0 PCI bridge: Red Hat, Inc. Device 0001 00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device 00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) This is wrong because slots 1 and 2 are marked as not hotpluggable in qemu. The reason is that our acpi tables declare both _RMV with value 0, and _EJ0 method for these slots. What happens in this case is undocumented by ACPI spec, so linux ignores _RMV, and windows seems to ignore _EJ0. The correct way to suppress hotplug is not to have _EJ0, so this is what this patch does: it probes PIIX and modifies DSDT to match. With these patches applied, we get: [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/ address [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/ address Michael S. Tsirkin (3): acpi: add ssdt for pci hotplug acpi: EJ0 method name patching acpi: remove _RMV Makefile | 2 +- src/acpi-dsdt.dsl | 132 +-------------------------------------------------- src/acpi.c | 40 ++++++++++++++++ src/ssdt-pcihp.dsl | 98 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 142 insertions(+), 130 deletions(-) create mode 100644 src/ssdt-pcihp.dsl -- 1.7.5.53.gc233e

8 years, 10 months

[PATCH] virtio-pci: include pci.h and pci_regs.h

by Sebastian Herbszt

Include pci.h and pci_regs.h. Signed-off-by: Sebastian Herbszt <herbszt(a)gmx.de> diff --git a/src/virtio-pci.c b/src/virtio-pci.c index 7e0c1a5..4b9ad0a 100644 --- a/src/virtio-pci.c +++ b/src/virtio-pci.c @@ -19,6 +19,8 @@ #include "virtio-pci.h" #include "config.h" // CONFIG_DEBUG_LEVEL #include "util.h" // dprintf +#include "pci.h" // pci_config_readl +#include "pci_regs.h" // PCI_BASE_ADDRESS_0 int vp_find_vq(unsigned int ioaddr, int queue_index, struct vring_virtqueue **p_vq)

8 years, 10 months

Re: [SeaBIOS] VGA Callback function in SeaBIOS

by Kevin O'Connor

On Tue, Nov 22, 2011 at 05:39:07PM +0100, Wolfgang Kamp - datakamp wrote: > Hi, > > I want to implement a Callback Function (04E08H- System BIOS INT > 15H) for the AMD Video vBIOS (ATOM BIOS Extension Functions) to > support LVDS TFT Displays with AMD G-Series processors (Persimmon > mainboard). What is the best way to do this in SeaBIOS? Take a look at src/vgahooks.c. You'll want to extend that for your board. > I need some parameter like UMA base and size from Coreboot. How can > I transfer this information from Coreboot to SeaBIOS? As ruik mentions - coreboot is itself getting the info from somewhere (eg, the hardware) - if it's not too hard to have seabios pull the info directly that would be ideal. -Kevin

8 years, 10 months

Re: [SeaBIOS] VGA Callback function in SeaBIOS

by Rudolf Marek

> I want to implement a Callback Function (04E08H- System BIOS INT 15H) for the > AMD Video vBIOS (ATOM BIOS Extension Functions) > > to support LVDS TFT Displays with AMD G-Series processors (Persimmon mainboard). Is there any freely accessible documentation? Do you know if VBIOS calls this? I tried to investigate if mine video BIOS is doing any calls but if I recall correctly i havent seen that. I have some trouble with flicker during FID/VID changes any clue here? > > What is the best way to do this in SeaBIOS? I guess just implementing that. > I need some parameter like UMA base and size from Coreboot. How can I transfer > this information from Coreboot to SeaBIOS? Read the config out of the hardware if possible. Check gfx.c in coreboot how to do that. Thanks Rudolf > Thanks, > > Wolfgang > > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios

8 years, 10 months

VGA Callback function in SeaBIOS

by Wolfgang Kamp - datakamp

Hi, I want to implement a Callback Function (04E08H- System BIOS INT 15H) for the AMD Video vBIOS (ATOM BIOS Extension Functions) to support LVDS TFT Displays with AMD G-Series processors (Persimmon mainboard). What is the best way to do this in SeaBIOS? I need some parameter like UMA base and size from Coreboot. How can I transfer this information from Coreboot to SeaBIOS? Thanks, Wolfgang

8 years, 10 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS November 2011