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.
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
>
>
>
Some cleanups I came across while reviewing the boot code.
Gleb - patch 7 conflicts with your last patch - I hope it isn't a big
deal to fixup though. (I'm still reviewing your last patch.)
-Kevin
Kevin O'Connor (9):
Rename add_ordered_drive() to add_drive() and use in map_hd_drive().
Call setup_translation() from map_hd_drive().
Don't access drive_g->desc from boot_cdrom().
Remove Drives global struct in favor of independent global variables.
Move IPL.checkfloppysig to a global (CheckFloppySig) in boot.c.
Move IPL.bev to static variables in boot.c
Move IPL.fw_bootorder to static variables in boot.c.
Minor reorganization of some of the boot_xxx code in boot.c.
Remove drive->desc field.
src/ahci.c | 40 +++++++---------
src/ata.c | 41 +++++++---------
src/block.c | 64 ++++++++++++-------------
src/boot.c | 137 +++++++++++++++++++++++++++++++-----------------------
src/boot.h | 36 +-------------
src/cdrom.c | 2 +-
src/coreboot.c | 5 +--
src/disk.c | 2 +-
src/disk.h | 13 +----
src/floppy.c | 28 ++++++-----
src/output.c | 26 ++++++++++
src/ramdisk.c | 10 +++-
src/usb-msc.c | 32 ++++++-------
src/util.h | 2 +
src/virtio-blk.c | 11 ++---
15 files changed, 221 insertions(+), 228 deletions(-)
--
1.7.3.4
On Wed, Dec 29, 2010 at 12:47:14PM -0500, Kevin O'Connor wrote:
> The drive description is allocated with malloc_tmp() and is thus only
> available during the POST phase - boot_cdrom() is called during the
> boot phase.
Odd - two patches got merged into one here.
-Kevin