[SeaBIOS] 9-segment allocator
SeaBIOS v1.7.0 and earlier had an allocator that would reserve memory
in the "9-segment" - memory at the end of the first 640K. (Subsequent
versions of SeaBIOS allocate ram for "low memory" in the e-segment.)
I recently revived the 9-segment code for testing purposes. I don't
plan to commit this to the SeaBIOS repo - I'm posting it here in case
there is interest. It is also available at:
https://github.com/KevinOConnor/seabios/tree/test-9segment-20130223
-Kevin
>From 3608cf00a12c33f03c8dcb3f3ba272effdf3dfb7 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor
Date: Mon, 18 Feb 2013 10:45:39 -0500
Subject: [PATCH] Revive 9-segment allocator.
To: seabios@seabios.org
May be useful for testing.
Signed-off-by: Kevin O'Connor
---
src/Kconfig| 9 +
src/pmm.c | 113 -
src/post.c | 10 +++--
src/shadow.c | 4 +-
src/stacks.c | 3 +-
tools/layoutrom.py | 9 +++--
6 files changed, 131 insertions(+), 17 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index 98a6642..c88aaec 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -104,6 +104,15 @@ endchoice
help
Support floppy images in coreboot flash.
+config MALLOC_UPPERMEMORY
+bool "Allocate memory that needs to be in first Meg above 0xc"
+default y
+help
+Use the "Upper Memory Block" area for internal "low
+memory" allocations. If this is not selected, the memory
+is instead allocated between 0x9-0xa (the
+"9-segment").
+
endmenu
menu "Hardware support"
diff --git a/src/pmm.c b/src/pmm.c
index f02cf62..829547f 100644
--- a/src/pmm.c
+++ b/src/pmm.c
@@ -174,8 +174,12 @@ static struct allocinfo_s *RomBase;
u32
rom_get_max(void)
{
-return ALIGN_DOWN((u32)RomBase->allocend - OPROM_HEADER_RESERVE
- , OPTION_ROM_ALIGN);
+if (CONFIG_MALLOC_UPPERMEMORY)
+return ALIGN_DOWN((u32)RomBase->allocend - OPROM_HEADER_RESERVE
+ , OPTION_ROM_ALIGN);
+extern u8 code32init_end[];
+u32 end = (u32)code32init_end;
+return end > BUILD_BIOS_ADDR ? BUILD_BIOS_ADDR : end;
}
// Return the end of the last deployed option rom.
@@ -189,6 +193,11 @@ rom_get_last(void)
struct rom_header *
rom_reserve(u32 size)
{
+if (!CONFIG_MALLOC_UPPERMEMORY) {
+if (RomEnd + size > rom_get_max())
+return NULL;
+return (void*)RomEnd;
+}
u32 newend = ALIGN(RomEnd + size, OPTION_ROM_ALIGN) + OPROM_HEADER_RESERVE;
if (newend > (u32)RomBase->allocend)
return NULL;
@@ -313,8 +322,14 @@ malloc_init(void)
// Initialize low-memory region
extern u8 varlow_start[], varlow_end[], final_varlow_start[];
memmove(final_varlow_start, varlow_start, varlow_end - varlow_start);
-addSpace(&ZoneLow, zonelow_base + OPROM_HEADER_RESERVE,
final_varlow_start);
-RomBase = findLast(&ZoneLow);
+if (CONFIG_MALLOC_UPPERMEMORY) {
+addSpace(&ZoneLow, zonelow_base + OPROM_HEADER_RESERVE
+ , final_varlow_start);
+RomBase = findLast(&ZoneLow);
+} else {
+addSpace(&ZoneLow, (void*)ALIGN_DOWN((u32)final_varlow_start, 1024)
+ , final_varlow_start);
+}
// Add space available in f-segment to ZoneFSeg
extern u8 zonefseg_start[], zonefseg_end[];
@@ -330,13 +345,19 @@ malloc_prepboot(void)
ASSERT32FLAT();
dprintf(3, "malloc finalize\n");
-// Place an optionrom signature around used low mem area.
u32 base = rom_get_max();
-struct rom_header *dummyrom = (void*)base;
-dummyrom->signature = OPTION_ROM_SIGNATURE;
-int size = (BUILD_BIOS_ADDR - base) / 512;
-dummyrom->size = (size > 255) ? 255 : size;
memset((void*)RomEnd, 0, base-RomEnd);
+if (CONFIG_MALLOC_UPPERMEMORY) {
+// Place an optionrom signature around used low mem area.
+struct rom_header *dummyrom = (void*)base;
+dummyrom->signature = OPTION_ROM_SIGNATURE;
+int size = (BUILD_BIOS_ADDR - base) / 512;
+dummyrom->size = (size > 255) ? 255 : size;
+}
+
+// Reserve more low-mem if needed.
+u32 endlow = GET_BDA(mem_size_kb)*1024;
+add_e820(endlow, BUILD_LOWRAM_END-endlow, E820_RESERVED);
// Clear unused f-seg ram.
struct allocinfo_s *info = findLast(&ZoneFSeg);
@@ -357,6 +378,78 @@ malloc_prepboot(void)
/
+ * ebda movement
+ /
+
+// Move ebda
+static int
+relocate_ebda(u32 newebda, u32 oldebda, u8 ebda_size)
+{
+u32 lowram = GET_BDA(mem_size_kb) * 1024;
+if (oldebda != lowram)
+// EBDA isn't at end of ram - give up.
+ret
Re: [SeaBIOS] [PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()
David Woodhouse wrote: > > IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS) > > to QEMU and just have QEMU pass the tables to SeaBIOS for it to copy > > into memory like it does on CSM, coreboot, and Xen. > > I believe it's on Laszlo's TODO list. Put them in coreboot. //Peter pgpA8ClE0ZRMp.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()
On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote: > On Sat, Feb 23, 2013 at 04:28:06PM +, David Woodhouse wrote: > > On Sat, 2013-02-23 at 10:00 -0500, Kevin O'Connor wrote: > > > Patch 2 and 3 look okay to me - if there are no further comments I'll > > > push them. > > > > I think we're fairly happy with them. Laszlo put together the OVMF side > > (creating ACPI 2.0 tables instead of 1.0 and filling in the RESET_REG) > > and I've tested that it's doing the right thing. We should probably do > > something similar on the SeaBIOS side when it's creating its own tables, > > and feed same to acpi_set_reset_reg(). > > IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS) > to QEMU and just have QEMU pass the tables to SeaBIOS for it to copy > into memory like it does on CSM, coreboot, and Xen. I believe it's on Laszlo's TODO list. > If you want to call acpi_set_reset_reg() from pciinit.c (like the way > pmtimer_setup() is called) or something similar, that's fine with me. If we actually *created* ACPI 2.0 tables with a RESET_REG I'd have done so already. As it is, I'm happy to wait until we do so, or until we do, or until we get the tables from Qemu. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()
On Sat, Feb 23, 2013 at 04:28:06PM +, David Woodhouse wrote: > On Sat, 2013-02-23 at 10:00 -0500, Kevin O'Connor wrote: > > Patch 2 and 3 look okay to me - if there are no further comments I'll > > push them. > > I think we're fairly happy with them. Laszlo put together the OVMF side > (creating ACPI 2.0 tables instead of 1.0 and filling in the RESET_REG) > and I've tested that it's doing the right thing. We should probably do > something similar on the SeaBIOS side when it's creating its own tables, > and feed same to acpi_set_reset_reg(). IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS) to QEMU and just have QEMU pass the tables to SeaBIOS for it to copy into memory like it does on CSM, coreboot, and Xen. > > I'm not sure about patch 4. I do think we want to try the "standard" > > ways before poking at unstandard ports. > > Yeah, maybe. Perhaps we could enable that only if PCI devices 8086/7113 > or 8086/2918 were found in pci_probe_devices() ? If you want to call acpi_set_reset_reg() from pciinit.c (like the way pmtimer_setup() is called) or something similar, that's fine with me. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()
On Sat, 2013-02-23 at 10:00 -0500, Kevin O'Connor wrote: > Patch 2 and 3 look okay to me - if there are no further comments I'll > push them. I think we're fairly happy with them. Laszlo put together the OVMF side (creating ACPI 2.0 tables instead of 1.0 and filling in the RESET_REG) and I've tested that it's doing the right thing. We should probably do something similar on the SeaBIOS side when it's creating its own tables, and feed same to acpi_set_reset_reg(). > I'm not sure about patch 4. I do think we want to try the "standard" > ways before poking at unstandard ports. Yeah, maybe. Perhaps we could enable that only if PCI devices 8086/7113 or 8086/2918 were found in pci_probe_devices() ? Then again, if we *do* find those devices then our ACPI tables should have given us 0xcf9 as a RESET_REG. So perhaps patch #4 is superfluous. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH] Try to detect an unsuccessful hard-reboot to prevent soft-reboot loops.
There have been various kvm bugs that prevent reboots from working
properly. Generalize the existing test for a failed reboot to better
catch these cases.
Signed-off-by: Kevin O'Connor
---
src/resume.c | 9 +
src/shadow.c | 4
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/resume.c b/src/resume.c
index 784abac..9466480 100644
--- a/src/resume.c
+++ b/src/resume.c
@@ -123,10 +123,19 @@ s3_resume(void)
farcall16big(&br);
}
+u8 HaveAttemptedReboot VARLOW;
+
// Attempt to invoke a hard-reboot.
static void
tryReboot(void)
{
+if (HaveAttemptedReboot) {
+// Hard reboot has failed - try to shutdown machine.
+dprintf(1, "Unable to hard-reboot machine - attempting shutdown.\n");
+apm_shutdown();
+}
+HaveAttemptedReboot = 1;
+
dprintf(1, "Attempting a hard reboot\n");
// Setup for reset on qemu.
diff --git a/src/shadow.c b/src/shadow.c
index 0aac60b..e971fe9 100644
--- a/src/shadow.c
+++ b/src/shadow.c
@@ -169,8 +169,4 @@ qemu_prep_reset(void)
extern u8 code32flat_start[], code32flat_end[];
memcpy(code32flat_start, code32flat_start + BIOS_SRC_OFFSET
, code32flat_end - code32flat_start);
-
-if (HaveRunPost)
-// Memory copy failed to work - try to halt the machine.
-apm_shutdown();
}
--
1.7.11.7
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()
On Sat, Feb 23, 2013 at 12:24:47AM +, David Woodhouse wrote: > From: David Woodhouse > > Signed-off-by: David Woodhouse Thanks. I pushed patch 1. Patch 2 and 3 look okay to me - if there are no further comments I'll push them. I'm not sure about patch 4. I do think we want to try the "standard" ways before poking at unstandard ports. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
