Last time I checked[1], SeaBIOS required 1MiB of RAM, and the failure
modes were mean.
Back then, I asked whether we should enforce a suitable minimum RAM
size[2]. Peter Maydell replied that modelling RAM constraints involves
an expedition into the Generality Swamps, and wished me better luck than
he had.
Four and a half years later, the failure modes are as mean as ever. For
instance,
$ qemu-system-x86_64 --nodefaults -device VGA -m 640k
simply hangs for me, and
$ qemu-system-…
[View More]x86_64 --nodefaults -device VGA -m 16k
crashes with "qemu: fatal: Trying to execute code outside RAM or ROM at
0x0000000000004000" and a register dump with TCG, or the even less
helpful "KVM internal error. Suberror: 1" with KVM.
Waiting for "someone" to design and implement the completely general
solution has had the predictable result: nothing.
Are we now ready to accept a simple & stupid patch that actually helps
users, say letting boards that care declare minimum and maximum RAM
size? And make PC reject RAM size less than 1MiB, even though "someone"
might conceivably have firmware that works with less?
[1] Message-ID: <87fw7xwqkq.fsf(a)blackfin.pond.sub.org>
https://www.seabios.org/pipermail/seabios/2012-August/004343.html
[2] Message-ID: <87wr1921rd.fsf(a)blackfin.pond.sub.org>
https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01319.html
[View Less]
This series add several fixes to coreboot's framebuffer implementation
and it main purpose is to fix Microsoft's Windows as supported OS.
The series fixes the following issues:
* Windows shows no image in text-mode
* Windows NTLDR/bootmgr shows no image in VESA mode
* Windows shows no image in VESA mode
I was able to boot Windows using VgaSave driver in text-mode with a
fixed display resolution of 640x480@4Bpp.
I was able to boot Windows using VgaSave driver in VESA mode and
set a display …
[View More]resolution up to 1600x1200@24Bpp.
Most likely other VESA compatible bootloaders and operating systems
will be fixed, too.
While most issues are fixed, one critical remains:
Windows replaces int 15h at the start of the boot process, but SeaVGABios
relies on it to clear the screen.
It would be great if you could help me to implement a 32bit memcpy method
that doesn't rely on bios calls to copy memory.
All test in VESA mode had the clear screen feature disabled.
Patrick Rudolph (4):
SeaVGABios/cbvga: Assume VGA compatible GPU in text-mode
SeaVGABIOS/vbe: Query driver for scanline pitch
SeaVGABios/cbvga: Use active mode to clear screen
SeaVGABios/cbvga: Advertise compatible VESA modes
vgasrc/bochsvga.c | 5 ++
vgasrc/bochsvga.h | 1 +
vgasrc/cbvga.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
vgasrc/clext.c | 5 ++
vgasrc/stdvga.c | 5 ++
vgasrc/vbe.c | 2 +-
vgasrc/vgahw.h | 10 ++++
vgasrc/vgautil.h | 3 ++
8 files changed, 161 insertions(+), 6 deletions(-)
--
2.7.4
[View Less]
On QEMU it's necessary to manually reset the BIOS memory region
between 0xc0000-0x100000 on a reboot. After this manual memory reset
is completed, it's not valid to use the generic reset mechanisms.
Rename qemu_prep_reset() to qemu_reboot() and change the function to
immediately reboot after the code memcpy.
This fixes a bug that could cause code corruption on reboots - calling
the udelay() function (as invoked by i8042_reboot and/or pci_reboot)
was not valid after the BIOS was memcpy'd.
…
[View More]Reported-by: "Dr. David Alan Gilbert" <dgilbert(a)redhat.com>
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
This patch is based on Paolo's recommendation of first attempting a
PCI style reboot on QEMU. However, instead of next attempting a
keyboard reset, this patch attempts to signal an "INIT" via a triple
fault (as I think that's a bit simpler and less likely to fail).
---
src/fw/shadow.c | 14 +++++++++++++-
src/hw/pci.c | 1 -
src/hw/pci.h | 2 ++
src/resume.c | 4 ++--
src/util.h | 2 +-
5 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/fw/shadow.c b/src/fw/shadow.c
index cd02d3a..c80b266 100644
--- a/src/fw/shadow.c
+++ b/src/fw/shadow.c
@@ -167,7 +167,7 @@ make_bios_readonly(void)
}
void
-qemu_prep_reset(void)
+qemu_reboot(void)
{
if (!CONFIG_QEMU || runningOnXen())
return;
@@ -187,4 +187,16 @@ qemu_prep_reset(void)
memcpy(hrp + 4, hrp + 4 + BIOS_SRC_OFFSET, cend - (hrp + 4));
barrier();
HaveRunPost = 0;
+ barrier();
+
+ // Request a QEMU system reset. Do the reset in this function as
+ // the BIOS code was overwritten above and not all BIOS
+ // functionality may be available.
+
+ // Attempt PCI style reset
+ outb(0x02, PORT_PCI_REBOOT);
+ outb(0x06, PORT_PCI_REBOOT);
+
+ // Next try triple faulting the CPU to force a reset
+ asm volatile("int3");
}
diff --git a/src/hw/pci.c b/src/hw/pci.c
index 506ee56..8e3d617 100644
--- a/src/hw/pci.c
+++ b/src/hw/pci.c
@@ -12,7 +12,6 @@
#include "x86.h" // outl
#define PORT_PCI_CMD 0x0cf8
-#define PORT_PCI_REBOOT 0x0cf9
#define PORT_PCI_DATA 0x0cfc
void pci_config_writel(u16 bdf, u32 addr, u32 val)
diff --git a/src/hw/pci.h b/src/hw/pci.h
index bf50430..ee6e196 100644
--- a/src/hw/pci.h
+++ b/src/hw/pci.h
@@ -3,6 +3,8 @@
#include "types.h" // u32
+#define PORT_PCI_REBOOT 0x0cf9
+
static inline u8 pci_bdf_to_bus(u16 bdf) {
return bdf >> 8;
}
diff --git a/src/resume.c b/src/resume.c
index 99fa34f..fb0b8a8 100644
--- a/src/resume.c
+++ b/src/resume.c
@@ -125,8 +125,8 @@ tryReboot(void)
{
dprintf(1, "Attempting a hard reboot\n");
- // Setup for reset on qemu.
- qemu_prep_reset();
+ // Use a QEMU specific reboot on QEMU
+ qemu_reboot();
// Reboot using ACPI RESET_REG
acpi_reboot();
diff --git a/src/util.h b/src/util.h
index 336eaaf..8269057 100644
--- a/src/util.h
+++ b/src/util.h
@@ -123,7 +123,7 @@ void pirtable_setup(void);
// fw/shadow.c
void make_bios_writable(void);
void make_bios_readonly(void);
-void qemu_prep_reset(void);
+void qemu_reboot(void);
// fw/smbios.c
void smbios_legacy_setup(void);
--
2.5.5
[View Less]
On Sun, Mar 05, 2017 at 03:34:02PM -0700, Daniel Verkamp wrote:
> On Thu, Mar 2, 2017 at 7:51 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Thu, Feb 23, 2017 at 11:27:52PM -0700, Daniel Verkamp wrote:
> >> With the first two patches applied, I am able to install and boot
> >> FreeDOS on an Intel SSD DC P3700, an NVMe 1.0 device, in QEMU
> >> using PCI device assignment.
> >>
> >> The rest of the patches are minor issues found …
[View More]through inspection.
> >
> > Thanks. I committed this series.
> >
> > If this was tested with QEMU device passthrough, do you think we can
> > also enable NVMe on real hardware?
>
> I am not equipped to test on a complete real-hardware system, but I
> don't see anything that would prevent the driver from working
> correctly there.
If you tested with a real PCI device using PCI passthrough, then I
think it's safe to enable support on real machines.
-Kevin
[View Less]
With the first two patches applied, I am able to install and boot
FreeDOS on an Intel SSD DC P3700, an NVMe 1.0 device, in QEMU
using PCI device assignment.
The rest of the patches are minor issues found through inspection.
Normal user expect that when there is written on the screen "Press ESC for boot menu." and afterwards when the user have not pressed anything inside the short time, and see then "Booting from Hard Disk..." then when the user press ESC nothing should happen any more because the user simply missed the time period to press the ESC button.
In SeaBios there is a strange situation. When i see "Booting from Hard Disk..." and suddenly press ESC (few times) i get in a fully unusable state. The machine …
[View More]didnt do anything any more.
Seabios Version is rel-1.10.0-19-g8f598a4
...
Press ESC for boot menu.
Checking for bootsplash
Searching bootorder for: HALT
Mapping hd drive 0x000f5f80 to 0
drive 0x000f5f80: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=312581808
finalize PMM
malloc finalize
Add to e820 map: 0009fc00 00000400 2
Space available for UMB: c7000-ea800, f5840-f5f80
Add to e820 map: 7bdc0000 00040000 1
Returned 262144 bytes of ZoneHigh
e820 map has 9 items:
0: 0000000000000000 - 000000000009fc00 = 1 RAM
1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
3: 0000000000100000 - 000000007bb29000 = 1 RAM
4: 000000007bb29000 - 000000007bc00000 = 2 RESERVED
5: 000000007bc00000 - 000000007be00000 = 1 RAM
6: 000000007be00000 - 0000000080000000 = 2 RESERVED
7: 00000000e0000000 - 00000000f0000000 = 2 RESERVED
8: 00000000fed10000 - 0000000100000000 = 2 RESERVED
Jump to int19
enter handle_19:
NULL
Booting from Hard Disk...
Booting from 0000:7c00
ata_reset drive=0x000f5f80
ata_reset exit status=50
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
Get VBE Controller: VBE2 Signature found
VBE current mode=3
stub vbe_104fXX:406:
a=00004f15 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=eab4
si=00000000 di=00000000 bp=00001ff0 sp=000001f6 cs=0000 ip=9104 f=0202
stub vbe_104fXX:406:
a=00004f11 b=00000001 c=7bd00930 d=00000004 ds=7bd8 es=6000 ss=eab4
si=0007fbec di=00008080 bp=00001ff0 sp=000001f6 cs=0000 ip=9104 f=0202
set VGA mode 12
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
i8042_command cmd=ae
i8042_wait_write
This should not happen. The user expect to not get into a state where nothing can be done any more.
[View Less]