nkage.
Build tested.
Signed-off-by: Laszlo Ersek
---
Please keep me CC'd, I'm not subscribed. Thanks.
src/block.c |2 +-
src/usb-msc.h |1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/block.c b/src/block.c
index eeebd83..ccf4ee6 100644
--- a/src/bl
Hi!
(I hope this will reach the SeaBIOS mailing list, because I'm not
subscribed.)
I've reviewed this patch for RHEL-6 and now diffed the RHEL-6 patch with
this one. I think the differences are all OK (source file list, handling
of the VIRTIO_SCSI config option, bdf vs. pci, contents of struct
vi
On 02/15/12 15:42, Paolo Bonzini wrote:
> virtio-scsi is a simple HBA that talks to the host via a single
> vring. The implementation looks like a hybrid of usb-msc and
> virtio-blk.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Laszlo
On 04/27/12 17:12, Jordan Justen wrote:
> On Fri, Apr 27, 2012 at 07:31, Laszlo Ersek wrote:
>> edk2's "OvmfPkg/AcpiTables/Platform.h" specifies GPE0_BLK at 0x40C,
>> while qemu's "hw/acpi_piix4.c" expects the guest to access it at 0xAFE0.
>>
On 04/27/12 20:09, Gleb Natapov wrote:
> On Fri, Apr 27, 2012 at 07:24:48PM +0200, Laszlo Ersek wrote:
>> >From "5.2.9 Fixed ACPI Description Table (FADT)" in the ACPI spec (v5.0)
>> it would appear OVMF can freely choose where to put GPE0_BLK, in both
>> senses
On 07/27/12 15:42, Laszlo Ersek wrote:
> The series looks to me;
^
good
L.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On 07/25/12 20:45, Eduardo Habkost wrote:
> Extract Local APIC IDs directly from the CPUs, and instead of check for
> "i < CountCPUs", check if the APIC ID was present on boot, when building
> ACPI tables and the MP-Table.
>
> This keeps ACPI Processor ID == APIC ID, but allows the
> hardware<->Se
>
>ACPI: PCI Interrupt Link [LNKS] (IRQs 9) *0
>
> Instead of that, we can simply use a hardwired interrupt index.
>
> Cc: Gleb Natapov
> Cc: Laszlo Ersek
> Signed-off-by: Paolo Bonzini
> ---
> src/acpi-dsdt.dsl | 16
> 1 file modificato, 4 i
(CC'ing Jordan, the TianoCore/OvmfPkg maintainer)
On 10/10/12 09:29, Paolo Bonzini wrote:
> Il 10/10/2012 09:14, Gerd Hoffmann ha scritto:
>> Hi,
>>
>>> Instead of moving just the dsdt to qemu, though, can we move all acpi
>>> tables into qemu? Moving just the dsdt can lead to conflicts with th
There are users who would like to see the UUID at startup, and it probably
won't bother others.
Related RHBZ: 876250.
Signed-off-by: Laszlo Ersek
---
src/util.h |1 +
src/bootsplash.c | 15 ++-
src/output.c | 15 +++
3 files changed, 30 inser
On 12/11/12 11:10, Gerd Hoffmann wrote:
> On 12/11/12 05:54, Kevin O'Connor wrote:
>> On Mon, Dec 10, 2012 at 06:11:08PM +0100, Laszlo Ersek wrote:
>>> There are users who would like to see the UUID at startup, and it probably
>>> won't bother others.
>&g
On 12/11/12 05:54, Kevin O'Connor wrote:
> On Mon, Dec 10, 2012 at 06:11:08PM +0100, Laszlo Ersek wrote:
>> There are users who would like to see the UUID at startup, and it probably
>> won't bother others.
>
> The patch isn't going to work for non-qemu users
On 12/11/12 15:52, Gerd Hoffmann wrote:
>
>>> Also even with qemu the uuid might not be set (just start qemu without
>>> -uuid $something), that case needs to be handled too. Easiest is
>>> probably to just not print it when not preset.
>>
>> How can I distinguish "unset" from "set to all zeros"?
"bootsplash.c" and "smbios.c" are both SRC32FLAT, thus I figure I can
call across. "output.c" is SRC32SEG, but(?) "bootsplash.c" already calls
printf().
v1->v2:
- Retrieve the UUID from SMBIOS table type 1, wherever it has been
installed from.
- Don&#
Signed-off-by: Laszlo Ersek
---
src/util.h |1 +
src/output.c | 16
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/util.h b/src/util.h
index 7723bb1..aafa9b0 100644
--- a/src/util.h
+++ b/src/util.h
@@ -227,6 +227,7 @@ void __set_code_invalid(struct
Signed-off-by: Laszlo Ersek
---
src/smbios.h |1 +
src/smbios.c | 47 +++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/src/smbios.h b/src/smbios.h
index 9d54e80..c1fe7f6 100644
--- a/src/smbios.h
+++ b/src/smbios.h
@@ -165,4
There are users who would like to see the UUID at startup, and it probably
won't bother others.
Related RHBZ: 876250.
Signed-off-by: Laszlo Ersek
---
src/bootsplash.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/src/bootsplash.c
On 12/12/12 01:36, Kevin O'Connor wrote:
> On Tue, Dec 11, 2012 at 05:16:40PM +0100, Laszlo Ersek wrote:
>> There are users who would like to see the UUID at startup, and it probably
>> won't bother others.
>>
>> Related RHBZ: 876250.
>
> Out of curiosi
this link to override the
> +// polarity to active high and match the content of the MADT.
> +Method(_STA, 0, NotSerialized) { Return (0x0b) }
> +Method(_DIS, 0, NotSerialized) { }
> +Method(_CRS, 0, NotS
There are users who would like to see the UUID at startup, and it probably
won't bother others.
Related RHBZ: 876250.
Signed-off-by: Laszlo Ersek
---
v2->v3:
- moved everything to display_uuid() in smbios.c, called from maininit()
v1->v2:
- Retrieve the UUID from SMBIOS table type
On 12/14/12 12:59, Laszlo Ersek wrote:
> There are users who would like to see the UUID at startup, and it probably
> won't bother others.
>
> Related RHBZ: 876250.
>
> Signed-off-by: Laszlo Ersek
> ---
> v2->v3:
> - moved everything to display_uuid() in smb
In the v2->v3 change of what would become commit 37676f83
<http://www.seabios.org/pipermail/seabios/2012-December/005166.html>, the
defense against an initial "addr > end" condition ("wraparound") was
erroneously loosened.
Signed-off-by: Laszlo Ersek
---
s
") was
>> erroneously loosened.
>>
>> Signed-off-by: Laszlo Ersek
>> ---
>> src/smbios.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
> | void
> | display_uuid(void)
> | {
> | u32 addr, end;
> | u8 *uu
On 01/10/13 00:54, Kevin O'Connor wrote:
> On Wed, Jan 09, 2013 at 08:34:18AM -0600, Dave Frodin wrote:
>> Here's a patch that's been lingering awhile.
>> thanks,
>
> Thanks. I don't receive a warning for this - what is the exact
> warning you receive? I don't see why gcc would convert (datalo
On 02/06/13 12:06, David Woodhouse wrote:
> On Tue, 2013-02-05 at 23:14 -0500, Kevin O'Connor wrote:
>> I still need to get an OVMF environment up to test this - I'll do
>> that tomorrow.
(Sorry for not having yet begun the review, working on other stuff...
But certainly don't wait for my review
On 02/08/13 09:00, David Woodhouse wrote:
> On Fri, 2013-02-08 at 04:44 +, Li, Elvin wrote:
>>
>> I guess this virtual disk comes from a virtual disk
>> controller. Now you only fill an entry in BBS table to show legacy
>> boot options, I am unclear that how you enable real legacy boot
On 02/09/13 20:08, Kevin O'Connor wrote:
> This is the redo of the "multi-platform support" patch I sent
> previously.
>
> This patch series is less ambitious than the previous - SeaBIOS can't
> be compiled for multiple platforms (eg, QEMU, CSM, coreboot) at the
> same time. However, this series
On 02/12/13 14:55, Kevin O'Connor wrote:
> On Tue, Feb 12, 2013 at 01:06:34PM +0100, Laszlo Ersek wrote:
>> out/vgaccode16.o: In function `runningOnQEMU':
>> /home/lacos/src/upstream/seabios/out/../src/paravirt.h:17: undefined
>> reference to `PlatformRunning
cpuid==KVM
XEN y (forced)| y cpuid==Xencpuid==KVM
Signed-off-by: Laszlo Ersek
---
src/util.h |7 +++
src/paravirt.c |2 +-
src/util.c |2 +-
src/Kconfig|9 +
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src
n of
"PlatformRunningOn" to SRCBOTH [src/util.c]. Assignment to global
variables is made with SET_FARVAR(), mimicking SET_VGA().
This should allow us to use CONFIG_DEBUG_IO even in vgabios and Legacy16
CSM callbacks.
Signed-off-by: Laszlo Ersek
---
src/paravirt.
Signed-off-by: Laszlo Ersek
---
vgasrc/vgabios.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c
index 3e26e32..0855338 100644
--- a/vgasrc/vgabios.c
+++ b/vgasrc/vgabios.c
@@ -1282,6 +1282,8 @@ void VISIBLE16
vga_post(struct bregs
Signed-off-by: Laszlo Ersek
---
src/csm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/csm.c b/src/csm.c
index 554b304..aac9e78 100644
--- a/src/csm.c
+++ b/src/csm.c
@@ -68,6 +68,9 @@ csm_maininit(struct bregs *regs)
static void
handle_csm_(struct bregs
Signed-off-by: Laszlo Ersek
---
.config| 92
.gitignore |1 -
2 files changed, 92 insertions(+), 1 deletions(-)
create mode 100644 .config
diff --git a/.config b/.config
new file mode 100644
index 000..e58a55e
--- /dev
ably broke everything in the
process. Another approach would be to replace the runtime
runningOnQEMU() check in putc_debug() with the build-time constant
(CONFIG_QEMU || (CONFIG_CSM && CONFIG_QEMU_HARDWARE) || CONFIG_XEN)
condition.
Laszlo Ersek (5):
add .config for CSM testing
move h
On 02/13/13 06:19, Kevin O'Connor wrote:
> On Wed, Feb 13, 2013 at 04:52:09AM +0100, Laszlo Ersek wrote:
>> This series bears witness to my extreme cluelessness. With it I'm only
>> asking if we can move the hypervisor/platform detection logic to SRCBOTH
&g
. It is set to 1 for normal operation of the attribute
controller. [...]"
clext_set_mode()
stdvga_set_mode() -- for regular modes
stdvga_attrindex_write() -- existing call
cirrus_switch_mode() -- for Cirrus modes
stdvga_attrindex_write() -- call added by this patch
Signed-off-by: Lasz
Hi,
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:
In resume (status=0)
In 32bit resume
Attempting a hard re
On 02/14/13 21:54, H. Peter Anvin wrote:
> On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
>>
>> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
>> the exact address of... reset_vector() in SeaBIOS.
>>
>
> This would be a bug, but it isn&
On 02/14/13 21:55, David Woodhouse wrote:
> So, if real hardware would reset the PAMs on reset and avoid the need
> for SeaBIOS to do so, I think we should be doing the same in qemu too.
That's what I couldn't figure out from the i440FX spec, but I believe
one could argue that "reset" should in f
On 02/14/13 22:27, David Woodhouse wrote:
> On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
>> On 02/14/13 21:54, H. Peter Anvin wrote:
>>> On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
>>>>
>>>> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f00
On 02/14/13 21:55, David Woodhouse wrote:
> Thanks for testing this, btw. Are you looking at suspend/resume too? :)
Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
I woke up the guest with
# virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
--hmp --
On 02/15/13 02:22, Kevin O'Connor wrote:
> On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
>> On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote:
>>> On 02/14/13 21:55, David Woodhouse wrote:
>>>
>>>> Thanks for testing
(removing edk2-devel, adding Jan)
On 02/15/13 08:19, Michael Tokarev wrote:
> 15.02.2013 07:43, Kevin O'Connor wrote:
>> On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
>>> On 02/15/13 02:22, Kevin O'Connor wrote:
>>>> On Thu, Feb 14, 2013 a
On 02/14/13 23:24, David Woodhouse wrote:
> On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
>> I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
>> reset requested by the guest doesn't work as expected. The behavior is
>> an infinite loop
On 02/15/13 21:57, David Woodhouse wrote:
> On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote:
>> Same infinite loop, alas...
>>
>> (i) What is your host kernel exactly?
>
> 3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3).
- host CPU: Xeon W3550 (fam
On 02/18/13 13:53, David Woodhouse wrote:
> Nevertheless, on my workstation as on yours, we do seem to end up
> executing from the CSM in RAM when we reset. But on my laptop, it
> executes the *ROM* as it should.
>
> This patch 'fixes' it, and I think it might even be correct in itself,
> but I do
On 02/18/13 18:45, Gleb Natapov wrote:
> On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
>> CS =f000 000f f300
>> ^^^^
>> |base limitflags
>> selector
>>
> This is because real mode is
On 02/18/13 20:00, Kevin O'Connor wrote:
> On Mon, Feb 18, 2013 at 08:31:01PM +0200, Gleb Natapov wrote:
>> Laszlo explained to me that the problem is that after reset we end up
>> in SeaBIOS reset code instead of OVMF one. This is because kvm starts
>> to execute from 0 instead of fff0 aft
On 02/18/13 20:09, Laszlo Ersek wrote:
> On 02/18/13 20:00, Kevin O'Connor wrote:
>> On Mon, Feb 18, 2013 at 08:31:01PM +0200, Gleb Natapov wrote:
>>> Laszlo explained to me that the problem is that after reset we end up
>>> in SeaBIOS reset code instead of OVMF
Hi,
could someone please review this one-liner?
Thanks!
Laszlo
(PS: sorry for top posting)
On 02/14/13 05:43, Laszlo Ersek wrote:
> This patch does the same for Cirrus as David's following patch for bochs,
> originally posted under
> <http://www.seabios.org/pipermail/seab
On 02/18/13 22:25, David Woodhouse wrote:
> On Mon, 2013-02-18 at 21:27 +0100, Laszlo Ersek wrote:
>>
>> could someone please review this one-liner?
>
> Kevin already merged it.
Thanks. Sorry for the noise.
L.
___
SeaBIOS
On 02/19/13 16:29, David Woodhouse wrote:
> On Mon, 2013-02-18 at 17:37 -0500, Kevin O'Connor wrote:
>> The ACPI v2 spec describes a "hard" reset register. SeaBIOS could
>> extract it from the FADT and then use it. Of course, we'd probably
>> want to update the QEMU ACPI tables to implement ACPI
On 02/19/13 19:41, Gleb Natapov wrote:
> On Tue, Feb 19, 2013 at 06:35:03PM +, David Woodhouse wrote:
>> On Tue, 2013-02-19 at 20:13 +0200, Gleb Natapov wrote:
>>>
I take it you mean copy 0xfffe to 0xe? That would not be
>>> fun.
SeaBIOS would need to detect that it's in the
On 02/19/13 23:45, David Woodhouse wrote:
> I'm beginning to wish I'd just ignored the fact that
> we need a properly working "soft" reset to get back from 286 protected
> mode to real mode, and wired up the damn PAM reset unconditionally. I'm
> not convinced that the protected->real mode transiti
Regarding the ACPI tables, OVMF takes them from Xen. It scans 0x000EA020
to 0x000F for the RSDP and goes from there. See
OvmfPkg/AcpiPlatformDxe/Xen.c.
I'm not sure about the e820 table. In hvmloader's build_e820_table()
[tools/firmware/hvmloader/e820.c], a range starting at RESERVED_MEMBASE
i
On 02/20/13 18:18, Ian Campbell wrote:
> On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
>> However in OVMF the RESERVED_MEMBASE range is not parsed from this
>> Xen-exported table, it is added manually in InitializeXen()
>> [OvmfPkg/PlatformPei/Xen.c]:
>>
&
On 02/22/13 15:55, David Woodhouse wrote:
> On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote:
>> Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3
>> Reset Control Register in it.
>
> Hm. I can still trigger the soft reset loop in SeaBIOS, but perhaps no
On 02/22/13 19:13, Laszlo Ersek wrote:
> On 02/22/13 15:55, David Woodhouse wrote:
>> On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote:
>>> Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3
>>> Reset Control Register in it.
>>
>> Hm. I c
On 02/24/13 19:00, Kevin O'Connor wrote:
> On Sat, Feb 23, 2013 at 04:47:26PM +, David Woodhouse wrote:
>> On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote:
>>> IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS)
>>> to QEMU and just have QEMU pass the tables to SeaBIOS
On 02/26/13 10:03, Gerd Hoffmann wrote:
> Can tianocore grab acpi tables from coreboot?
Not that I know of. (... It may have been a rhetorical question.)
When running on Xen, an area is searched for the RSDP, and linked tables
(prepared by Xen's hvmloader I think) are installed by OVMF.
When ru
On 02/27/13 10:19, Gerd Hoffmann wrote:
> On 02/26/13 19:30, Laszlo Ersek wrote:
>> On 02/26/13 10:03, Gerd Hoffmann wrote:
>>
>>> Can tianocore grab acpi tables from coreboot?
>>
>> Not that I know of. (... It may have been a rhetorical question.)
>
&g
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
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 t
erd 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'C
On 03/07/13 09:43, Aurelien Jarno wrote:
> I did a git bisect to find the commit fixing the issue. Then, as I was
> not believing the result, I tried the following sequence a dozen of
> times (for some unknown reasons the FreeBSD install CD doesn't exhibit
> the issue, so I used the Debian GNU/kFr
On 03/08/13 04:35, Kevin O'Connor wrote:
> On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
>> On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
>>> That change is definitely just build related - I don't see how it
>>> could impact the final SeaBIOS binary. How did you
On 03/18/13 09:24, Michael S. Tsirkin wrote:
> On Sun, Mar 17, 2013 at 10:19:45PM -0400, Kevin O'Connor wrote:
>> On Sun, Mar 17, 2013 at 08:27:36PM +0200, Michael S. Tsirkin wrote:
>>> With seabios built from source, and latest qemu, VMs hang during boot
>>> for me. Bisect points at this commit:
comments in-line
On 03/18/13 11:12, Michael S. Tsirkin wrote:
> QEMU now loads its own copy of DSDT, so let's not build in PIIX.
> This leaves building in the DSDT an option, default to off.
> If no one complains for a while, we'll be able to
> remove this altogether.
>
> Signed-off-by: Michael S
9dd3aa 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -202,7 +202,11 @@ struct srat_memory_affinity
> u32reserved3[2];
> } PACKED;
>
> +#ifdef CONFIG_ACPI_DSDT
> #include "acpi-dsdt.hex"
> +#else
> +static u8 AmlCode[1];
> +#endif
On 03/18/13 11
@@ -826,7 +826,8 @@ acpi_setup(void)
> break;
> }
> }
> -if (fadt && !fadt->dsdt) {
> +
> +if (CONFIG_ACPI_DSDT && fadt && !fadt->dsdt) {
> /* default DSDT */
> void *dsdt = malloc_high
Signed-off-by: Laszlo Ersek
---
src/acpi.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 8bbc92b..611553e 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -797,13 +797,13 @@ acpi_setup(void)
struct fadt_descriptor_rev1
These fields are wider than a single byte; stick to cpu_to_leXX() for
consistency with other field settings in this function.
Signed-off-by: Laszlo Ersek
---
src/acpi.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 119d1c1
ads=2
The table dumps / disassemblies are too big to include here, please find
them at <http://people.redhat.com/~lersek/acpi_move/madt_tests.tar.gz>.
Laszlo Ersek (2):
build_madt(): "fix" intsrcovr->{gsi,flags} and local_nmi->flags byte
order
accept MADT
On 03/20/13 16:57, Michael S. Tsirkin wrote:
> You are getting this mail because you might have contributed code to one
> of the files in seabios that we want to reuse in QEMU,
> when this file was under GPLv3 or LGPLv3.
>
> QEMU is GPLv2 at the moment, so as a step in the process of moving acpi
>
On 03/21/13 00:52, Kevin O'Connor wrote:
> On Wed, Mar 20, 2013 at 10:53:04PM +0100, Laszlo Ersek wrote:
>> These fields are wider than a single byte; stick to cpu_to_leXX() for
>> consistency with other field settings in this function.
>
> Thanks. We can do thi
licenses/>.
> +
>
> #include "acpi.h" // struct rsdp_descriptor
> #include "util.h" // memcpy
With reference to
<http://www.seabios.org/pipermail/seabios/2013-March/005960.html>:
Acked-by: Laszlo Ersek
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On 03/21/13 13:03, Michael S. Tsirkin wrote:
> In the interim of moving ACPI tables out of
> seabios, developers should get the config from
> QEMU tree to keep things in sync.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> README | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/REA
he qemu source directory, $SEABIOS_DIR points to the
> +seabios build directory); and then run make in the seabios main directory
> with
> +this configuration:
> +
> + make olddefconfig
> +
> +The resulting file "out/bios.bin" contains the process
On 03/21/13 13:23, David Woodhouse wrote:
> On Wed, 2013-03-20 at 20:22 -0400, Kevin O'Connor wrote:
>> On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
>>>
>>> Signed-off-by: Laszlo Ersek
>>
>> I think we need to figure out what th
On 03/21/13 13:52, David Woodhouse wrote:
> On Thu, 2013-03-21 at 13:49 +0100, Gerd Hoffmann wrote:
> How about we don't bother to determine this at runtime at all?
Because it will be a PITA for testers + developers to figure the correct
.config switches of the day during the tra
This config option, when set to N, allows any qemu-built MADT to take
precedence.
Signed-off-by: Laszlo Ersek
---
in v2:
- replaced primitive dynamic detection code with static config option
- 352 bytes saved in 32bit flat init when set to N (RHEL-6 gcc-4.4.7)
v2 depends on Michael's [PA
On 03/22/13 01:04, Kevin O'Connor wrote:
> On Thu, Mar 21, 2013 at 03:26:26PM +0200, Michael S. Tsirkin wrote:
>> The advantage is that we can make progress
>> without keeping lots of patches out of tree.
>> Unless of course Kevin nacks this all ...
>
> I think we need to have a plan for what the
I'm confused. What are the requirements?
(1) should unpatched qemu work with patched seabios?
(2) should patched qemu work with unpatched seabios?
Considering patched qemu + patched seabios,
(3) should qemu dynamically control table origin/contents per table?
(4) should qemu be able to suppress/d
On 03/24/13 20:14, Michael S. Tsirkin wrote:
> On Sun, Mar 24, 2013 at 01:17:38PM -0400, Kevin O'Connor wrote:
>> What do you think about using approach 2 as I outline at:
>> http://www.seabios.org/pipermail/seabios/2013-March/006020.html ?
>>
>> The existing fw_cfg acpi table passing mechanism is
Again, this enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek
---
hw/acpi.h |2 ++
hw/acpi.c |2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index e3e17e9..2c89e59 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek
---
hw/acpi.h | 11 +++
hw/acpi.c | 48 +---
2 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index e18ef28
Soon we'll declare a function in "hw/pc.h" that takes a
pointer-to-FWCfgState. That would be inconsistent with current usage --
some places use pointer-to-void now even though they mean
pointer-to-FWCfgState. Clean them up.
Signed-off-by: Laszlo Ersek
---
hw/loader.h
2b],
- pc_memory_init() depends on pc_acpi_init() [2a]
This yields the total ordering visible in the patch.
Signed-off-by: Laszlo Ersek
---
hw/pc.h |1 +
hw/i386/pc.c | 142 +
hw/i386/pc_piix.c |2 +
hw/i386/pc_q35.c
isectable.
[1] http://thread.gmane.org/gmane.comp.emulators.qemu/202005/focus=202072
[2] http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5960/focus=6008
Laszlo Ersek (5):
refer to FWCfgState explicitly
hw/acpi: extract standard table headers as a standalone structure
hw/acpi:
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek
---
hw/acpi.h |2 ++
hw/acpi.c | 39 ---
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index d69b6ef..e3e17e9 100644
Signed-off-by: Laszlo Ersek
---
src/acpi.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index bc4d8ea..9e128b2 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -393,6 +393,33 @@ build_madt(void)
return madt
On 04/22/13 17:37, Michael S. Tsirkin wrote:
> On Mon, Apr 22, 2013 at 10:03:01AM +0300, Michael S. Tsirkin wrote:
>> On Sun, Apr 21, 2013 at 08:39:41PM -0400, Kevin O'Connor wrote:
>>> On Sun, Apr 21, 2013 at 11:41:48PM +0300, Michael S. Tsirkin wrote:
Okay I'm pretty close to posting some pa
Not sure how much it counts, but I personally can agree with you on this
direction :)
One note below:
> @@ -603,8 +604,72 @@ acpi_setup(void)
> if (! CONFIG_ACPI)
> return;
>
> +int acpi_generate = 1;
> +
> dprintf(3, "init ACPI tables\n");
>
> +struct romfile_s *fi
On 05/09/13 16:48, Michael Tokarev wrote:
> [Resending after being subscribed to the list]
>
> I'm not sure what happened yet, but I noticed that current seabios
> does not build with 20130214-32 version of iasl.
>
> Apparently, the listing file (-l) produced now does not contain
> any comments f
On 04/05/13 09:17, Hu Tao wrote:
> +Method(RDPT, 0, NotSerialized) {
> +Store(PEPT, Local0)
> +Return (Local0)
> +}
> +
> +Method(WRPT, 1, NotSerialized) {
> +Store(Arg0, PEPT)
> +}
Please excuse my as
On 05/15/13 09:27, Hu Tao wrote:
> On Wed, May 15, 2013 at 09:21:54AM +0200, Laszlo Ersek wrote:
>> On 04/05/13 09:17, Hu Tao wrote:
>>
>>> +Method(RDPT, 0, NotSerialized) {
>>> +Store(PEPT, Local0)
&g
(Not sure why the CC list has grown this huge, but I'm adding Drew for
good mesaure.)
On 05/15/13 09:27, Hu Tao wrote:
> On Wed, May 15, 2013 at 09:21:54AM +0200, Laszlo Ersek wrote:
>> On 04/05/13 09:17, Hu Tao wrote:
>>
>>> +
On 05/15/13 18:25, Paolo Bonzini wrote:
> Il 15/05/2013 18:25, Laszlo Ersek ha scritto:
>> (Not sure why the CC list has grown this huge, but I'm adding Drew for
>> good mesaure.)
>>
>> On 05/15/13 09:27, Hu Tao wrote:
>>> On Wed, May 15, 2013 at 09:21:54AM
On 05/28/13 10:06, Paolo Bonzini wrote:
> Il 28/05/2013 09:40, Amos Kong ha scritto:
>> bootindex parameter of scsi device doesn't work, it causes
>> by wrong pattern in seabios.
>>
>> qemu passes the following firmware dev_path to seabios:
>> /pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,
o_bus_get_dev_path;
> + bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path;
> }
>
> static const TypeInfo virtio_bus_info = {
>
Ah, the happiness of finally understanding what Paolo suggested. (Or at
least believing so.)
My R-b is superfluous after Paolo's, but I can't resist.
Reviewed-by: Laszlo Ersek
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
1 - 100 of 342 matches
Mail list logo
