On 06/14/13 01:02, Paolo Bonzini wrote:
Il 10/06/2013 21:03, Anthony Liguori ha scritto:
I'm not really convinced that
QEMU-firmware is a GPL boundary because of how tightly the two are
linked.
Where has 'linked' in terms of the GPL ever been anything other than
actual executable linking?
On 06/11/13 17:45, Michael S. Tsirkin wrote:
To summarize, there's a concensus now that generating ACPI
tables in QEMU is a good idea.
Two issues that need to be addressed:
- original patches break cross-version migration. Need to fix that.
- Anthony requested that patchset is merged
On 06/03/13 08:06, Gerd Hoffmann wrote:
---
src/coreboot.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/coreboot.c b/src/coreboot.c
index 120bc2e..2c8bd2d 100644
--- a/src/coreboot.c
+++ b/src/coreboot.c
@@ -14,6 +14,7 @@
#include config.h // CONFIG_*
#include
On 06/01/13 05:35, Kevin O'Connor wrote:
The plan on uefi was to use the smbios
tables to detect qemu. Once detection is in place, the DEBUG_IO
support could be made dependent on QEMU_HARDWARE and only activated
after detection succeeds.
Understood.
I wasn't aware this was pending on me
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
Either qemu does it, or seabios... (And, OVMF too, but I don't think
you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an
On 05/31/13 10:13, Peter Stuge wrote:
ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg
On 05/31/13 03:09, Kevin O'Connor wrote:
On Thu, May 30, 2013 at 09:30:33AM +0200, Gerd Hoffmann wrote:
On 05/30/13 03:34, Kevin O'Connor wrote:
On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote:
Allow selecting DEBUG_IO for non-qemu configurations,
which is useful when running
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
:)
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable
On 05/31/13 16:08, David Woodhouse wrote:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a
On 05/31/13 16:38, Anthony Liguori wrote:
It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
suggesting (from the soapbox :))?
I have a hard
On 05/31/13 17:43, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork.
On 05/31/13 18:33, David Woodhouse wrote:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a sense
On 05/30/13 11:23, David Woodhouse wrote:
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
Certainly an option, but that is a long-term project.
Out of curiousity, are there other benefits to using coreboot as a core
firmware in QEMU?
Is there a payload we would ever plausibly use
On 05/30/13 14:19, David Woodhouse wrote:
Yeah, but if we're shoving a lot of hardware-specific ACPI table
generation into the guest's firmware, instead of just doing it on the
qemu side where a number of us seem to think it belongs, then there *is*
a benefit to using Coreboot. When stuff
On 05/30/13 18:20, Jordan Justen wrote:
I think ACPI table generation lives in firmware on real products,
because on real products the firmware is the point that best
understands the actual hardware layout for the machine. In qemu, I
would say that qemu best knows the hardware layout, given
On 05/30/13 18:57, Jordan Justen wrote:
On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote:
On 05/30/13 18:20, Jordan Justen wrote:
I think ACPI table generation lives in firmware on real products,
because on real products the firmware is the point that best
understands
= 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 ler...@redhat.com
as flexible
as possible -- if I understand the current Kconfig right, the CONFIG_CSM
build target still conflicts with CONFIG_DEBUG_IO, and this patch would
fix that for me. Kevin will decide of course, but personally:
Reviewed-by: Laszlo Ersek ler...@redhat.com
Thanks,
Laszlo
QEMU_HARDWARE, so OK in that direction.
CSM and COREBOOT (!QEMU in general) make the QEMU_HARDWARE option
available, which when set to y opens up DEBUG_IO.
Reviewed-by: Laszlo Ersek ler...@redhat.com
Thanks
Laszlo
___
SeaBIOS mailing list
SeaBIOS
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,0
No,
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)
+Return (Local0)
+}
+
+Method(WRPT, 1
(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:
+Method(RDPT, 0, NotSerialized) {
+Store(PEPT
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 from
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 *file = NULL;
Again, this enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/acpi.h | 11 +++
hw/acpi.c | 48 +---
2 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/hw/acpi.h b/hw
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 ler...@redhat.com
---
hw/loader.h
() [2a]
This yields the total ordering visible in the patch.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/pc.h |1 +
hw/i386/pc.c | 142 +
hw/i386/pc_piix.c |2 +
hw/i386/pc_q35.c | 10 +++-
4 files changed
://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: export default ACPI headers
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
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 pretty
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 final
with
+this configuration:
+
+ make olddefconfig
+
+The resulting file out/bios.bin contains the processed bios image.
Testing of images:
Reviewed-by: Laszlo Ersek ler...@redhat.com
(I'll unavoidably test this anyway.)
Thanks for the heads-up again!
Laszlo
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 ler...@redhat.com
I think we need to figure out what the final fw_cfg interface for
ACPI, SMBIOS
This config option, when set to N, allows any qemu-built MADT to take
precedence.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
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 ler...@redhat.com
---
src/acpi.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
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 over fw_cfg
src/acpi.c | 31
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 this to improve documentation. Please ack
-March/005960.html:
Acked-by: Laszlo Ersek ler...@redhat.com
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
));
if (!dsdt) {
Ah I see. We build the hex file include it too, but gcc will optimize
it out.
Reviewed-by: Laszlo Ersek ler...@redhat.com
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
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.
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:41, Laszlo Ersek wrote:
The macro CONFIG_ACPI_DSDT is always defined (you use it just below
in a controlling expression); its value is what
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/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
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
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
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
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.)
Wasn't rhetorical. Generating the apci tables in both
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
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 for it
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 not
in a circumstance that we
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
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]:
//
// Reserve away HVMLOADER reserved
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 v2 then.
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 after
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 one. This is because kvm starts
to execute
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/seabios/2013-February/005434
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 mailing list
SeaBIOS@seabios.org
(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 at 08:16:02PM -0500, Kevin O'Connor wrote:
By chance
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, with the following debug fragment
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
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't quite true.
If you look at x86_cpu_reset
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 fact
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 f000:fff0, which is
the exact address of... reset_vector
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/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
code, so that it sets up PlatformRunningOn
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 still
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 `PlatformRunningOn'
Oops. This is because
cpuid==KVM
XEN y (forced)| y cpuid==Xencpuid==KVM
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
src/util.h |7 +++
src/paravirt.c |2 +-
src/util.c |2 +-
src/Kconfig|9 +
4 files changed, 10 insertions(+), 10 deletions(-)
diff
]. 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 ler...@redhat.com
---
src/paravirt.h | 22 --
src/util.h | 30
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
that I wanted, but I probably 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
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 for
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; I
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 (datalow_end -
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 ler...@redhat.com
---
src/smbios.c |4 ++--
1
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 ler...@redhat.com
---
v2-v3:
- moved everything to display_uuid() in smbios.c, called from maininit()
v1-v2:
- Retrieve the UUID from SMBIOS table
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 ler...@redhat.com
---
v2-v3:
- moved everything to display_uuid() in smbios.c, called from maininit
(_CRS, 0, NotSerialized) { Return (_PRS) }
+Method(_SRS, 1, NotSerialized) { }
+}
}
#include acpi-dsdt-cpu-hotplug.dsl
Reviewed-by: Laszlo Ersek ler...@redhat.com
although I'm not sure FreeBSD does the right thing
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 curiosity, why do they want to see the UUID?
I've received
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.
The patch isn't going to work for non-qemu users (eg
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 (eg, coreboot).
At least on qemu, I figured
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?
set to all
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't print an all-zeros (= unset) UUID.
Laszlo Ersek (3
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
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
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 ler...@redhat.com
---
src/bootsplash.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/src/bootsplash.c
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 ler...@redhat.com
---
src/util.h |1 +
src/bootsplash.c | 15 ++-
src/output.c | 15 +++
3 files changed
Interrupt Link [LNKS] (IRQs 9) *0
Instead of that, we can simply use a hardwired interrupt index.
Cc: Gleb Natapov gnata...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/acpi-dsdt.dsl | 16
1 file modificato, 4
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 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 (ie. port address considered alone, and also
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
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 pbonz...@redhat.com
Reviewed-by: Laszlo Ersek ler...@redhat.com
Laszlo
201 - 298 of 298 matches
Mail list logo
