SeaBIOS October 2015

seabios@seabios.org

13 participants
20 discussions

[PATCH 1/2] Consolidate code16*() functions
by Kevin O'Connor 09 Oct '15

09 Oct '15

Introduce code16_override() for cases where call16() should not restore the previous 16bit state. All callers now use call16_back() to invoke 16bit code, so rename call16_back() to call16(). Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/stacks.c | 61 +++++++++++++++++++++++++++--------------------------------- 1 file changed, 27 insertions(+), 34 deletions(-) diff --git a/src/stacks.c b/src/stacks.c index 850a335..a156138 100644 --- a/src/stacks.c +++ b/src/stacks.c @@ -92,7 +92,23 @@ call32_post(void) return method; } -// 16bit handler code called from call16_back() / call16_smm() +// Force next call16() to restore to a pristine cpu environment state +static void +call16_override(int big) +{ + ASSERT32FLAT(); + if (getesp() > BUILD_STACK_ADDR) + panic("call16_override with invalid stack\n"); + memset(&Call16Data, 0, sizeof(Call16Data)); + if (big) { + Call16Data.method = C16_BIG; + Call16Data.a20 = 1; + } else { + Call16Data.a20 = !CONFIG_DISABLE_A20; + } +} + +// 16bit handler code called from call16() / call16_smm() u32 VISIBLE16 call16_helper(u32 eax, u32 edx, u32 (*func)(u32 eax, u32 edx)) { @@ -243,11 +259,11 @@ call32(void *func, u32 eax, u32 errret) // Call a 16bit SeaBIOS function, restoring the mode from last call32(). static u32 -call16_back(u32 eax, u32 edx, void *func) +call16(u32 eax, u32 edx, void *func) { ASSERT32FLAT(); if (getesp() > MAIN_STACK_MAX) - panic("call16_back with invalid stack\n"); + panic("call16 with invalid stack\n"); if (CONFIG_CALL32_SMM && Call16Data.method == C16_SMM) return call16_smm(eax, edx, func); @@ -283,31 +299,6 @@ call16_back(u32 eax, u32 edx, void *func) return eax; } -// Call a 16bit SeaBIOS function in regular ("non-big") mode. -static u32 -call16(u32 eax, u32 edx, void *func) -{ - ASSERT32FLAT(); - if (getesp() > BUILD_STACK_ADDR) - panic("call16 with invalid stack\n"); - memset(&Call16Data, 0, sizeof(Call16Data)); - Call16Data.a20 = !CONFIG_DISABLE_A20; - return call16_back(eax, edx, func); -} - -// Call a 16bit SeaBIOS function in "big real" mode. -static u32 -call16big(u32 eax, u32 edx, void *func) -{ - ASSERT32FLAT(); - if (getesp() > BUILD_STACK_ADDR) - panic("call16big with invalid stack\n"); - memset(&Call16Data, 0, sizeof(Call16Data)); - Call16Data.method = C16_BIG; - Call16Data.a20 = 1; - return call16_back(eax, edx, func); -} - /**************************************************************** * Extra 16bit stack @@ -362,7 +353,7 @@ u32 stack_hop_back(u32 eax, u32 edx, void *func) { if (!MODESEGMENT) - return call16_back(eax, edx, func); + return call16(eax, edx, func); if (!MODE16 || !on_extra_stack()) return ((u32 (*)(u32, u32))func)(eax, edx); ASSERT16(); @@ -414,18 +405,20 @@ _farcall16(struct bregs *callregs, u16 callregseg) : "ebx", "ecx", "esi", "edi", "cc", "memory"); } +// Invoke external 16bit code. void farcall16(struct bregs *callregs) { - extern void _cfunc16__farcall16(void); - call16((u32)callregs, 0, _cfunc16__farcall16); + call16_override(0); + _farcall16(callregs, 0); } +// Invoke external 16bit code in "big real" mode. void farcall16big(struct bregs *callregs) { - extern void _cfunc16__farcall16(void); - call16big((u32)callregs, 0, _cfunc16__farcall16); + call16_override(1); + _farcall16(callregs, 0); } // Invoke a 16bit software interrupt. @@ -448,7 +441,7 @@ reset(void) { extern void reset_vector(void) __noreturn; if (!MODE16) - call16_back(0, 0, reset_vector); + call16(0, 0, reset_vector); reset_vector(); } -- 2.4.3

1 2

Re: [SeaBIOS] VT-d not enabled on Chromebook Pixel 2013 Link & Chromebook Pixel 2015 Samus
by Kevin O'Connor 09 Oct '15

09 Oct '15

On Fri, Oct 09, 2015 at 04:36:02PM +0100, edward wandasiewicz wrote: > Basically, we are missing a DMAR table in the BIOS [...] > $ acpidump -s > > ACPI: RSDP 0x00000000000F48E0 000024 (v02 CORE ) > ACPI: RSDT 0x000000007CF44030 000038 (v01 CORE COREBOOT 00000000 > CORE 00000000) > ACPI: XSDT 0x000000007CF440E0 00004C (v01 CORE COREBOOT 00000000 > CORE 00000000) > ACPI: DSDT 0x000000007CF44250 004720 (v02 COREv4 COREBOOT 20110725 > INTL 20130117) > ACPI: FACS 0x000000007CF44210 000040 > ACPI: FACP 0x000000007CF48970 0000F4 (v05 CORE COREBOOT 00000000 > CORE 00000001) > ACPI: HPET 0x000000007CF48A70 000038 (v01 CORE COREBOOT 00000000 > CORE 00000000) > ACPI: APIC 0x000000007CF48AB0 00006C (v01 CORE COREBOOT 00000000 > CORE 00000000) > ACPI: MCFG 0x000000007CF48B20 00003C (v01 CORE COREBOOT 00000000 > CORE 00000000) > ACPI: SSDT 0x000000007CF49BC0 000FF8 (v02 CORE COREBOOT 0000002A > CORE 0000002A) > > I get the same output, both before running qemu for the first time, > after a fresh reboot, and whilst running qemu - on the off chance, if > VT-x is enabled whilst running qemu, then maybe the DMAR tables for > VT-d might be available at the same time, but alas, no, it wasn't to > be. > > For VT-d to work, we would need a DMAR table in the BIOS. > > Is this at all possible? SeaBIOS just passes along the ACPI tables generated by coreboot. If you want to change those tables it needs to be done in the coreboot code - see: http://coreboot.org/ -Kevin

1 0

VT-d not enabled on Chromebook Pixel 2013 Link & Chromebook Pixel 2015 Samus
by edward wandasiewicz 09 Oct '15

09 Oct '15

Basically, we are missing a DMAR table in the BIOS How I came to the conclusion? 2013 Chromebook Pixel Link runs on Intel's HM75 chipset 2015 Chromebook Pixel Samus runs on Intel's HM97 chipset Looking up the HM75 chipset specs on http://ark.intel.com/#@Chipsets - links to http://ark.intel.com/products/64348 At a brief glance, Intel are telling us VT-d is not available on this chipset. However, if we click on 'Link', next to Essentials -> Datasheet Jump to page 282, we see the list of Intel® VT-d Features Supported So we know the motherboard chipset of HM75 is VT-d compatible at a native level. HM97 for mobile laptops is not listed on the website at present, but Wildcat Point chipsets of Z97 and H97 for Desktops are listed, and show the same wrong info of VT-d not available, at a quick glance, but further reading of the datasheet PDF indicates the opposite. We know the CPU on Link & Samus is VT-d compatible. To get VT-d to work, we need a compatible CPU, a compatible chipset and a flag in the BIOS. All 3 must be available, else we won't get VT-d. It appears we have all the wiring in place (CPU & chipset), but no switch attached to the wires, to turn it on or off (BIOS) The factory SeaBIOS does not turn off VT-x completely. If we run a qemu 2.4.0-4 on Arch Linux 4.2.2-1, it gets turned on at run time, Before we run qemu $ rdmsr 0x3a 0 Whilst running qemu and after we finish / kill qemu $ rdmsr 0x3a 5 So VT-x works fine. If we turn it on by running qemu, we should have access to VT-d, (theoretically speaking, if Google never turned off VT features in the SeaBIOS to begin with), but to no avail. If I run $ ls -l /sys/firmware/acpi/tables total 0 -r-------- 1 root root 108 Oct 9 14:40 APIC -r-------- 1 root root 18208 Oct 9 14:40 DSDT drwxr-xr-x 2 root root 0 Oct 9 14:40 dynamic -r-------- 1 root root 244 Oct 9 14:40 FACP -r-------- 1 root root 64 Oct 9 14:40 FACS1 -r-------- 1 root root 64 Oct 9 14:40 FACS2 -r-------- 1 root root 56 Oct 9 14:40 HPET -r-------- 1 root root 60 Oct 9 14:40 MCFG -r-------- 1 root root 4088 Oct 9 14:40 SSDT $ acpidump -s ACPI: RSDP 0x00000000000F48E0 000024 (v02 CORE ) ACPI: RSDT 0x000000007CF44030 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: XSDT 0x000000007CF440E0 00004C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: DSDT 0x000000007CF44250 004720 (v02 COREv4 COREBOOT 20110725 INTL 20130117) ACPI: FACS 0x000000007CF44210 000040 ACPI: FACP 0x000000007CF48970 0000F4 (v05 CORE COREBOOT 00000000 CORE 00000001) ACPI: HPET 0x000000007CF48A70 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: APIC 0x000000007CF48AB0 00006C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: MCFG 0x000000007CF48B20 00003C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: SSDT 0x000000007CF49BC0 000FF8 (v02 CORE COREBOOT 0000002A CORE 0000002A) I get the same output, both before running qemu for the first time, after a fresh reboot, and whilst running qemu - on the off chance, if VT-x is enabled whilst running qemu, then maybe the DMAR tables for VT-d might be available at the same time, but alas, no, it wasn't to be. For VT-d to work, we would need a DMAR table in the BIOS. Is this at all possible? Edward.

1 0

Re: [SeaBIOS] Problems booting legacy OSes on Chromebook Pixel 2015 - cbmem output
by Kevin O'Connor 06 Oct '15

06 Oct '15

On Mon, Oct 05, 2015 at 05:04:09PM +0100, edward wandasiewicz wrote: > Following on from this post - http://seabios.seabios.narkive.com/UAt3jVij > > I was having the exactly the same problem. So to summarize, you can boot Linux on Samus, but can not boot any *BSD? Both Linux and the BSDs do work on Link? [...] > If I run "vbeinfo" within Grub2 on the Pixel 2013, we get a long list, > including 640 x 400 and 800 x 600 > > On the Pixel 2015, "vbeinfo" only gives one entry, and one entry only > of 1280 x 850 x 16 > > Could this explain why *BSD operating systems and MemTest utility > cannot boot from USB or SD card (..properly..) ? They boot up in a > "text console", versus a "graphical console in text mode". It's certainly possible that cbvga SeaVGABIOS is the cause. The cbvga support in SeaVGABIOS is a hack to get some minimal display support when only a graphical framebuffer is available. It is known to not work with some bootloaders and OSes (that don't use the VGA BIOS to write to the screen). For that reason, it's not going to work with MemTest86+. Looks like you have a rom from John Lewis. I'd confirm that the SeaVGABIOS in the rom is relatively recent as there were some changes ("leal" emulation) that are known to work better on the *BSDs. If SeaVGABIOS is recent, then I think the next step would be to see if you can replace SeaVGABIOS with an Intel VGABIOS. -Kevin P.S. it should be possible to implement a SeaVGABIOS with support for mode switching on Intel graphics adapters. That should solve these problems (at least on Intel hardware), but it's a bit of work as I find the Intel graphics manuals to be basically indecipherable. :-(

3 6

Re: [SeaBIOS] Problems booting legacy OSes on Chromebook Pixel 2015 - cbmem output
by Kevin O'Connor 06 Oct '15

06 Oct '15

On Tue, Oct 06, 2015 at 01:40:05PM +0100, edward wandasiewicz wrote: > On Tue, Oct 6, 2015 at 2:02 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > P.S. it should be possible to implement a SeaVGABIOS with support for > > mode switching on Intel graphics adapters. That should solve these > > problems (at least on Intel hardware), but it's a bit of work as I > > find the Intel graphics manuals to be basically indecipherable. :-( > > Does this explain why there is only one mode available. Other > resolutions could be added, but since there is no support for mode > switching, we don't have the ability to change back and forth from any > of them, even if we tried. Right. Also, some boot loaders (and kernels) try to write directly to the legacy framebuffers. With cbvga SeaVGABIOS the gpu isn't actually using these legacy framebuffers. As a result the video output is not seen and it looks like a crash. If SeaVGABIOS could instruct the gpu to change into the legacy modes then the legacy framebuffers would actually be valid. -Kevin

1 0

Problems booting legacy OSes on Chromebook Pixel 2015 - cbmem output
by edward wandasiewicz 05 Oct '15

05 Oct '15

Following on from this post - http://seabios.seabios.narkive.com/UAt3jVij I was having the exactly the same problem. Booting up from arch linux and using the "libreboot" package in their yaourt package system, I've included the output from "cbmem -c" for both the Chromebook Pixel 2013 (Link) and 2015 (Samus) Chromebook Pixel 2013 (Link) $ cbmem -c http://pastebin.com/x6qDZ1Hr Chromebook Pixel 2015 (Samus) $ cbmem -c http://pastebin.com/fzx5aB48 Looking at the output from Samus, we have CBFS: WARNING: No file header found at 0x7ff480 - try next aligned address: 0x7ff4c0. CBFS: WARNING: 'pci8086,1616.rom' not found. CBFS: Could not find file 'pci8086,1616.rom'. Some further work, revealed it's ROM got linked to the pci8086,0406.rom See https://chromium-review.googlesource.com/#/c/221994/ https://chromium-review.googlesource.com/#/c/221994/2/chromeos/links If I run "vbeinfo" within Grub2 on the Pixel 2013, we get a long list, including 640 x 400 and 800 x 600 On the Pixel 2015, "vbeinfo" only gives one entry, and one entry only of 1280 x 850 x 16 Could this explain why *BSD operating systems and MemTest utility cannot boot from USB or SD card (..properly..) ? They boot up in a "text console", versus a "graphical console in text mode".

1 0

[RFC PATCH] x86: Support booting SeaBIOS
by Bin Meng 03 Oct '15

03 Oct '15

SeaBIOS is an open source implementation of a 16-bit X86 BIOS. It can run in an emulator or natively on X86 hardware with the use of coreboot. With SeaBIOS's help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS. As U-Boot, we have to manually create a table where SeaBIOS gets system information (eg: E820) from. The table unfortunately has to follow the coreboot table format as SeaBIOS currently supports booting as a coreboot payload. No U-Boot native support there. Booting SeaBIOS is done via U-Boot's bootelf command. This is the initial attempt to support booting SeaBIOS from U-Boot. If the basic concept is good, I can spend time working on follow-on patches to enable BIOS tables as well as graphics support. One issue is that U-Boot x86 does not has a ROM file system like coreboot. This brings difficulities to pass PCI option ROM to SeaBIOS, if we don't modify SeaBIOS's source codes. Maybe we should promote CBFS in U-Boot x86? This is tested on an Intel Crown Bay board with VGA card, booting SeaBIOS then chain loading a GRUB on a USB drive, then Linux kernel finally. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/x86/Kconfig | 10 ++++++++++ arch/x86/include/asm/tables.h | 29 +++++++++++++++++++++++++++++ arch/x86/lib/tables.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5e42d7d..b432ff8 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -401,6 +401,16 @@ config PCIE_ECAM_SIZE so a default 0x10000000 size covers all of the 256 buses which is the maximum number of PCI buses as defined by the PCI specification. +config SEABIOS + bool "Support booting SeaBIOS" + help + SeaBIOS is an open source implementation of a 16-bit X86 BIOS. + It can run in an emulator or natively on X86 hardware with the use + of coreboot/U-Boot. By turning on this option, U-Boot prepares + all the configuration tables that are necessary to boot SeaBIOS. + + Check http://www.seabios.org/SeaBIOS for details. + source "arch/x86/lib/efi/Kconfig" endmenu diff --git a/arch/x86/include/asm/tables.h b/arch/x86/include/asm/tables.h index 0aa6d9b..a083cac 100644 --- a/arch/x86/include/asm/tables.h +++ b/arch/x86/include/asm/tables.h @@ -7,6 +7,32 @@ #ifndef _X86_TABLES_H_ #define _X86_TABLES_H_ +#ifdef CONFIG_SEABIOS + +#define CB_TAG_MEMORY 1 + +struct cb_header { + u8 signature[4]; + u32 header_bytes; + u32 header_checksum; + u32 table_bytes; + u32 table_checksum; + u32 table_entries; +}; + +struct cb_memory_range { + u64 start; + u64 size; + u32 type; +}; + +struct cb_memory { + u32 tag; + u32 size; + struct cb_memory_range map[0]; +}; +#endif + /* * All x86 tables happen to like the address range from 0xf0000 to 0x100000. * We use 0xf0000 as the starting address to store those tables, including @@ -14,6 +40,9 @@ */ #define ROM_TABLE_ADDR 0xf0000 +/* SeaBIOS expects coreboot tables at address range 0x0000-0x1000 */ +#define CB_TABLE_ADDR 0x800 + /** * table_compute_checksum() - Compute a table checksum * diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c index f15b2e2..5849b2f 100644 --- a/arch/x86/lib/tables.c +++ b/arch/x86/lib/tables.c @@ -9,6 +9,7 @@ #include <asm/mpspec.h> #include <asm/tables.h> #include <asm/acpi_table.h> +#include <asm/e820.h> u8 table_compute_checksum(void *v, int len) { @@ -36,6 +37,41 @@ void table_fill_string(char *dest, const char *src, size_t n, char pad) dest[i] = pad; } +#ifdef CONFIG_SEABIOS +static u32 write_cb_tables(u32 addr) +{ + struct cb_header *cbh = (struct cb_header *)addr; + struct cb_memory *mem; + struct cb_memory_range *map; + struct e820entry entry[32]; + int num, i; + + memset(cbh, 0, sizeof(struct cb_header)); + strncpy((char *)cbh->signature, "LBIO", 4); + cbh->header_bytes = sizeof(struct cb_header); + + /* populate memory map table */ + mem = (struct cb_memory *)(cbh + 1); + mem->tag = CB_TAG_MEMORY; + map = mem->map; + num = install_e820_map(32, entry); + for (i = 0; i < num; i++) { + map->start = entry[i].addr; + map->size = entry[i].size; + map->type = entry[i].type; + map++; + } + mem->size = num * sizeof(struct cb_memory_range) + 8; + + cbh->table_bytes = mem->size; + cbh->table_checksum = compute_ip_checksum(mem, cbh->table_bytes); + cbh->table_entries = 1; + cbh->header_checksum = compute_ip_checksum(cbh, cbh->header_bytes); + + return (u32)map; +} +#endif + void write_tables(void) { u32 __maybe_unused rom_table_end = ROM_TABLE_ADDR; @@ -56,4 +92,7 @@ void write_tables(void) rom_table_end = write_acpi_tables(rom_table_end); rom_table_end = ALIGN(rom_table_end, 1024); #endif +#ifdef CONFIG_SEABIOS + write_cb_tables(CB_TABLE_ADDR); +#endif } -- 1.8.2.1

2 1

QEMU fw_cfg DMA interface
by Marc Marí 01 Oct '15

01 Oct '15

Implementation of the FW CFG DMA interface. When running a Linux guest on top of QEMU, using the -kernel options, this is the timing improvement for x86: QEMU commit b2312c6 and SeaBIOS commit 423542e QEMU startup time: .080 BIOS startup time: .060 Kernel setup time: .586 Total time: .726 QEMU with this patch series and SeaBIOS with this patch series QEMU startup time: .080 BIOS startup time: .039 Kernel setup time: .005 Total time: .126 QEMU startup time is the time between the start and the first kvm_entry. BIOS startup time is the time between the first kvm_entry and the start of function do_boot, in SeaBIOS. Kernel setup time is the time between the start of the function do_boot in SeaBIOS and the jump to the Linux kernel. As you can see, both the BIOS (because of ACPI tables and other configurations) and the Linux kernel boot (because of the copy to memory) are greatly improved with this new interface. Also, this new interface is an addon to the old interface. Both interfaces are compatible and interchangeable. Changes from v1: - Take into account order of fields in the FWCfgDmaAccess structure - Check and change endianness of FWCfgDmaAccess fields - Change order of fields in the FWCfgDmaAccess structure - Add FW_CFG_DMA_CTL_SKIP feature for control field - Split FW_CFG_SIZE in QEMU - Make FW_CFG_ID a bitmap of features - Add 64 bit address support for the transfer. Trigger when writing the low address, and address is 0 by default and at the end of each transfer. - Align ports and addresses. - Preserve old fw_cfg_comb_valid behaviour in QEMU - Update documentation to reflect all these changes Changes from v2: - Make IOports fw_cfg DMA region a different IO region. - Reuse everything for MMIO and IOport DMA regions - Make transfer status only based on control field - Use DMA helpers instead of direct map/unmap - Change ARM fw_cfg DMA address space - Change Linux boot process to match linuxboot.S - Add select capabilities in the FWCfgDmaAccess struct - Update documentation to reflect all these changes Changes from v3: - Set properly fw_cfg DMA fields in ARM - Set fw_cfg DMA boot process properly (by Laszlo Ersek) - Add signature to fw_cfg DMA address field (by Kevin O'Connor) - Minor nitpicks

4 10

[PATCH 07/15] malloc: Introduce common helper alloc_new_detail()
by Kevin O'Connor 01 Oct '15

01 Oct '15

Introduce helper for finding temp space to hold an "allocation detail struct" and use it in both alloc_add() and _malloc(). Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/list.h | 10 +++++++++ src/malloc.c | 72 +++++++++++++++++++++++++++++++----------------------------- 2 files changed, 47 insertions(+), 35 deletions(-) diff --git a/src/list.h b/src/list.h index de656b9..94512e3 100644 --- a/src/list.h +++ b/src/list.h @@ -61,6 +61,16 @@ hlist_add_after(struct hlist_node *n, struct hlist_node *prev) hlist_add(n, &prev->next); } +static inline void +hlist_replace(struct hlist_node *old, struct hlist_node *new) +{ + new->next = old->next; + if (new->next) + new->next->pprev = &new->next; + new->pprev = old->pprev; + *new->pprev = new; +} + #define hlist_for_each_entry(pos, head, member) \ for (pos = container_of((head)->first, typeof(*pos), member) \ ; pos != container_of(NULL, typeof(*pos), member) \ diff --git a/src/malloc.c b/src/malloc.c index 3aed014..6f8332e 100644 --- a/src/malloc.c +++ b/src/malloc.c @@ -57,8 +57,6 @@ alloc_new(struct zone_s *zone, u32 size, u32 align, struct allocinfo_s *fill) void *newallocend = (void*)ALIGN_DOWN((u32)allocend - size, align); if (newallocend >= dataend && newallocend <= allocend) { // Found space - now reserve it. - if (!fill) - fill = newallocend; fill->data = newallocend; fill->dataend = newallocend + size; fill->allocend = allocend; @@ -71,6 +69,28 @@ alloc_new(struct zone_s *zone, u32 size, u32 align, struct allocinfo_s *fill) return NULL; } +// Reserve space for a 'struct allocdetail_s' and fill +static struct allocdetail_s * +alloc_new_detail(struct allocdetail_s *temp) +{ + struct allocdetail_s *detail = alloc_new( + &ZoneTmpHigh, sizeof(*detail), MALLOC_MIN_ALIGN, &temp->detailinfo); + if (!detail) { + detail = alloc_new(&ZoneTmpLow, sizeof(*detail) + , MALLOC_MIN_ALIGN, &temp->detailinfo); + if (!detail) { + warn_noalloc(); + return NULL; + } + } + + // Fill final 'detail' allocation from data in 'temp' + memcpy(detail, temp, sizeof(*detail)); + hlist_replace(&temp->detailinfo.node, &detail->detailinfo.node); + hlist_replace(&temp->datainfo.node, &detail->datainfo.node); + return detail; +} + // Add new memory to a zone static void alloc_add(struct zone_s *zone, void *start, void *end) @@ -85,29 +105,15 @@ alloc_add(struct zone_s *zone, void *start, void *end) // Add space using temporary allocation info. struct allocdetail_s tempdetail; + tempdetail.handle = MALLOC_DEFAULT_HANDLE; tempdetail.datainfo.data = tempdetail.datainfo.dataend = start; tempdetail.datainfo.allocend = end; hlist_add(&tempdetail.datainfo.node, pprev); // Allocate final allocation info. - struct allocdetail_s *detail = alloc_new( - &ZoneTmpHigh, sizeof(*detail), MALLOC_MIN_ALIGN, NULL); - if (!detail) { - detail = alloc_new(&ZoneTmpLow, sizeof(*detail) - , MALLOC_MIN_ALIGN, NULL); - if (!detail) { - hlist_del(&tempdetail.datainfo.node); - warn_noalloc(); - return; - } - } - - // Replace temp alloc space with final alloc space - pprev = tempdetail.datainfo.node.pprev; - hlist_del(&tempdetail.datainfo.node); - memcpy(&detail->datainfo, &tempdetail.datainfo, sizeof(detail->datainfo)); - detail->handle = MALLOC_DEFAULT_HANDLE; - hlist_add(&detail->datainfo.node, pprev); + struct allocdetail_s *detail = alloc_new_detail(&tempdetail); + if (!detail) + hlist_del(&tempdetail.datainfo.node); } // Release space allocated with alloc_new() @@ -232,23 +238,19 @@ _malloc(struct zone_s *zone, u32 size, u32 align) if (!size) return NULL; - // Find and reserve space for bookkeeping. - struct allocdetail_s *detail = alloc_new( - &ZoneTmpHigh, sizeof(*detail), MALLOC_MIN_ALIGN, NULL); - if (!detail) { - detail = alloc_new(&ZoneTmpLow, sizeof(*detail) - , MALLOC_MIN_ALIGN, NULL); - if (!detail) - return NULL; - } - detail->handle = MALLOC_DEFAULT_HANDLE; - // Find and reserve space for main allocation - void *data = alloc_new(zone, size, align, &detail->datainfo); + struct allocdetail_s tempdetail; + tempdetail.handle = MALLOC_DEFAULT_HANDLE; + void *data = alloc_new(zone, size, align, &tempdetail.datainfo); if (!CONFIG_MALLOC_UPPERMEMORY && !data && zone == &ZoneLow) - data = zonelow_expand(size, align, &detail->datainfo); - if (!data) { - alloc_free(&detail->detailinfo); + data = zonelow_expand(size, align, &tempdetail.datainfo); + if (!data) + return NULL; + + // Find and reserve space for bookkeeping. + struct allocdetail_s *detail = alloc_new_detail(&tempdetail); + if (!detail) { + alloc_free(&tempdetail.datainfo); return NULL; } -- 2.4.3

1 8

[RFCv2 00/15] Experiment with PAE paging
by Kevin O'Connor 01 Oct '15

01 Oct '15

I was curious to see if SeaBIOS could run in memory above 4GB. This series demonstrates that it is possible. At the end of this experimental patch series, SeaBIOS can relocate itself to physical ram above 4GB and it can also run its internal threads above 4GB. I've tested this with QEMU running FreeDOS on an ATA drive - other configs are likely to break as most drivers have not been updated to use ioremap(). The series is also available at: https://github.com/KevinOConnor/seabios/tree/testing The first 7 patches are cleanup patches and should probably be committed even without the others. The remaining patches become more specific to PAE and become increasingly more experimental. The final patch is mostly a hack, but it does verify that SeaBIOS could use PAE to make full use of any RAM in the system. Patch 14 implements PAE paging support with a simple ioremap() hash scheme. The first 2MB uses an identity map, and no other memory is accessible without first calling ioremap() (or the similar memremap() ). That scheme is probably a bit too aggressive - it would likely be simpler to not require memremap() to access regular ram below 4GB. -Kevin Kevin O'Connor (15): e820: Introduce e820_remove() and avoid exporting E820_HOLE e820: Rename memmap.c to e820map.c and use consistent "e820_" prefix e820: Update debugging messages to report 64bit values virtio: Simplify vring alignment code virtio: Move standard definitions from virtio-ring.h to standard headers malloc: Use consistent naming for internal low-level "alloc" functions malloc: Introduce common helper alloc_new_detail() malloc: Don't mix virtual and physical addresses memmap: Move GDT declarations from misc.c to new file memmap.c optionroms: Use ioremap() on PCI rom bars to map them to memory smp: Use ioremap() on APIC memory tpm: Temporary ioremap() hack for tpm_drivers Implement protected mode exception handlers Experimental support for PAE paging Experiment with SeaBIOS internal memory above 4GB Makefile | 4 +- src/Kconfig | 7 ++ src/{memmap.c => e820map.c} | 18 ++- src/{memmap.h => e820map.h} | 9 +- src/fw/coreboot.c | 8 +- src/fw/csm.c | 14 +-- src/fw/paravirt.c | 22 ++-- src/fw/pciinit.c | 6 +- src/fw/smp.c | 23 ++-- src/fw/xen.c | 9 +- src/hw/pvscsi.c | 2 +- src/hw/ramdisk.c | 5 +- src/hw/tpm_drivers.c | 6 +- src/hw/virtio-ring.h | 36 ++---- src/list.h | 10 ++ src/malloc.c | 296 ++++++++++++++++++++++++-------------------- src/malloc.h | 22 ++-- src/memmap.c | 282 +++++++++++++++++++++++++---------------- src/memmap.h | 48 +++---- src/misc.c | 45 ------- src/optionroms.c | 5 +- src/pmm.c | 16 +-- src/post.c | 6 +- src/romlayout.S | 54 ++++++-- src/stacks.c | 17 ++- src/system.c | 2 +- src/x86.h | 53 +++++++- 27 files changed, 606 insertions(+), 419 deletions(-) copy src/{memmap.c => e820map.c} (90%) copy src/{memmap.h => e820map.h} (66%) -- 2.4.3

1 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS October 2015