On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
> > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> >> Should a kernel fail during boot, I'd suspect it doesn't like one of
> >> the apm/pcibios callbacks, or it doesn't like one of the
> >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code
> >> (see http://seabios.org/Download ) and increasing the debugging by
> >> modifying src/config.h. Specifically, you could increase
> >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to
> >> 1. Also, you could try disabling some of the features to see if that
> >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS /
> >> CONFIG_MPTABLE).
> >
>
> I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the
> image boots up fine.
Gleb, have you seen this thread?
Some of the recent changes to smbios that look like possible culprits
are:
Make SMBIOS table pass MS SVVP test
Use MaxCountCPUs during building of per cpu tables.
Add malloc_high/fseg() and rework bios table creation to use them.
There were other changes, but the comments indicate they were only
ports of changes already in bochs. I suppose it's also possible the
lack of smbios is turning off some other feature in the guest (eg,
acpi) that's the real culprit.
-Kevin
Without this BIOS fails to remap 0xf0000 memory from ROM to RAM so writes
to F-segment modify ROM content instead of memory copy. Since QEMU does
not reloads ROMs during reset on next boot modified copy of BIOS is used.
Signed-off-by: Gleb Natapov <gleb(a)redhat.com>
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 933ad86..0bf435d 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -99,10 +99,6 @@ static void i440fx_update_memory_mappings(PCII440FXState *d)
int i, r;
uint32_t smram, addr;
- if (kvm_enabled()) {
- /* FIXME: Support remappings and protection changes. */
- return;
- }
update_pam(d, 0xf0000, 0x100000, (d->dev.config[I440FX_PAM] >> 4) & 3);
for(i = 0; i < 12; i++) {
r = (d->dev.config[(i >> 1) + (I440FX_PAM + 1)] >> ((i & 1) * 4)) & 3;
--
Gleb.
The following set of patches add TPM and Trusted Computing support to SeaBIOS.
In particular the patches add:
- a TPM driver for the Qemu's TPM TIS emulation (not yet in Qemu git)
- ACPI support for the TPM device (SSDT table)
- ACPI support for measurement logging (TCPA table)
- Support for initialzation of the TPM
- Support for the TCG BIOS extensions (1ah handler [ah = 0xbb])
(used by trusted grub; http://trousers.sourceforge.net/grub.html)
- Static Root of Trusted for Measurement (SRTM) support
- Support for S3 resume (sends command to TPM upon resume)
- TPM-specific menu for controlling aspects of the TPM
- [An optional test suite for the TIS interface]
All implementations necessarily follow specifications.
Regards,
Stefan
Hi Stefan,
I'm CC'ing the mailing list.
On Wed, Nov 24, 2010 at 11:45:17AM -0500, Stefan Berger wrote:
> Hi Kevin,
>
> while I am porting the BIOS code for TCG support to SeaBIOS, I am
> wondering about the following:
>
> 'When' is it recommendable to switch from 16 bit to 32bit.
To be honest, this has never really been done before in SeaBIOS, so I
think we'll have to figure this out as we go. Since you need to
access full memory, it looks like it will be required to jump into
32bit mode.
>I am
> asking because the interface I am implementing allows callers to
> pass input and output data structures using es:di and ds:si, with es
> and ds allowed to be loaded with anything possible. So my strategy
> in the Bochs BIOS was to switch to 32 bit even before calling the
> interrupt handler, there doing the case statement for branching into
> the actual functions (switch (regs->al)) and passing 32 bit pointers
> converted from es:di and ds:si to the functions doing the work and
> reading from those memory locations.
This sounds okay to me - it should be possible to implement
handle_1abb(regs) which does a call32(tcg32_1abb, regs). It's
possible to do all the pointer conversion while in 32bit mode.
>The 'thing' is also that
> several ones of the functions that can be called through the
> interrupt interface are also called from the implemented functions.
> Example:
>
> Functions A,B,C can be called via the interrupt handler.
>
> Function B also calls A.
> Function C also calls B.
This shouldn't really be an issue. The build should take care of
this.
>
> This is due to the hierarchical nature of the functions. Also, while
> for example B calls A, B fills a data structure (on the stack) that
> it passes to A. A of course can get the same data structure from the
> user calling the interrupt interface. So, by switching to 32 bit
> mode and converting to 32 bit pointers early I could previously
> avoid a lot of headaches with the segment registers in 16 bit mode
> and reading the data from wherever they may be. Would you have any
> concerns about switching to 32 bit mode early, so that the interrupt
> handler and anything subsequent runs in 32 bit mode?
I can't say for sure what will make sense without seeing the code
first, but it sounds okay to me.
-Kevin
>
> Regards,
> Stefan
>
>
>
Hi Matthew. I'm forwarding your mail to the seabios list. I'll also
take a look at this later on.
On Wed, Mar 09, 2011 at 06:29:20PM +0000, Matthew Bloch wrote:
> Hi Kevin -
>
> I'm not sure whether this is a qemu bug or SeaBIOS' but your commit
> 244caf86f11f5f65d166d91704f64cb673167abc seems to have broken qemu's
> ability to reset the system. I reported it on qemu's bug tracker as
> qemu behaves differently if KVM is turned on (i.e. you only see this
> behaviour with qemu, not kvm).
>
> I found that commenting this out in post.c seems to allow it to
> reboot properly - once:
>
> if (CONFIG_COREBOOT && HaveRunPost)
> // This is a soft reboot - invoke a hard reboot.
> tryReboot();
>
> The second reset seems to break the VGA but continues to boot, the
> third hangs at "Scanning for VGA ROM".
>
> Hope that's useful, not entirely sure how to work around it at
> present, other than "always use KVM".
>
> qemu is stil bundling a 0.5 build of seabios, but if they upgrade
> this is going to be a bit more visible.
>
> Regards,
>
> --
> Matthew Bloch
On Tue, Mar 08, 2011 at 09:00:05AM -0800, Jordan Justen wrote:
> On Mon, Mar 7, 2011 at 23:18, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
> > On Tue, Mar 8, 2011 at 12:54 AM, Jordan Justen <jljusten(a)gmail.com> wrote:
> >> The biggest issue that you guys care about for OVMF is a lack of
> >> legacy bios compatibility (CSM). There has been no progress in this
> >> area. (However, it has now been suggested by someone on our dev list
> >> for a potential Google Summer of Code project. We will have to see if
> >> anything comes of this...)
> >
> > That would be cool. Is there a way to just embed SeaBIOS? Or do the
> > UEFI APIs still need to be around when CSM kicks in?
>
> Yes, the UEFI system is still in place. The UEFI part still handles
> the majority of platform init, and calls into the CSM at various
> points. The CSM returns back to UEFI for all CSM calls, except the
> legacy boot.
Is there a concise list of these various callbacks between UEFI and
CSM?
If SeaBIOS just needs to be loaded up for legacy boots, that doesn't
sound too difficult. However, if SeaBIOS would need to translate
various BIOS calls into UEFI calls - that sounds like it could be
complex.
-Kevin
Some versions of Bochs don't like the MTRR initialization, so add
CONFIG_MTRR_INIT to control whether SeaBIOS will touch the MTRRs.
---
src/Kconfig | 6 ++++++
src/mtrr.c | 2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index fca73e4..f064b27 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -194,6 +194,12 @@ menu "Hardware support"
default y
help
Support System Management Mode (on emulators).
+ config MTRR_INIT
+ depends on !COREBOOT
+ bool "Initialize MTRRs"
+ default y
+ help
+ Initialize the Memory Type Range Registers (on emulators).
endmenu
menu "BIOS interfaces"
diff --git a/src/mtrr.c b/src/mtrr.c
index ed239c8..0502c18 100644
--- a/src/mtrr.c
+++ b/src/mtrr.c
@@ -32,7 +32,7 @@
void mtrr_setup(void)
{
- if (CONFIG_COREBOOT)
+ if (!CONFIG_MTRR_INIT || CONFIG_COREBOOT)
return;
u32 eax, ebx, ecx, edx, cpuid_features;
--
1.7.4
I've tagged a new release of SeaBIOS. For more information on the
release, please see:
http://seabios.org/Releases
New in this release:
* Setup code can relocate to high-memory to save space in c-f segments
* Build now configured via Kconfig
* Experimental support for AHCI controllers
* Support for run-time configuration of the boot order (via CBFS/fw_cfg "bootorder" file)
* Support T13 EDD3.0 spec
* Improved bounds checking on PCI memory allocation
* Several bug fixes
For information on obtaining SeaBIOS, please see:
http://seabios.org/Download
-Kevin
