On Mon, 2013-02-18 at 23:08 +, David Woodhouse wrote:
> Laszlo has hooked up the RCR on the PIIX3 already, so something like
> this ought to make it reset the PAM setup *only* if reset via that...
> +static void i440fx_reset(DeviceState *ds)
> +{
> +PCIDevice *dev = DO_U
On Mon, 2013-02-18 at 10:34 -0500, Kevin O'Connor wrote:
> Some old DOS programs can also use f-segment space as Upper Memory
> Blocks (UMB), so also report on what space is available in debug
> messages.
Should we mark it as available in E820 too?
--
dwmw2
smime.p7s
Description: S/MIME crypto
On Tue, 2013-02-19 at 01:38 -0500, Kevin O'Connor wrote:
> This reduces some duplicate code between malloc_preinit() and
> csm_malloc_preinit().
>
> Signed-off-by: Kevin O'Connor
Nice. I was planning to reduce that duplication, and this seems ideal.
Thanks.
--
dwmw2
smime.p7s
Description: S/
On Mon, 2013-02-18 at 17:37 -0500, Kevin O'Connor wrote:
> On Mon, Feb 18, 2013 at 09:12:46PM +0000, David Woodhouse wrote:
> > The i440fx data sheet (§3.0) appears to say that the default values are
> > loaded on a *hard* reset, not a soft reset. And a reset invoked by the
>
On Mon, 2013-02-18 at 21:27 +0100, Laszlo Ersek wrote:
>
> could someone please review this one-liner?
Kevin already merged it.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.s
On Mon, 2013-02-18 at 14:11 -0500, Kevin O'Connor wrote:
> On Mon, Feb 18, 2013 at 07:04:08PM +0000, David Woodhouse wrote:
> > Well, what SeaBIOS already *does* is bash on the keyboard controller to
> > cause a reset. Which *ought* to work too; I have a patch to at leas
On Mon, 2013-02-18 at 14:00 -0500, 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 inst
On Mon, 2013-02-18 at 19:16 +0100, Laszlo Ersek wrote:
> 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
> >
should be doing for *its* reset function too?
I'll submit this for upstream, but I consider it a workaround for the
real bug that Laszlo has been suffering from. So I'd rather wait until
we've solved that properly, or at least until we understand why we get
such different results on di
On Mon, 2013-02-18 at 10:40 +, David Woodhouse wrote:
> On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote:
> > I give up. Thanks for the help & sorry about spamming three lists.
>
> I've managed to reproduce this on a clean F18 system. This is the stock
> qemu 1
On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote:
> I give up. Thanks for the help & sorry about spamming three lists.
I've managed to reproduce this on a clean F18 system. This is the stock
qemu 1.2.2-6.fc18 on kernel 3.7.6-201.fc18.x86_64 with a newly-installed
Fedora 18 VM in the guest.
q
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).
> (ii) And when you say you did a "legacy boot", does that mean you installed
> the guest OS as a traditiona
On Thu, 2013-02-14 at 16:46 +, Ian Campbell wrote:
> Right, we really need to find someone with hours to finish properly
> integrating OVMF.
Hm, that 'someone' may end up being me¹.
So... from the Xen point of view, what needs doing? There are some
things on my TODO list which apply to Qemu/K
On Fri, 2013-02-15 at 11:19 +0400, Michael Tokarev wrote:
> This patch is more than 2 years old and is applied to all more or
> less recent qemu versions.
RHEL 6.3?
I'm *not* seeing this bug with recent qemu versions.
> This does not tell us why disabling kvm (with this patch applied!)
> makes
On Fri, 2013-02-15 at 00:01 +0100, Laszlo Ersek wrote:
>
> 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 --cmd system_wakeup
>
> Trailing portion of the l
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 repeated by the
> CSM-ized SeaBIOS:
>
>
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() in SeaBIOS.
> >>
> >
> > T
On Thu, 2013-02-14 at 12:54 -0800, H. Peter Anvin wrote:
> This would be a bug, but it isn't quite true.
>
> If you look at x86_cpu_reset() you will note that it sets the code
> segment base to 0x, not 0xf as one could expect from the
> above. This is also true of a physical x86.
>
>
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
> Can we dumb down ^W^W generalize this code? :) Or maybe should qemu
> introduce a reset handler for PAMs?
In the UEFI+CSM model, I believe the handling of PAM stuff is left
*entirely* to the UEFI side and the CSM is supposed to be
hardware-a
On Thu, 2013-02-14 at 18:10 +, Ian Campbell wrote:
>
> I tested:
> HEAD is now at e62d172 Make Xen one of the top-level build target choices
> with the attached config and I'm afraid it booted from the cdrom no
> matter what I did in my config file.
The patch I sent earlier seems to have fixe
On Thu, 2013-02-14 at 18:10 +, Ian Campbell wrote:
> I tested:
> HEAD is now at e62d172 Make Xen one of the top-level build target choices
> with the attached config and I'm afraid it booted from the cdrom no
> matter what I did in my config file.
>
> I enabled CONFIG_QEMU_HARDWARE (seabios2.c
On Thu, 2013-02-14 at 16:46 +, Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
> > git.infradead.org/users/dwmw2/seabios.git
> >
> > There's a README.CSM file in the SeaBIOS tree which describes how to
> > build OVMF with C
On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
> On Thu, 2013-02-14 at 13:05 +0000, David Woodhouse wrote:
> >
> > Anyway, I appear to have established that the qemu fw_cfg *doesn't*
> > exist in your domains — so how you pass bootorder to the guest, if
> you
d need to fix the VGA ROM you're shipping for Cirrus, which has the
> > PCIR structure unaligned. That was it.
> ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> include? (rather than tools/firmware/vgabios/)
Yes, the one in /usr/share/qemu-xen. You want the patch
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
>
> I'll probably have a look at OVMF under Xen now, and making sure that my
> CSM code works there. Then you shouldn't need to offer people the choice
> between OVMF and SeaBIOS because you'll have one imag
On Thu, 2013-02-14 at 12:53 +, Ian Campbell wrote:
>
> I had observed once upon a time that turning up the limit caused odd
> failures, but I'd never associated it with the size. I spent ages
> trying
> to track down a NULL pointer in some level>3 message and the like...
>
> In hvmloader I se
On Thu, 2013-02-14 at 11:27 +, Ian Campbell wrote:
> I've attached an hvmloader which I just built from the 4.2 stable branch
> and have smoke tested, does it work for you?
FFS. Is it too early to start drinking yet? A 256KiB ROM image fails as
I have described, while a 128KiB image works fine
On Wed, 2013-02-13 at 20:02 -0500, Kevin O'Connor wrote:
> On Wed, Feb 13, 2013 at 09:50:13AM +0000, David Woodhouse wrote:
> > - 4940c334 Clean up Kconfig options for CSM
> >
> > Merging this would be good.
>
> The "BIOS interfaces" menu allows develope
On Wed, 2013-02-13 at 12:50 +0100, Fred . wrote:
> Would it be possible to boot in a resolution any more modern than the
> old IBM PC BIOS of 1980?
> Which probably used same resolution as something from 1960 or 1970.
> Maybe 132*60 instead of 40*25 or 80*25 rows/columns of text?
Please don't top
On Wed, 2013-02-13 at 12:56 +, Ian Campbell wrote:
>
> I think it should JustWork. I expect they disabled it either because
> they intended to eventually use /usr/bin/qemu-foo instead or maybe just
> as an expedient way of getting the 4.2 package together and because it
> is a non-default opti
On Wed, 2013-02-13 at 12:38 +, M A Young wrote:
>
> xen-4.2.0 added a second qemu-xen image - the patch takes it out again. As
> the traditional qemu-xen was still the default so it didn't seem worth
> adding another, particularly as I would ideally like to drop xen's qemu
> altogether and
On Wed, 2013-02-13 at 12:05 +, Ian Campbell wrote:
>
> Hrm, this should either be provided by the Xen package (or maybe there
> is a separate xen-qemu package?) or the Xen package should have been
> patched to use the system qemu from /usr/bin. This is probably a
> casualty of the upstream qem
On Wed, 2013-02-13 at 11:40 +, Ian Campbell wrote:
> On Wed, 2013-02-13 at 11:37 +0000, David Woodhouse wrote:
> > device_model_version_override = "qemu-xen"
>
> No "_override" on this option, sorry, that was my fault.
[root@i7 ~]# ls /usr/lib/xen/bin/
On Wed, 2013-02-13 at 11:31 +, David Woodhouse wrote:
> On Wed, 2013-02-13 at 11:30 +, Ian Campbell wrote:
> >
> > Is there anything of interest in /var/log/xen/*seabios* or "xl dmesg"?
> > Could you post the output of "xl -vvv create -c seabios.cfg&qu
On Wed, 2013-02-13 at 11:30 +, Ian Campbell wrote:
>
> Is there anything of interest in /var/log/xen/*seabios* or "xl dmesg"?
> Could you post the output of "xl -vvv create -c seabios.cfg" please.
>
> Dario, have you ever run a domain with qemu-xen on a Fedora 18 box, it
> ought to work, righ
On Tue, 2013-02-12 at 10:34 +, Ian Campbell wrote:
>
>
> Lastly to change the seabios bits, just change to
> tools/firmware/seabios-dir (assuming Fedora's packaging hasn't moved
> it)
> and git fetch/git reset/vim/emacs, the build system won't clobber this
> unless you ask it to. Then to rebu
On Tue, 2013-02-12 at 21:27 -0500, Kevin O'Connor wrote:
>
> I'm fine with that change, but I'm not sure how to communicate that to
> the distro maintainers. I wouldn't want them to try and build the
> next version of xen and find it mysterously failing.
I'm not so worried about that. Xen ships
I'm running Fedora 18 with Xen 4.2.1 but using the Fedora 17 3.7.3
kernel because the F18 3.7.6 kernel doesn't find its root filesystem
when booted under Xen. The Fedora KISS violation of using LVM by default
bites again... but that shouldn't make any difference, right? Xen and
all the userspace to
On Wed, 2013-02-13 at 10:44 +0100, Fred . wrote:
> Can SeaBIOS init to a high resolution video mode such as 1920x1200?
I'm not entirely sure what you're asking. Can SeaVGABIOS initialise a
high-resolution mode? Yes. It supports 1920x1200 and 2560x1600 modes.
All you have to do is call INT 10h with
On Mon, 2013-02-11 at 19:41 -0500, Kevin O'Connor wrote:
> On Mon, Feb 11, 2013 at 05:28:11PM +0000, David Woodhouse wrote:
> > > Does QEMU_HARDWARE mean hardware "defined" (so to speak) by QEMU (e.g.
> > > virtio type stuff) or does it include regular hardwa
On Mon, 2013-02-11 at 12:43 +, Ian Campbell wrote:
> I don't know if distros prefer to have fewer images or not, once you
> have 2 I guess having N is not such a big deal for something the size
> and build time of SeaBIOS.
Probably not. It's not as if supporting Xen is an otherwise trivial
exe
f in the config.
commit eff724e682ce557cd9d4a09d7892cb28950bb886
Author: David Woodhouse
Date: Mon Feb 11 10:47:47 2013 +
Make Xen one of the top-level build target choices
Signed-off-by: David Woodhouse
diff --git a/src/Kconfig b/src/Kconfig
index 6dbea79..f5dab76 100644
---
On Mon, 2013-02-11 at 12:26 +0100, Gerd Hoffmann wrote:
> On 02/11/13 12:18, Gerd Hoffmann wrote:
> > Then add a CONFIG_QEMU_DRIVERS menu where we put all virtual
> hardware
> > drivers in. So when building for real hardware you'll just say 'n'
> > there and all virtual drivers will be skipped.
>
On Fri, 2013-02-08 at 18:37 -0500, Kevin O'Connor wrote:
> On Fri, Feb 08, 2013 at 11:25:39PM +0000, David Woodhouse wrote:
> > On Fri, 2013-02-08 at 18:02 -0500, Kevin O'Connor wrote:
> > >
> > > >I'm not sure it would even work for CSM,
On Fri, 2013-02-08 at 18:02 -0500, Kevin O'Connor wrote:
>
> >I'm not sure it would even work for CSM, because it would
> > probably be too big.
>
> As an aside, is there a way to pass in the "init" sections to ovmf
> such that they don't prevent option roms from using the space? Also,
> I brief
On Fri, 2013-02-08 at 18:02 -0500, Kevin O'Connor wrote:
>
> Yes - that's why it doesn't make sense to change the Kconfig settings
> of the various qemu drivers from "depends on QEMU" to "depends on
> !COREBOOT" - the CSM is in the same situation as Coreboot. It's fine
> to access the hardware wh
On Fri, 2013-02-08 at 16:11 +, Ian Campbell wrote:
> (XEN) HVM167: xen: copy BIOS tables...
> (XEN) HVM167: Copying SMBIOS entry point from 0x00010010 to 0x000fdb10
> (XEN) HVM167: Copying MPTABLE from 0xfc001170/fc001180 to 0x000fda10
> (XEN) HVM167: Copying PIR from 0x00010030 to 0x000fd990
>
On Fri, 2013-02-08 at 15:33 +, David Woodhouse wrote:
> On Fri, 2013-02-08 at 15:27 +, Ian Campbell wrote:
> > On Fri, 2013-02-08 at 14:50 +, Ian Campbell wrote:
> > > even with that and
> > > CONFIG_DEBUG_LEVEL=2 I still don't see the expect
On Fri, 2013-02-08 at 15:27 +, Ian Campbell wrote:
> On Fri, 2013-02-08 at 14:50 +, Ian Campbell wrote:
> > even with that and
> > CONFIG_DEBUG_LEVEL=2 I still don't see the expected "Using pmtimer"
> > message.
>
> pci_setup() doesn't run on coreboot or Xen (because they do PCI setup
> t
On Fri, 2013-02-08 at 15:06 +, David Woodhouse wrote:
> When booting with OVMF+CSM, the first video mode that we ask for is mode
> 0x143. This doesn't seem to work; the qemu display window doesn't change
> size, and remains blank.
>
> If the first thing we ask f
t to go chasing it. Most video
BIOSes will enter mode 3 for themselves as part of the POST anyway,
won't they? And that's sufficient to work around the problem for me...
Signed-off-by: David Woodhouse
diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c
index 3e26e32..82aa5fc 100644
---
On Fri, 2013-02-08 at 11:27 +0100, Gerd Hoffmann wrote:
>
> > unaligned PCIR - I'm not sure we can merge this as it would break QEMU
> > users with a current "lgpl vgabios".
>
> As long as this is a config switch so we can easily turn this on for the
> builds shipped with qemu everything is fine.
On Fri, 2013-02-08 at 09:51 +, Ian Campbell wrote:
> I've not been following this thread all that closely, what
> specifically should I be testing on Xen? Just starting a guest which
> uses pmtimer under latest SeaBIOS git and checking it works OK?
It's not merged yet; it's at http:// and
git:
On Fri, 2013-02-08 at 00:06 -0500, Kevin O'Connor wrote:
> This patch series enables SeaBIOS to be compiled for multiple
> platforms (eg, CSM, QEMU, Coreboot) at the same time. This is useful
> for cases where SeaBIOS is running under coreboot which is running
> under QEMU, for example.
I think y
se either, if you can
be booted from coreboot under qemu.
See the final two patches in my git tree... I wouldn't mind getting
these merged so that they're part of the *base* for your subsequent
Kconfig changes.
commit 1c78b74a62a178050c1e9763b0943725a32ec060
Author: David Woodhouse
Dat
On Thu, 2013-02-07 at 20:48 -0500, Kevin O'Connor wrote:
> Kconfig - I'm not sure we should have a qemu vs coreboot vs csm
> selection as it's possible we can have qemu+csm (or even
> qemu+coreboot+csm) and I think Kconfig should reflect that reality.
> I'll put together a patch to demonstrate what
On Thu, 2013-02-07 at 08:40 +, David Woodhouse wrote:
> On Wed, 2013-02-06 at 23:13 -0500, Kevin O'Connor wrote:
> >
> > Restoring flags on exit is assuredly more correct, and if I move
> > timer_setup() to the prepare-to-boot phase this problem goes away for
> &g
On Wed, 2013-02-06 at 23:13 -0500, Kevin O'Connor wrote:
>
> Restoring flags on exit is assuredly more correct, and if I move
> timer_setup() to the prepare-to-boot phase this problem goes away for
> me. So, I think this is more evidence that the timer can not be
> enabled in the init-yourself ph
rangeness here.
I disabled CONFIG_RELOCATE_INIT, and I made the Lock call in OVMF's
LegacyRegion code a no-op so it's never actually locking it; just to
eliminate certain classes of problem.
I also fixed your code as follows:
commit debcd72c34a6b8eba91c9157b15422d418fe8868
Author: Davi
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.
Should go something like this...
git clone git://git.infradead.org/users/dwmw2/edk2.git
cd edk2
make -C BaseTools
. edksetup.sh
ln -sf /where/your/seabio
From: David Woodhouse
GCC, for reasons unknown, will refuse to compile code such as
extern int bar;
uint16_t foo = &bar;
The assembler would happily emit a R_386_16 relocation for this if asked
nicely, and all would be well. But instead, GCC complains about the
initialiser not b
From: David Woodhouse
This is under a BSD licence so it's fine to import directly.
Signed-off-by: David Woodhouse
---
src/LegacyBios.h | 965 +++
1 file changed, 965 insertions(+)
create mode 100644 src/LegacyBios.h
diff --git
From: David Woodhouse
Signed-off-by: David Woodhouse
---
src/Kconfig| 1 -
src/coreboot.c | 4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index 0b112ed..43046c5 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -239,7 +239,6 @@ menu "Har
From: David Woodhouse
I'm about to introduce some post-processing in checkrom.py which will want
access to public symbols. So let's make sure they're defined in the final
link even if they're *not* cross-referenced from a different code section.
Signed-off-by: David W
From: David Woodhouse
This removes 25KiB of unused cruft from the image, crucially making the
difference between a 128KiB image (which works with OVMF) and a 256KiB
image (which doesn't).
Signed-off-by: David Woodhouse
---
src/post.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: David Woodhouse
Signed-off-by: David Woodhouse
---
src/xen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/xen.c b/src/xen.c
index c9759f0..2e6849c 100644
--- a/src/xen.c
+++ b/src/xen.c
@@ -10,6 +10,7 @@
#include "memmap.h" // add_e820
#include "types.
From: David Woodhouse
Signed-off-by: David Woodhouse
---
src/post.c | 10 +-
src/post.h | 10 ++
2 files changed, 15 insertions(+), 5 deletions(-)
create mode 100644 src/post.h
diff --git a/src/post.c b/src/post.c
index dbf4944..ec014c0 100644
--- a/src/post.c
+++ b/src
instead of wholesale copy.
- Add pic_save_mask() and pic_restore_mask() functions.
- Less intrusive size reduction for handle_post().
- Various other cleanups.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel
From: Kevin O'Connor
Place the "interface initialization" functions together, "platform
hardware initialization" functions together, and "prepare to boot"
functions together. This may also be useful for using SeaBIOS as a
CSM.
This slightly changes the order of some function invocations, but
sh
From: Kevin O'Connor
Call maininit() and startBoot() from handle_post(). This reduces the
chaining of calls during the relocation phase, and allows maininit()
to return (which may be useful when using SeaBIOS as a CSM).
This change relies on reloc_init() modifying the maininit() call in
handle_
From: David Woodhouse
Signed-off-by: David Woodhouse
---
src/optionroms.c | 2 +-
src/optionroms.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index c79a706..c9e7d7b 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -44,7
From: David Woodhouse
cf. http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
Signed-off-by: David Woodhouse
---
src/Kconfig | 7 +++
src/optionroms.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig
index 43046c5..b9206e5 100644
--- a
From: David Woodhouse
With CSM (and maybe coreboot) we'll want to find the pmtimer from the ACPI
tables, instead of knowing where it is and *putting* it into the ACPI
tables.
Extract the first part of the existing find_resume_vector() function into
a find_fadt() function, and use it from
From: David Woodhouse
CONFIG_PIRTABLE, along with various other BIOS tables, is only selectable
if CONFIG_QEMU is selected. QEMU/COREBOOT/CSM is a choice, so you can't
enable CONFIG_PIRTABLE if you've selected COREBOOT or CSM. So kill the
excessive #if check for COREBOOT.
Signed-off
From: David Woodhouse
Yes, copy_table() would invoke it, but CSM will *only* use it for SMBIOS
tables and however much we trick the compiler by gratuitously checking
the table signature right before calling copy_table(), it still doesn't
seem to notice that fact. And emits code for all the
From: David Woodhouse
I want to do this too, and can't bring myself to introduce yet another copy.
Signed-off-by: David Woodhouse
Acked-by: Marc Jones
---
src/entryfuncs.S | 74 ++--
1 file changed, 29 insertions(+), 45 deletions(-)
From: David Woodhouse
Signed-off-by: David Woodhouse
---
Makefile| 2 +-
README.CSM | 21
src/Kconfig | 19 ++--
src/boot.c | 7 ++
src/csm.c | 289
src/csm.h | 18
src/pmm.c | 19
From: David Woodhouse
We need this proposed addition to the CSM spec, or OVMF will make the whole
region from 0xC to 0xF read-only before invoking our Legacy16Boot
method. Read-only stack considered harmful.
http://www.sourceforge.net/mailarchive/forum.php?thread_name=50FD7290.9060003
From: David Woodhouse
CSM will (unfortunately) need to use these.
Signed-off-by: David Woodhouse
---
src/pic.c | 16
src/pic.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/src/pic.c b/src/pic.c
index 8992a8b..669d670 100644
--- a/src/pic.c
+++ b/src/pic.c
@@ -50,3
On Sat, 2013-02-02 at 20:21 -0500, Kevin O'Connor wrote:
>
> Ideally this would be added to the existing README instead of adding a
> new file.
I couldn't see a clean way to merge the files together. Other than that,
various fixes are now in my git tree at
http://git.infradead.org/users/dwmw2/sea
On Sat, 2013-02-02 at 19:32 -0500, Kevin O'Connor wrote:
> I'm not sure how to best address this. One way is to go forward and
> sprinkle VISIBLE32INIT. Another way would be to revert patch 1, pass
> a function pointer to reloc_preinit() instead of hard-coding maininit,
> and teach the CSM code h
On Sat, 2013-02-02 at 20:21 -0500, Kevin O'Connor wrote:
> On Mon, Jan 28, 2013 at 04:23:45PM +0000, David Woodhouse wrote:
> > +++ b/README.CSM
> Ideally this would be added to the existing README instead of adding a
> new file.
OK, will fix.
> > +// csm.c
> &
On Wed, 2013-01-30 at 22:13 -0500, Kevin OConnor wrote:
> This bothers me a little as well. Would it be possible to
> separate out the UMBStart/End stuff into a separate patch. (The
> main patch would assume OVMF doesn't lock 0xc-0xf at all,
> and the UMBStart/End patch would assume that
On Wed, 2013-01-30 at 09:58 -0700, Marc Jones wrote:
>
> > Not-yet-signed-off-by: David Woodhouse
> would-be-acked-by: Marc Jones
Thanks. I've updated the git tree at git://,
http://git.infradead.org/users/dwmw2/seabios.git accordingly.
The 'not yet' bit has been re
On Mon, 2013-01-28 at 16:23 +, David Woodhouse wrote:
> I haven't quite finished going through the corporate bureaucracy for
> releasing this, so it's for review only.
Now done.
s/Not-yet-signed-off-by/Signed-off-by/
--
dwmw2
smime.p7s
Description: S/MIME cryptog
cf. http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
Signed-off-by: David Woodhouse
diff --git a/src/Kconfig b/src/Kconfig
index f35b0f5..e49dd82 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -293,6 +293,13 @@ menu "BIOS interfaces"
default y
From: David Woodhouse
GCC, for reasons unknown, will refuse to compile code such as
extern int bar;
uint16_t foo = &bar;
The assembler would happily emit a R_386_16 relocation for this if asked
nicely, and all would be well. But instead, GCC complains about the
initialiser not b
From: David Woodhouse
I'm about to introduce some post-processing in checkrom.py which will want
access to public symbols. So let's make sure they're defined in the final
link even if they're *not* cross-referenced from a different code section.
Not-yet-signed-off
From: David Woodhouse
We need this proposed addition to the CSM spec, or OVMF will make the whole
region from 0xC to 0xF read-only before invoking our Legacy16Boot
method. Read-only stack considered harmful.
http://www.sourceforge.net/mailarchive/forum.php?thread_name=50FD7290.9060003
From: David Woodhouse
This is under a BSD licence so it's fine to import directly.
Not-yet-signed-off-by: David Woodhouse
---
src/LegacyBios.h | 965 +++
1 file changed, 965 insertions(+)
create mode 100644 src/LegacyBios.h
diff --
From: David Woodhouse
This removes 25KiB of unused cruft from the image, crucially making the
difference between a 128KiB image (which works with OVMF) and a 256KiB
image (which doesn't).
Not-yet-signed-off-by: David Woodhouse
---
src/pirtable.c | 2 +-
src/romlayout.S
From: David Woodhouse
Not-yet-signed-off-by: David Woodhouse
---
Makefile| 2 +-
README.CSM | 20
src/Kconfig | 7 ++
src/boot.c | 6 ++
src/boot.h | 5 +
src/csm.c | 313
src/csm.h
From: David Woodhouse
I want to do this too, and can't bring myself to introduce yet another copy.
Not-yet-signed-off-by: David Woodhouse
---
src/entryfuncs.S | 74 ++--
1 file changed, 29 insertions(+), 45 deletions(-)
diff --git
From: David Woodhouse
Yes, copy_table() would invoke it, but CSM will *only* use it for SMBIOS
tables and however much we trick the compiler by gratuitously checking
the table signature right before calling copy_table(), it still doesn't
seem to notice that fact. And emits code for all the
From: David Woodhouse
Not-yet-signed-off-by: David Woodhouse
---
src/optionroms.c | 2 +-
src/optionroms.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index c79a706..c9e7d7b 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
From: David Woodhouse
Not-yet-signed-off-by: David Woodhouse
---
src/post.c | 10 +-
src/post.h | 11 +++
2 files changed, 16 insertions(+), 5 deletions(-)
create mode 100644 src/post.h
diff --git a/src/post.c b/src/post.c
index dbf4944..b53f1eb 100644
--- a/src/post.c
+++ b
From: Kevin O'Connor
Place the "interface initialization" functions together, "platform
hardware initialization" functions together, and "prepare to boot"
functions together. This may also be useful for using SeaBIOS as a
CSM.
This slightly changes the order of some function invocations, but
sh
From: Kevin O'Connor
Call maininit() and startBoot() from handle_post(). This reduces the
chaining of calls during the relocation phase, and allows maininit()
to return (which may be useful when using SeaBIOS as a CSM).
This change relies on reloc_init() modifying the maininit() call in
handle_
for
releasing this, so it's for review only.
Git tree at git://git.infradead.org/users/dwmw2/seabios.git or gitweb at
http://git.infradead.org/users/dwmw2/seabios.git
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
Just a brief update for those who are interested... the CSM is fairly
functional now. I've tested with:
Various Linuxes including CentOS [56], Fedora 17.
Windows 7
Windows 2008r2 (via EFI)
OpenBSD 5.2
FreeBSD 9
FreeBSD 8
Debian/kFreeBSD (also FBSD 8 kernel I think)
DragonflyBSD
NetBSD
So
101 - 200 of 207 matches
Mail list logo
