We expect to use the space between the top of option ROMs and the bottom
of our own BIOS code as a stack. OVMF was previously marking the whole
region from 0xC0000 to 0xFFFFF read-only before invoking our Legacy16Boot
method. Read-only stack considered harmful.
Version 0.98 of the CSM spec adds the UmaAddress and UmaSize fields, which
allow the CSM to specify a memory region that needs to be writable.
There exists CONFIG_MALLOC_UPPERMEMORY which we could turn off to use
the 9-segment, but that isn't particularly useful for the CSM case
either because that memory isn't ours to play with until the final
Legacy16Boot call. There's a LowPmmMemory given to use by UEFI to play
with, but that's right in the *middle* of low memory and using that for
persistent allocations would be painful. So just require
CONFIG_MALLOC_UPPERMEMORY when building a CSM.
Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com>
---
v2: Require CONFIG_MALLOC_UPPERMEMORY. Default UmaAddress to &zonelow_base.
src/Kconfig | 2 +-
src/fw/csm.c | 6 +++++-
src/std/LegacyBios.h | 20 ++++++++++++++++++++
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index a42ab2d..093075c 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -114,7 +114,7 @@ endchoice
the BIOS in 16bit protected mode.
config MALLOC_UPPERMEMORY
- bool "Allocate memory that needs to be in first Meg above 0xc0000"
+ bool "Allocate memory that needs to be in first Meg above 0xc0000" if !CSM
default y
help
Use the "Upper Memory Block" area (0xc0000-0xf0000) for
diff --git a/src/fw/csm.c b/src/fw/csm.c
index dfb0d12..4e4b688 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -34,6 +34,8 @@ EFI_COMPATIBILITY16_TABLE csm_compat_table VARFSEG __aligned(16) = {
.Compatibility16CallOffset = 0 /* Filled in by checkrom.py */,
.OemIdStringPointer = (u32)"SeaBIOS",
.AcpiRsdPtrPointer = (u32)&csm_rsdp,
+ .UmaAddress = (u32)&zonelow_base,
+ .UmaSize = 0x10000,
};
EFI_TO_COMPATIBILITY16_INIT_TABLE *csm_init_table;
@@ -46,9 +48,11 @@ extern void __csm_return(struct bregs *regs) __noreturn;
static void
csm_return(struct bregs *regs)
{
- dprintf(3, "handle_csm returning AX=%04x\n", regs->ax);
+ u32 top = rom_get_max();
PICMask = pic_irqmask_read();
+ csm_compat_table.UmaAddress = top;
+ csm_compat_table.UmaSize = 0xf0000 - top;
__csm_return(regs);
}
diff --git a/src/std/LegacyBios.h b/src/std/LegacyBios.h
index cf0c3c5..5170c37 100644
--- a/src/std/LegacyBios.h
+++ b/src/std/LegacyBios.h
@@ -228,6 +228,26 @@ typedef struct {
/// Maximum PCI bus number assigned.
///
UINT8 LastPciBus;
+
+ ///
+ /// Start address of UMB RAM
+ ///
+ UINT32 UmaAddress;
+
+ ///
+ /// Size of UMB RAM
+ ///
+ UINT32 UmaSize;
+
+ ///
+ /// Start address of persistent allocation in high (>1MiB) memory
+ ///
+ UINT32 HiPermanentMemoryAddress;
+
+ ///
+ /// Size of persistent allocation in high (>1MiB) memory
+ ///
+ UINT32 HiPermanentMemorySize;
} EFI_COMPATIBILITY16_TABLE;
///
--
1.8.3.1
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
As with the recent change to AHCI, if the pvscsi driver needs to jump
into 32bit mode to access a register, then it's better to run the
pvscsi driver entirely in 32bit mode.
Evgeny, can you take a look at this and give it a test? Also, what
command line do you use for testing?
I tried testing locally by adding:
-device pvscsi,id=pvscsi0 -device scsi-disk,bus=pvscsi0.0,drive=drive0 -drive id=drive0,if=none,file=dos-drivec-new
to my qemu command line (both qemu v1.6 and qemu v1.7), but it doesn't
work for me even before my changes. It hangs in
pvscsi_wait_intr_cmpl().
-Kevin
Kevin O'Connor (3):
pvscsi: Don't store reference to struct pci_device.
pvscsi: Always run entirely in 32bit mode.
pvscsi: Remove use of LOWFLAT and GLOBALFLAT macros.
Makefile | 4 +--
src/block.c | 8 +++--
src/hw/blockcmd.c | 3 +-
src/hw/pvscsi.c | 106 +++++++++++++++++++++++++-----------------------------
4 files changed, 58 insertions(+), 63 deletions(-)
--
1.8.3.1
This provides basic debug output on the Quark system, assuming that
*something* (i.e. coreboot or UEFI) has set it up in advance for us.
Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com>
---
I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code,
and making that generic enough to handle I/O access *or* MMIO access
depending on what's present... but in fact that's probably overkill.
This isn't really limited to Quark; it would work with any 16550 device
wired up as MMIO32. But we can expand it as required, I think. No point
in starting off with the same functionality as the 5000-odd lines of the
Linux kernel's 8250_pci.c.
What do I need to do if called in 32-bit segmented mode? I'm guessing
that's not going to work right now...
src/Kconfig | 5 +++++
src/fw/csm.c | 2 ++
src/output.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig
index a42ab2d..bdc2602 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -472,6 +472,11 @@ menu "Debugging"
Set to zero to disable debugging.
+ config DEBUG_QUARK_UART
+ depends on DEBUG_LEVEL != 0
+ bool "Debug to Quark UART #1"
+ default n
+
config DEBUG_SERIAL
depends on DEBUG_LEVEL != 0
bool "Serial port debugging"
diff --git a/src/fw/csm.c b/src/fw/csm.c
index dfb0d12..afd7ffe 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -280,6 +280,8 @@ handle_csm(struct bregs *regs)
if (!CONFIG_CSM)
return;
+ debug_serial_preinit();
+
dprintf(3, "handle_csm regs %p AX=%04x\n", regs, regs->ax);
pic_irqmask_write(PICMask);
diff --git a/src/output.c b/src/output.c
index b47625f..a90d350 100644
--- a/src/output.c
+++ b/src/output.c
@@ -17,6 +17,8 @@
#include "stacks.h" // call16_int
#include "string.h" // memset
#include "util.h" // ScreenAndDebug
+#include "hw/pci_regs.h" // PCI_VENDOR_ID, PCI_BASE_ADDRESS_0
+#include "hw/pci.h" // pci_config_readl
struct putcinfo {
void (*func)(struct putcinfo *info, char c);
@@ -31,9 +33,59 @@ struct putcinfo {
u16 DebugOutputPort VARFSEG = 0x402;
+static volatile u32 *quark_uart_addr = 0;
+
+extern void _cfunc32flat_quark_uart_preinit(void);
+extern void _cfunc32flat_quark_uart_putc(void);
+extern void _cfunc32flat_quark_uart_flush(void);
+
+void quark_uart_preinit(void)
+{
+ // debug port is bus 0, device 0x14, function 5.
+ u16 uart_bdf = pci_to_bdf(0, 0x14, 5);
+
+ // If it isn't a Quark UART...
+ if (pci_config_readl(uart_bdf, PCI_VENDOR_ID) != 0x09368086)
+ return;
+
+ u32 bar0 = pci_config_readl(uart_bdf, PCI_BASE_ADDRESS_0);
+ if (!(bar0 & 0xf))
+ quark_uart_addr = (void *)bar0;
+}
+
+void quark_uart_putc(char c)
+{
+ if (!quark_uart_addr)
+ return;
+
+ int timeout = DEBUG_TIMEOUT;
+ while ((quark_uart_addr[SEROFF_LSR] & 0x20) != 0x20)
+ if (!timeout--)
+ // Ran out of time.
+ return;
+ quark_uart_addr[SEROFF_DATA] = c;
+}
+
+void quark_uart_flush(void)
+{
+ if (!quark_uart_addr)
+ return;
+ int timeout = DEBUG_TIMEOUT;
+ while ((quark_uart_addr[SEROFF_LSR] & 0x60) != 0x60)
+ if (!timeout--)
+ // Ran out of time.
+ return;
+}
+
void
debug_serial_preinit(void)
{
+ if (CONFIG_DEBUG_QUARK_UART) {
+ if (MODE16)
+ call32(_cfunc32flat_quark_uart_preinit, 0, 0);
+ else
+ quark_uart_preinit();
+ }
if (!CONFIG_DEBUG_SERIAL)
return;
// setup for serial logging: 8N1
@@ -54,6 +106,12 @@ debug_serial_preinit(void)
static void
debug_serial(char c)
{
+ if (CONFIG_DEBUG_QUARK_UART) {
+ if (MODE16)
+ call32(_cfunc32flat_quark_uart_putc, c, 0);
+ else
+ quark_uart_putc(c);
+ }
if (!CONFIG_DEBUG_SERIAL)
return;
int timeout = DEBUG_TIMEOUT;
@@ -68,6 +126,12 @@ debug_serial(char c)
static void
debug_serial_flush(void)
{
+ if (CONFIG_DEBUG_QUARK_UART) {
+ if (MODE16)
+ call32(_cfunc32flat_quark_uart_flush, 0, 0);
+ else
+ quark_uart_flush();
+ }
if (!CONFIG_DEBUG_SERIAL)
return;
int timeout = DEBUG_TIMEOUT;
--
1.8.3.1
--
dwmw2
On Tue, Mar 18, 2014 at 07:23:17PM -0400, Gabriel L. Somlo wrote:
> At this point, can anyone with access to a real, physical, NUMA
> system dump the smbios tables with dmidecode and post them here?
> I think that would be very informative.
So I thrashed around a bit trying to find a real NUMA box,
and found a Dell R410 whose BIOS claims to support NUMA by
disabling the "Node Interleaving" option (haven't actually
configured it to run NUMA, but based on what else I found,
I no longer think I need to -- keep reading :)
So, to my surprise, I noticed this machine did NOT have any
Type 20 tables in SMBIOS at all !!!
Then, after a more careful reading of the SMBIOS manual, I
noticed that Type 20 was made OPTIONAL as v2.5 of the spec,
cca. 2006 !!!
In conclusion, we *could* simply scan e820 for E820_RAM type
regions and generate Type 19 tables for each one we find,
and we no longer have to care at all about generating Type 20
nodes to link 19s to 17s, which basically makes the problem
go away, as far as I am concerned.
I tested this (omitting Type 20) on OS X (10.6 through 10.9),
XPsp3 and Win7, successfully, without either of them noticing
any changes from previous executions where smbios tables
were "different" (i.e., when they used to include T20).
At this point, though, I'd like some feedback before I shoot
out another version (v5) of this patch set:
- Should I pretend we're generating v2.5 tables ?
- this means Type 4 now has extra fields (i.e. the
number of cores, etc), which should be relatively
easy to add, so I'd be OK doing that, if we agree
on everything else. Heck, how about going all out
and implementing v2.8 ? That would get us past the
2T limit in Types 16, 17, and 19 !
- SeaBIOS is still in charge of providing the smbios_entry_point
structure, and it's unlikely we can reasonably expect it to
bump the version to 2.5 (not that it seems to matter, if my
tests are to be believed)
- on that note, SeaBIOS will still cheerfully generate
Type 20 tables if nothing is supplied to it via fw_cfg
from QEMU, and, again, I'm not sure how likely it is
we can get it to stop doing that :)
- Does anyone still care ? ;)
Let me know what you all think!
Thanks,
--Gabriel
On Sun, Mar 23, 2014 at 12:04:32PM +0200, Michael S. Tsirkin wrote:
> On Sat, Mar 22, 2014 at 07:35:53AM +0000, Jeff wrote:
> > Hello,
> >
> > Can someone tells me if the compilation went well? I'm worried about:
> >
> > out/src/fw/ssdt-pcihp.dsl.i 45: Return (PCEJ(_SUN))
> > Warning 3104 - Reserved method should not return a value ^ (_EJ0)
>
> Yes, it's ok - it's a new warning produced by recent iasl versions in the ssdt.
> We moved the ACPI to QEMU so the seabios versions isn't actively
> maintained.
> But it's easy to fix so maybe the below should be applied.
> Or maybe it's better not to touch it ...
If it's an obvious bug fix, it's probably better to fix it. Could
you send to the mailing list?
-Kevin
>
>
> Note: lightly tested with a linux guest only.
>
> --->
> acpi: fix up iasl warning
>
> out/src/fw/ssdt-pcihp.dsl.i 45: Return (PCEJ(_SUN))
> Warning 3104 - Reserved method should not return a value ^ (_EJ0)
>
> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
>
> ---
>
> diff --git a/src/fw/ssdt-pcihp.dsl b/src/fw/ssdt-pcihp.dsl
> index 67e485f..cb24c11 100644
> --- a/src/fw/ssdt-pcihp.dsl
> +++ b/src/fw/ssdt-pcihp.dsl
> @@ -29,7 +29,7 @@ DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1)
> Name(_ADR, 0xAA0000)
> ACPI_EXTRACT_METHOD_STRING ssdt_pcihp_ej0
> Method(_EJ0, 1) {
> - Return (PCEJ(_SUN))
> + PCEJ(_SUN)
> }
> }
> }
On Tue, Mar 11, 2014 at 11:49:29AM -0400, Kevin O'Connor wrote:
> Make sure to initialize the entire smbios area to zero so that any
> field not explicitly initialized does not have random values. (It was
> found that the memory_error_information_handle field in smbios_type_17
> was not being set.)
FYI, I have pushed this patch to the master repo.
-Kevin
Hi,
Am 14.03.2014 04:19, schrieb Anthony Liguori:
> On behalf of the QEMU Team, I'd like to announce the availability of the
> first release candidate for the QEMU 2.0 release. This release is meant
> for testing purposes and should not be used in a production environment.
>
> http://wiki.qemu.org/download/qemu-2.0.0-rc0.tar.bz2
I've run into an issue with the SeaBIOS submodule included in the QEMU
tarball: The SeaBIOS scripts/buildversion.sh script looks for a .git
directory or file and, if absent, goes on to look for a .version file,
neither of which the QEMU tarball ships. That means it will fall back to
"?" as version, whereas the binary blob contributed by Gerd displays
"rel-1.7.4-0-g96917a8".
Should our tarball workflow include generating a roms/seabios/.version
file based on git-describe in that directory to fix this mismatch?
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
On Easynote LM85 under both coreboot and vendor BIOS NPORTS is 3, yet
port 4 is used for CD-ROM. NPORTS is RO on this chipset and has same
value on vendor BIOS as well, so it's not a coreboot bug.
Linux does essentially the same, by increasing nports variable if bits
in PI are set above nports-1. GRUB ignores PI since this problem was
detected.
diff --git a/src/hw/ahci.c b/src/hw/ahci.c
index ff5d5f9..3193d81 100644
--- a/src/hw/ahci.c
+++ b/src/hw/ahci.c
@@ -601,7 +601,7 @@ ahci_controller_setup(struct pci_device *pci)
dprintf(2, "AHCI: cap 0x%x, ports_impl 0x%x\n",
ctrl->caps, ctrl->ports);
- max = ctrl->caps & 0x1f;
+ max = 0x1f;
for (pnr = 0; pnr <= max; pnr++) {
if (!(ctrl->ports & (1 << pnr)))
continue;