Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
07.03.2013 10:12, Doug Goldstein wrote: > On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge wrote: >> Yeah, it is very common. Lots of distributions patch their >> toolchains such that they don't compile firmware code correctly. >> >> Firmware isn't a common target, so I understand that it happens. >> >> For coreboot we recommend to build a vanilla toolchain using known >> good versions. We also have a script to do that. (The script is at >> util/crossgcc/buildgcc in the coreboot repo.) [] > Not sure if you or Kevin builds the coreboot images at > http://code.coreboot.org/p/seabios/downloads/, but would you guys > consider building point release as well (e.g. 1.7.2.1), if yes then my > next question... > > The rest of the ML, > > Would qemu consider using those blobs rather than different developers > using their distro toolchain to build up a random commit ID. I say > random only because often qemu releases ship with a non-release > seabios. > > In this past there's been other issues related to seabios + qemu, that > I've solved in Gentoo by simply using the coreboot seabios images > after some troubleshooting help from Peter. Similarly our Ubuntu > OpenStack machines at work had quirks resolved by dropping the > coreboot seabios images on them. Just a note, or an "alternative opinion", so to say. In Debian, we have a social contract which, among other things, ensures that the binaries you, as a user, get, comes with source which you can modify on the system you installed. This requires, for example, that all binaries shipped are actually built from the corresponding source, and that no blobs from whatever other sources are used, ever. We don't even ship any upstream blobs in the debian qemu _source_ package: we repack upstream qemu.tar.gz by removing these blobs. So from this PoV, it'd be better if upstream didn't ship any blobs at all, -- we wont need to repack the upstream .tar.gz ;) FWIW, prpbably we were lucky so far: we had almost no issues with (mis)compiling of various ROM codes (bochsbios, seabios, vgabios, pxe roms, various sparc/ppc firmware etc) using toolchains provided by Debian. Thanks, /mjt ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH 2/2] acpi: Eliminate BDAT parameter passing to DSDT code.
The "BDAT" construct is the only ACPI mechanism that relies on SeaBIOS
reserved memory. Replace it with the SSDT based template system.
Signed-off-by: Kevin O'Connor
---
src/acpi-dsdt-pci-crs.dsl | 61 +--
src/acpi.c| 39 ++
src/acpi.h| 9 ---
src/ssdt-misc.dsl | 20
tools/acpi_extract.py | 17 -
5 files changed, 71 insertions(+), 75 deletions(-)
diff --git a/src/acpi-dsdt-pci-crs.dsl b/src/acpi-dsdt-pci-crs.dsl
index 802eebc..d421891 100644
--- a/src/acpi-dsdt-pci-crs.dsl
+++ b/src/acpi-dsdt-pci-crs.dsl
@@ -56,52 +56,35 @@ Scope(\_SB.PCI0) {
})
Method(_CRS, 0) {
-/* see see acpi.h, struct bfld */
-External(BDAT, OpRegionObj)
-Field(BDAT, QWordAcc, NoLock, Preserve) {
-P0S, 64,
-P0E, 64,
-P0L, 64,
-P1S, 64,
-P1E, 64,
-P1L, 64,
-}
-Field(BDAT, DWordAcc, NoLock, Preserve) {
-P0SL, 32,
-P0SH, 32,
-P0EL, 32,
-P0EH, 32,
-P0LL, 32,
-P0LH, 32,
-P1SL, 32,
-P1SH, 32,
-P1EL, 32,
-P1EH, 32,
-P1LL, 32,
-P1LH, 32,
-}
+/* Fields provided by dynamically created ssdt */
+External(P0S, IntObj)
+External(P0E, IntObj)
+External(P1V, IntObj)
+External(P1S, BuffObj)
+External(P1E, BuffObj)
+External(P1L, BuffObj)
/* fixup 32bit pci io window */
CreateDWordField(CRES, \_SB.PCI0.PW32._MIN, PS32)
CreateDWordField(CRES, \_SB.PCI0.PW32._MAX, PE32)
CreateDWordField(CRES, \_SB.PCI0.PW32._LEN, PL32)
-Store(P0SL, PS32)
-Store(P0EL, PE32)
-Store(P0LL, PL32)
+Store(P0S, PS32)
+Store(P0E, PE32)
+Store(Add(Subtract(P0E, P0S), 1), PL32)
-If (LAnd(LEqual(P1SL, 0x00), LEqual(P1SH, 0x00))) {
+If (LEqual(P1V, Zero)) {
Return (CRES)
-} Else {
-/* fixup 64bit pci io window */
-CreateQWordField(CR64, \_SB.PCI0.PW64._MIN, PS64)
-CreateQWordField(CR64, \_SB.PCI0.PW64._MAX, PE64)
-CreateQWordField(CR64, \_SB.PCI0.PW64._LEN, PL64)
-Store(P1S, PS64)
-Store(P1E, PE64)
-Store(P1L, PL64)
-/* add window and return result */
-ConcatenateResTemplate(CRES, CR64, Local0)
-Return (Local0)
}
+
+/* fixup 64bit pci io window */
+CreateQWordField(CR64, \_SB.PCI0.PW64._MIN, PS64)
+CreateQWordField(CR64, \_SB.PCI0.PW64._MAX, PE64)
+CreateQWordField(CR64, \_SB.PCI0.PW64._LEN, PL64)
+Store(P1S, PS64)
+Store(P1E, PE64)
+Store(P1L, PL64)
+/* add window and return result */
+ConcatenateResTemplate(CRES, CR64, Local0)
+Return (Local0)
}
}
diff --git a/src/acpi.c b/src/acpi.c
index 658ca50..98a5d40 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -501,7 +501,6 @@ build_ssdt(void)
+ (acpi_cpus * PROC_SIZEOF) // procs
+ (1+2+5+(12*acpi_cpus)) // NTFY
+ (6+2+1+(1*acpi_cpus)) // CPON
- + 17 // BDAT
+ (1+3+4) // Scope(PCI0)
+ ((PCI_SLOTS - 1) * PCIHP_SIZEOF)// slots
+ (1+2+5+(12*(PCI_SLOTS - 1; // PCNT
@@ -525,6 +524,19 @@ build_ssdt(void)
ssdt_ptr[acpi_s4_name[0]] = 'X';
else
ssdt_ptr[acpi_s4_pkg[0] + 1] = ssdt[acpi_s4_pkg[0] + 3] =
sys_states[4] & 127;
+
+// store pci io windows
+*(u32*)&ssdt_ptr[acpi_pci32_start[0]] = pcimem_start;
+*(u32*)&ssdt_ptr[acpi_pci32_end[0]] = pcimem_end - 1;
+if (pcimem64_start) {
+ssdt_ptr[acpi_pci64_valid[0]] = 1;
+*(u64*)&ssdt_ptr[acpi_pci64_start[0]] = pcimem64_start;
+*(u64*)&ssdt_ptr[acpi_pci64_end[0]] = pcimem64_end - 1;
+*(u64*)&ssdt_ptr[acpi_pci64_length[0]] = pcimem64_end - pcimem64_start;
+} else {
+ssdt_ptr[acpi_pci64_valid[0]] = 0;
+}
+
ssdt_ptr += sizeof(ssdp_misc_aml);
// build Scope(_SB_) header
@@ -562,31 +574,6 @@ build_ssdt(void)
for (i=0; ip0s = pcimem_start;
-bfld->p0e = pcimem_end - 1;
-bfld->p0l = pcimem_end - pcimem_start;
-bfld->p1s = pcimem64_start;
-bfld->p1e = pcimem64_end - 1;
-bfld->p1l = pcimem64_end - pcimem64_start;
-
-// build "OperationRegion(BDAT, SystemMemory, 0x12345678, 0x87654321)"
-*(ssdt_ptr++) = 0x5B; // ExtOpPrefix
-*(ssdt_ptr++) = 0x80; // OpRegionOp
-*(ssdt_ptr++) = 'B';
-*(ssdt_ptr++) = 'D';
-*(ssdt_ptr++) = 'A';
-*(ssdt_ptr++) = 'T';
-*(ssdt_ptr++) = 0x00; // SystemMemory
-
[SeaBIOS] [PATCH 1/2] Rename src/ssdt-susp.dsl to src/ssdt-misc.dsl.
Signed-off-by: Kevin O'Connor
---
Makefile | 2 +-
src/acpi.c| 8
src/ssdt-misc.dsl | 38 ++
src/ssdt-susp.dsl | 38 --
4 files changed, 43 insertions(+), 43 deletions(-)
create mode 100644 src/ssdt-misc.dsl
delete mode 100644 src/ssdt-susp.dsl
diff --git a/Makefile b/Makefile
index 1ce2f79..ada8fa5 100644
--- a/Makefile
+++ b/Makefile
@@ -220,7 +220,7 @@ $(OUT)%.hex: src/%.dsl ./tools/acpi_extract_preprocess.py
./tools/acpi_extract.p
$(Q)$(PYTHON) ./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off
$(Q)cat $(OUT)$*.off > $@
-$(OUT)acpi.o: $(OUT)acpi-dsdt.hex $(OUT)ssdt-proc.hex $(OUT)ssdt-pcihp.hex
$(OUT)ssdt-susp.hex $(OUT)q35-acpi-dsdt.hex
+$(OUT)acpi.o: $(OUT)acpi-dsdt.hex $(OUT)ssdt-proc.hex $(OUT)ssdt-pcihp.hex
$(OUT)ssdt-misc.hex $(OUT)q35-acpi-dsdt.hex
Kconfig rules
diff --git a/src/acpi.c b/src/acpi.c
index 195dc88..658ca50 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -439,7 +439,7 @@ encodeLen(u8 *ssdt_ptr, int length, int bytes)
#define SSDT_SIGNATURE 0x54445353 // SSDT
#define SSDT_HEADER_LENGTH 36
-#include "ssdt-susp.hex"
+#include "ssdt-misc.hex"
#include "ssdt-pcihp.hex"
#define PCI_RMV_BASE 0xae0c
@@ -496,7 +496,7 @@ static void*
build_ssdt(void)
{
int acpi_cpus = MaxCountCPUs > 0xff ? 0xff : MaxCountCPUs;
-int length = (sizeof(ssdp_susp_aml) // _S3_ / _S4_ /
_S5_
+int length = (sizeof(ssdp_misc_aml) // _S3_ / _S4_ /
_S5_
+ (1+3+4) // Scope(_SB_)
+ (acpi_cpus * PROC_SIZEOF) // procs
+ (1+2+5+(12*acpi_cpus)) // NTFY
@@ -518,14 +518,14 @@ build_ssdt(void)
if (!sys_states || sys_state_size != 6)
sys_states = (char[]){128, 0, 0, 129, 128, 128};
-memcpy(ssdt_ptr, ssdp_susp_aml, sizeof(ssdp_susp_aml));
+memcpy(ssdt_ptr, ssdp_misc_aml, sizeof(ssdp_misc_aml));
if (!(sys_states[3] & 128))
ssdt_ptr[acpi_s3_name[0]] = 'X';
if (!(sys_states[4] & 128))
ssdt_ptr[acpi_s4_name[0]] = 'X';
else
ssdt_ptr[acpi_s4_pkg[0] + 1] = ssdt[acpi_s4_pkg[0] + 3] =
sys_states[4] & 127;
-ssdt_ptr += sizeof(ssdp_susp_aml);
+ssdt_ptr += sizeof(ssdp_misc_aml);
// build Scope(_SB_) header
*(ssdt_ptr++) = 0x10; // ScopeOp
diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
new file mode 100644
index 000..f0a8df3
--- /dev/null
+++ b/src/ssdt-misc.dsl
@@ -0,0 +1,38 @@
+ACPI_EXTRACT_ALL_CODE ssdp_misc_aml
+
+DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
+{
+
+/
+ * Suspend
+ /
+
+Scope(\) {
+/*
+ * S3 (suspend-to-ram), S4 (suspend-to-disk) and S5 (power-off) type codes:
+ * must match piix4 emulation.
+ */
+
+ACPI_EXTRACT_NAME_STRING acpi_s3_name
+Name(_S3, Package(0x04) {
+One, /* PM1a_CNT.SLP_TYP */
+One, /* PM1b_CNT.SLP_TYP */
+Zero, /* reserved */
+Zero /* reserved */
+})
+ACPI_EXTRACT_NAME_STRING acpi_s4_name
+ACPI_EXTRACT_PKG_START acpi_s4_pkg
+Name(_S4, Package(0x04) {
+0x2, /* PM1a_CNT.SLP_TYP */
+0x2, /* PM1b_CNT.SLP_TYP */
+Zero, /* reserved */
+Zero /* reserved */
+})
+Name(_S5, Package(0x04) {
+Zero, /* PM1a_CNT.SLP_TYP */
+Zero, /* PM1b_CNT.SLP_TYP */
+Zero, /* reserved */
+Zero /* reserved */
+})
+}
+}
diff --git a/src/ssdt-susp.dsl b/src/ssdt-susp.dsl
deleted file mode 100644
index ca9428f..000
--- a/src/ssdt-susp.dsl
+++ /dev/null
@@ -1,38 +0,0 @@
-ACPI_EXTRACT_ALL_CODE ssdp_susp_aml
-
-DefinitionBlock ("ssdt-susp.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
-{
-
-/
- * Suspend
- /
-
-Scope(\) {
-/*
- * S3 (suspend-to-ram), S4 (suspend-to-disk) and S5 (power-off) type codes:
- * must match piix4 emulation.
- */
-
-ACPI_EXTRACT_NAME_STRING acpi_s3_name
-Name(_S3, Package(0x04) {
-One, /* PM1a_CNT.SLP_TYP */
-One, /* PM1b_CNT.SLP_TYP */
-Zero, /* reserved */
-Zero /* reserved */
-})
-ACPI_EXTRACT_NAME_STRING acpi_s4_name
-ACPI_EXTRACT_PKG_START acpi_s4_pkg
-Name(_S4, Package(0x04) {
-0x2, /* PM1a_CNT.SLP_TYP */
-0x2, /* PM1b_CNT.SLP_TYP */
-Zero, /* reserved */
-Zero /* reserved */
-})
-Name(_S5, Package(0x04) {
-Zero, /* PM1a_CNT.SLP_TYP */
-Zero, /* PM1
[SeaBIOS] [PATCH 0/2][RFC] Remove BDAT from ACPI interface
This patch changes SeaBIOS to pass the PCI regions via a dynamically updated SSDT instead of via the BDAT memory reference system. This change will likely make it easier to port the ACPI tables to QEMU. This patch has only been lightly tested. Gerd - I know you ran various tests when originally introducing the BDAT system. Do you recall what test cases you used? -Kevin Kevin O'Connor (2): Rename src/ssdt-susp.dsl to src/ssdt-misc.dsl. acpi: Eliminate BDAT parameter passing to DSDT code. Makefile | 2 +- src/acpi-dsdt-pci-crs.dsl | 61 +-- src/acpi.c| 47 +--- src/acpi.h| 9 --- src/ssdt-misc.dsl | 58 src/ssdt-susp.dsl | 38 - tools/acpi_extract.py | 17 - 7 files changed, 114 insertions(+), 118 deletions(-) create mode 100644 src/ssdt-misc.dsl delete mode 100644 src/ssdt-susp.dsl -- 1.7.11.7 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] problems with freeBSD
Laszlo Ersek wrote: > Going out on a limb, I suspect qemu commit 5f876756 instead. .. > I think the gcc version Anthony was using miscompiled SeaBIOS Yeah, it is very common. Lots of distributions patch their toolchains such that they don't compile firmware code correctly. Firmware isn't a common target, so I understand that it happens. For coreboot we recommend to build a vanilla toolchain using known good versions. We also have a script to do that. (The script is at util/crossgcc/buildgcc in the coreboot repo.) //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] problems with freeBSD
On 03/07/13 01:53, Kevin O'Connor wrote: > On Thu, Mar 07, 2013 at 12:12:08AM +0100, Aurelien Jarno wrote: >> On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote: >>> Using qemu 1.4.0: >>> >>> # qemu -hda test.raw -m 512 -cdrom >>> pfSense-LiveCD-2.0.2-RELEASE-amd64-20121207-2239.iso >>> >>> Results in: >>> >>> trap 12: page fault while in kernel mode >>> ... >>> stopped at x86bios_emu_rdw+0x2f: movzwl (%rbx),%eax >>> >>> Any ideas? Can somebody reproduce that? >>> >>> To get the FreeBSD VM boot use the console, enter the boot loader, then: >>> # set hint.atkbd.0.disabled="1" >>> # boot >>> >>> But that disables the keyboard. Apparently the call may come from get_typematic() [sys/dev/atkbdc/atkbd.c]; it wants to retrieve the typematic rate of the keyboard using the BIOS. >> >> I was actually digging about that problem. It is indeed present in >> version 1.4.0, but is fixed in the current git master. The problem is >> actually not directly in QEMU but in seabios, the update to version >> 1.7.2.1 commit 5c75fb10) fixes the issue. Maybe it is worth >> cherry-picking it into stable-1.4 (hence the Cc:). In the meantime >> using bios.bin from master with QEMU version 1.4.0 should also fix the >> issue. >> >> What is strange is the seabios commit fixing the issue: >> >> commit 4219149ad2b783abfa61e80e9e9f6910db0c76c9 >> Author: Kevin O'Connor >> Date: Sun Feb 17 10:56:10 2013 -0500 >> >> build: Don't require $(OUT) to be a sub-directory of the main >> directory. > > That change is definitely just build related - I don't see how it > could impact the final SeaBIOS binary. How did you conclude that this > commit is what fixes the issue? Going out on a limb, I suspect qemu commit 5f876756 instead. (It's a bit risky for me to say that, as Aurelien may have taken qemu-1.4.0 as fixed point and bisected seabios rel-1.7.2..rel-1.7.2.1 against it: $ git log --oneline --reverse rel-1.7.2..rel-1.7.2.1 f396871 Update tools/acpi_extract.py to handle iasl 20130117 release. 12e8199 USB-EHCI: Fix null pointer assignment d75c22f Fix Makefile - don't reference "out/" directly, instead use "$(OUT)". 4219149 build: Don't require $(OUT) to be a sub-directory of the main directory. e5fe4f9 Verify CC is valid during build tests. 2b57726 seabios q35: Enable all PIRQn IRQs at startup 985a9d3 seabios q35: Add new PCI slot to irq routing function 88cb66e seabios: Add a dummy PCI slot to irq mapping function ) I'm suspecting said qemu commit because: - it's the final commit in 1.4 for file "pc-bios/bios.bin", - somewhat out of the ordinary, apparently, it was Anthony to rebuild the bios, and he used gcc-4.7.2 on Fedora 18, - while normally Gerd does the updates (see both before and after 5f876756), and I know for a fact Gerd uses RHEL-6. I think the gcc version Anthony was using miscompiled SeaBIOS (in the sense that FreeBSD chokes on it), and the 1.7.2.1 binary from Gerd restores peace *only* because Gerd relied on RHEL-6 gcc, and not because of the SeaBIOS changes from 1.7.2 to 1.7.2.1. $ git log --reverse -- pc-bios/bios.bin Probably works, but never appeared in a separate release: commit 3588185b8396eb97fd9efd41c2b97775465f67c4 Author: Gerd Hoffmann Date: Mon Jan 21 09:17:16 2013 +0100 seabios: update to 1.7.2 release Not that many changes as we have a pretty recent git snapshot in master already: Hannes Reinecke (1): megasas: Invert PCI device selection Kevin O'Connor (2): Minor: Separate UUID display from F12 boot prompt. boot: Support "halt" in the boot order to prevent default boot attempts. Laszlo Ersek (1): display_uuid(): fix incomplete check after the loop Paolo Bonzini (1): vgabios: implement AX=1120H..1124H functions Exposes problem (released in qemu-1.4.0): commit 5f876756c57c15f5e14d4136fc432b74f05f082b Author: Anthony Liguori Date: Wed Feb 6 05:12:06 2013 -0600 bios: recompile BIOS SeaBIOS is really close to spilling over to 256k. Until we can better handle migration across RAM block size changes, recompile SeaBIOS with a compiler that causes the binary to still fit in 128k. This was built with: gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) On 64-bit Fedora 18. Signed-off-by: Anthony Liguori Works again (unreleased), according to Aurelien's testing: commit 5c75fb10029c5fd1e705a6ef5d698fbea06c7a33 Author: Gerd Hoffmann Date: Thu Feb 28 09:18:56 2013 +0100 update seabios to 1.7.2.1 Alex Williamson (3): seabios q35: Enable all PIRQn IRQs at startup seabios q35: Add new PCI slot to irq routing function seabios: Add a dummy PCI slot to irq mapping function Avik Sil (1): USB-EHCI: Fix null pointer assignment Kevi
Re: [SeaBIOS] Build errors with Clang 3.2: src/ioport.h:126:18: error: invalid operand for instruction
On Tue, Mar 05, 2013 at 03:20:57PM -0800, H. Peter Anvin wrote:
> On 03/04/2013 03:58 PM, Kevin O'Connor wrote:
> > On Mon, Mar 04, 2013 at 04:15:51PM +0100, Paul Menzel wrote:
> >> to build SeaBIOS, Clang throws the following errors.
> > [...]
> >> In file included from src/ata.c:9:
> >> src/ioport.h:126:18: error: invalid operand for instruction
> >> asm volatile("rep outsw %%es:(%%esi), (%%dx)"
> >> ^
> >
> > I'm not familiar with Clang, but I don't see anything wrong with this
> > particular assembler statement. Is this the only thing Clang has
> > issues with?
> >
>
> Wouldn't simply "es rep outsw" be better? The operands are implicit
> anyway, except for the source segment override.
I kind of prefer to be explicit with the source operands (for
documentation purposes). Otherwise, it's not really a big deal.
Paul, does Clang prefer "es rep outsw"?
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Seabios PATCH v2] make reboot-timeout to static for using it after POST phase
On Tue, Mar 05, 2013 at 05:52:21PM +0800, Amos Kong wrote: > From: Kevin O'Connor > > Memory allocated with malloc_tmp() can't be used after the POST > phase. The reboot-timeout inside romfile could not be loaded in > boot_fail(). The patch saved reboot-timeout to a static variable, > it fixed the regression bug introduced by commit 59d6ca52 FYI, this fix was committed. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] problems with freeBSD
On Thu, Mar 07, 2013 at 12:12:08AM +0100, Aurelien Jarno wrote: > On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote: > > Using qemu 1.4.0: > > > > # qemu -hda test.raw -m 512 -cdrom > > pfSense-LiveCD-2.0.2-RELEASE-amd64-20121207-2239.iso > > > > Results in: > > > > trap 12: page fault while in kernel mode > > ... > > stopped at x86bios_emu_rdw+0x2f: movzwl (%rbx),%eax > > > > Any ideas? Can somebody reproduce that? > > > > To get the FreeBSD VM boot use the console, enter the boot loader, then: > > # set hint.atkbd.0.disabled="1" > > # boot > > > > But that disables the keyboard. > > I was actually digging about that problem. It is indeed present in > version 1.4.0, but is fixed in the current git master. The problem is > actually not directly in QEMU but in seabios, the update to version > 1.7.2.1 commit 5c75fb10) fixes the issue. Maybe it is worth > cherry-picking it into stable-1.4 (hence the Cc:). In the meantime > using bios.bin from master with QEMU version 1.4.0 should also fix the > issue. > > What is strange is the seabios commit fixing the issue: > > commit 4219149ad2b783abfa61e80e9e9f6910db0c76c9 > Author: Kevin O'Connor > Date: Sun Feb 17 10:56:10 2013 -0500 > > build: Don't require $(OUT) to be a sub-directory of the main > directory. That change is definitely just build related - I don't see how it could impact the final SeaBIOS binary. How did you conclude that this commit is what fixes the issue? -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] problems with freeBSD
On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote: > Using qemu 1.4.0: > > # qemu -hda test.raw -m 512 -cdrom > pfSense-LiveCD-2.0.2-RELEASE-amd64-20121207-2239.iso > > Results in: > > trap 12: page fault while in kernel mode > ... > stopped at x86bios_emu_rdw+0x2f: movzwl (%rbx),%eax > > Any ideas? Can somebody reproduce that? > > To get the FreeBSD VM boot use the console, enter the boot loader, then: > # set hint.atkbd.0.disabled="1" > # boot > > But that disables the keyboard. I was actually digging about that problem. It is indeed present in version 1.4.0, but is fixed in the current git master. The problem is actually not directly in QEMU but in seabios, the update to version 1.7.2.1 commit 5c75fb10) fixes the issue. Maybe it is worth cherry-picking it into stable-1.4 (hence the Cc:). In the meantime using bios.bin from master with QEMU version 1.4.0 should also fix the issue. What is strange is the seabios commit fixing the issue: commit 4219149ad2b783abfa61e80e9e9f6910db0c76c9 Author: Kevin O'Connor Date: Sun Feb 17 10:56:10 2013 -0500 build: Don't require $(OUT) to be a sub-directory of the main directory. Remove references to "../" and "out/" from the build so that "make OUT=/a/b/c/" will work. Signed-off-by: Kevin O'Connor Maybe Kevin has an explanation? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] i915 status on x60.
On Sun, 3 Mar 2013 22:58:46 -0500
ron minnich wrote:
> setgtt is only for hardware with a gtt. Again, I'm not familiar with
> the hardware on this laptop. Does it have a gtt?
it seems so(from the xf86-video-intel mentioned before):
if (IS_G4X(pI830))
gtt = (unsigned char *)(pI830->mmio + MB(2));
else if (IS_I965G(pI830))
gtt = (unsigned char *)(pI830->mmio + KB(512));
else {
/* 915/945 chips has GTT range in bar 3*/
int err = 0;
err = pci_device_map_range (pI830->pci_dev,
pI830->pci_dev->regions[3].base_addr,
pI830->pci_dev->regions[3].size,
PCI_DEV_MAP_FLAG_WRITABLE,
(void **)>t);
if (err != 0) {
fprintf(stderr, "mapping GTT bar failed\n");
exit(1);
}
}
So the GTT would be on the bar 3:
# lspci -s 00:02.0 -
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00
[VGA controller]) Subsystem: Lenovo ThinkPad T60/R60 series Control:
I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=fast >TAbort- SERR- [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: Data:
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable-
DSel=0 DScale=0 PME-
And the datasheets for the 945G also talks about the GTT like the
GTTADR registers etc...
Denis.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Build errors with Clang 3.2: src/ioport.h:126:18: error: invalid operand for instruction
Am Mittwoch, den 06.03.2013, 11:49 +0100 schrieb Paul Menzel:
> Am Montag, den 04.03.2013, 18:58 -0500 schrieb Kevin O'Connor:
> > On Mon, Mar 04, 2013 at 04:15:51PM +0100, Paul Menzel wrote:
> > > to build SeaBIOS, Clang throws the following errors.
> > [...]
> > > In file included from src/ata.c:9:
> > > src/ioport.h:126:18: error: invalid operand for instruction
> > > asm volatile("rep outsw %%es:(%%esi), (%%dx)"
> > > ^
> >
> > I'm not familiar with Clang, but I don't see anything wrong with this
> > particular assembler statement.
>
> Alright, then I will report that to the Clang folks.
This issue is tracked in ticket 15455 in the LLVM Bugzilla bug tracking
system [1].
> > Is this the only thing Clang has issues with?
>
> I am not sure, as the build stops after this error.
[…]
Thanks,
Paul
[1] http://llvm.org/bugs/show_bug.cgi?id=15455
signature.asc
Description: This is a digitally signed message part
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Build errors with Clang 3.2: src/ioport.h:126:18: error: invalid operand for instruction
On 03/04/2013 03:58 PM, Kevin O'Connor wrote:
> On Mon, Mar 04, 2013 at 04:15:51PM +0100, Paul Menzel wrote:
>> to build SeaBIOS, Clang throws the following errors.
> [...]
>> In file included from src/ata.c:9:
>> src/ioport.h:126:18: error: invalid operand for instruction
>> asm volatile("rep outsw %%es:(%%esi), (%%dx)"
>> ^
>
> I'm not familiar with Clang, but I don't see anything wrong with this
> particular assembler statement. Is this the only thing Clang has
> issues with?
>
Wouldn't simply "es rep outsw" be better? The operands are implicit
anyway, except for the source segment override.
-hpa
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 4/3] wakeup: only reset the CPU
Il 05/03/2013 20:12, Laszlo Ersek ha scritto: > On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03 +0100, > Paolo Bonzini wrote: >>> Resuming from suspend-to-RAM should not reset all devices. Only the >>> CPU should get a reset signal. >> >> Hm... on reflection, I don't actually know if this is true. >> >> Perhaps we *should* reset all devices. After all, in a real machine >> they'll all have been turned off and the RAM will have been in >> self-refresh. Surely they have to be reset? >> >> So maybe we should *let* the i440FX PAM registers get reset to point to >> ROM. And fix the firmware to *cope* with that, check to see if the >> shadow RAM already holds an image of a started-up firmware with the >> correct checksum, and jump back to it. >> >> That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't work >> if the PAM configuration is reset? > > I think it is indeed a problem with SeaBIOS. Open romlayout.S: [...] > > It checks the CMOS only after looking at HaveRunPost. The value of > HaveRunPost depends on the PAM settings. It's always 0 in ROM, in which > case we continue at handle_post() [src/post.c]. Actually, Peter explained that it is okay. S3 doesn't clear the PAM configuration, but S4 does. The PAM registers are attached to the same power line as the RAM. Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Build errors with Clang 3.2: src/ioport.h:126:18: error: invalid operand for instruction
Am Montag, den 04.03.2013, 18:58 -0500 schrieb Kevin O'Connor:
> On Mon, Mar 04, 2013 at 04:15:51PM +0100, Paul Menzel wrote:
> > to build SeaBIOS, Clang throws the following errors.
> [...]
> > In file included from src/ata.c:9:
> > src/ioport.h:126:18: error: invalid operand for instruction
> > asm volatile("rep outsw %%es:(%%esi), (%%dx)"
> > ^
>
> I'm not familiar with Clang, but I don't see anything wrong with this
> particular assembler statement.
Alright, then I will report that to the Clang folks.
> Is this the only thing Clang has issues with?
I am not sure, as the build stops after this error.
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 4/3] wakeup: only reset the CPU
On 03/05/13 20:25, Paolo Bonzini wrote: > Il 05/03/2013 20:12, Laszlo Ersek ha scritto: >> On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03 >> +0100, Paolo Bonzini wrote: Resuming from suspend-to-RAM should not reset all devices. Only the CPU should get a reset signal. >>> >>> Hm... on reflection, I don't actually know if this is true. >>> >>> Perhaps we *should* reset all devices. After all, in a real machine >>> they'll all have been turned off and the RAM will have been in >>> self-refresh. Surely they have to be reset? >>> >>> So maybe we should *let* the i440FX PAM registers get reset to point to >>> ROM. And fix the firmware to *cope* with that, check to see if the >>> shadow RAM already holds an image of a started-up firmware with the >>> correct checksum, and jump back to it. >>> >>> That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't work >>> if the PAM configuration is reset? >> >> I think it is indeed a problem with SeaBIOS. Open romlayout.S: [...] >> >> It checks the CMOS only after looking at HaveRunPost. The value of >> HaveRunPost depends on the PAM settings. It's always 0 in ROM, in which >> case we continue at handle_post() [src/post.c]. > > Actually, Peter explained that it is okay. S3 doesn't clear the PAM > configuration, but S4 does. The PAM registers are attached to the same > power line as the RAM. Ah, you expect me to understand that "memory controller configuration" is a superset of the PAM registers :) Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH v2] pciinit: Enable default VGA device
As QEMU gains PCI bridge and PCIe root port support, we won't always
find the VGA device on the root bus. We therefore need to add support
to find and enable a VGA device and the path to it through the VGA
Enable support in the PCI bridge control register.
Signed-off-by: Alex Williamson
---
src/optionroms.c |2 +-
src/pciinit.c| 45 +
src/util.h |1 +
3 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index caa2151..ac92613 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -213,7 +213,7 @@ run_file_roms(const char *prefix, int isvga, u64 *sources)
/
// Verify device is a vga device with legacy address decoding enabled.
-static int
+int
is_pci_vga(struct pci_device *pci)
{
if (pci->class != PCI_CLASS_DISPLAY_VGA)
diff --git a/src/pciinit.c b/src/pciinit.c
index ce0a4cc..eb49a76 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -316,6 +316,49 @@ static void pci_bios_init_devices(void)
}
}
+static void pci_enable_default_vga(void)
+{
+struct pci_device *pci;
+
+foreachpci(pci) {
+if (is_pci_vga(pci)) {
+dprintf(1, "PCI: Using %02x:%02x.%x for primary VGA\n",
+pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+pci_bdf_to_fn(pci->bdf));
+return;
+}
+}
+
+pci = pci_find_class(PCI_CLASS_DISPLAY_VGA);
+if (!pci) {
+dprintf(1, "PCI: No VGA devices found\n");
+return;
+}
+
+dprintf(1, "PCI: Enabling %02x:%02x.%x for primary VGA\n",
+pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+pci_bdf_to_fn(pci->bdf));
+
+u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
+cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+pci_config_writew(pci->bdf, PCI_COMMAND, cmd);
+
+while (pci->parent) {
+pci = pci->parent;
+
+dprintf(1, "PCI: Setting VGA enable on bridge %02x:%02x.%x\n",
+pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+pci_bdf_to_fn(pci->bdf));
+
+u8 ctrl = pci_config_readb(pci->bdf, PCI_BRIDGE_CONTROL);
+ctrl |= PCI_BRIDGE_CTL_VGA;
+pci_config_writeb(pci->bdf, PCI_BRIDGE_CONTROL, ctrl);
+
+u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
+cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+pci_config_writew(pci->bdf, PCI_COMMAND, cmd);
+}
+}
/
* Platform device initialization
@@ -804,4 +847,6 @@ pci_setup(void)
pci_bios_init_devices();
free(busses);
+
+pci_enable_default_vga();
}
diff --git a/src/util.h b/src/util.h
index 306a8bf..e1df295 100644
--- a/src/util.h
+++ b/src/util.h
@@ -343,6 +343,7 @@ void vgahook_setup(struct pci_device *pci);
// optionroms.c
void call_bcv(u16 seg, u16 ip);
+int is_pci_vga(struct pci_device *pci);
void optionrom_setup(void);
void vgarom_setup(void);
void s3_resume_vga(void);
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 4/3] wakeup: only reset the CPU
On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03 +0100, Paolo Bonzini wrote: >> Resuming from suspend-to-RAM should not reset all devices. Only the >> CPU should get a reset signal. > > Hm... on reflection, I don't actually know if this is true. > > Perhaps we *should* reset all devices. After all, in a real machine > they'll all have been turned off and the RAM will have been in > self-refresh. Surely they have to be reset? > > So maybe we should *let* the i440FX PAM registers get reset to point to > ROM. And fix the firmware to *cope* with that, check to see if the > shadow RAM already holds an image of a started-up firmware with the > correct checksum, and jump back to it. > > That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't work > if the PAM configuration is reset? I think it is indeed a problem with SeaBIOS. (git.seabios.org (80.81.252.135) seems to be down ATM, so I can only check at f465e1ec.) Open romlayout.S: 622 reset_vector: 623 ljmpw $SEG_BIOS, $entry_post 537 entry_post: 538 cmpl $0, %cs:HaveRunPost// Check for resume/reboot 539 jnz entry_resume 540 ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point 239 entry_resume: ... 248 // Call handler. 249 jmp handle_resume handle_resume() [src/resume.c] inb_cmos(CMOS_RESET_CODE) It checks the CMOS only after looking at HaveRunPost. The value of HaveRunPost depends on the PAM settings. It's always 0 in ROM, in which case we continue at handle_post() [src/post.c]. Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Seabios PATCH] make reboot-timeout to static for using it after POST phase
在 2013-03-05二的 10:06 +0800，Amos Kong写道：
> From: Kevin O'Connor
>
> Memory allocated with malloc_tmp() can't be used after the POST
> phase. The reboot-timeout inside romfile could not be loaded in
> boot_fail(). The patch saved reboot-timeout to a static variable,
> it fixed the regression bug introduced by commit 59d6ca52
>
> I already tested this patch, reboot-timeout parameter of qemu
> works now.
> @ qemu -boot reboot-timeout=1000 ...
>
> Signed-off-by: Kevin O'Connor
> Signed-off-by: Amos Kong
> ---
> src/boot.c | 13 -
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/boot.c b/src/boot.c
> index ec411b7..325fac0 100644
> --- a/src/boot.c
> +++ b/src/boot.c
> @@ -235,6 +235,7 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int lun)
> * Boot setup
> /
>
> +static int BootRetryTime;
> static int CheckFloppySig = 1;
>
> #define DEFAULT_PRIO
> @@ -271,6 +272,8 @@ boot_init(void)
> }
> }
>
> +BootRetryTime = romfile_loadint("etc/boot-fail-wait", 60*1000);
> +
> loadBootOrder();
> }
>
> @@ -629,15 +632,15 @@ boot_rom(u32 vector)
> static void
> boot_fail(void)
> {
> -u32 retrytime = romfile_loadint("etc/boot-fail-wait", 60*1000);
> -if (retrytime == (u32)-1)
> +if (BootRetryTime == (u32)-1)
> printf("No bootable device.\n");
> else
> -printf("No bootable device. Retrying in %d seconds.\n",
> retrytime/1000);
> +printf("No bootable device. Retrying in %d seconds.\n"
> + , BootRetryTime/1000);
> // Wait for 'retrytime' milliseconds and then reboot.
s/retrytime/BootRetryTime
> -u32 end = calc_future_timer(retrytime);
> +u32 end = calc_future_timer(BootRetryTime);
> for (;;) {
> -if (retrytime != (u32)-1 && check_timer(end))
> +if (BootRetryTime != (u32)-1 && check_timer(end))
> break;
> yield_toirq();
> }
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
