SeaBIOS

seabios@seabios.org

3783 discussions

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

10 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 10 Oct '15

10 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 07 Oct '15

07 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 07 Oct '15

07 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 06 Oct '15

06 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 04 Oct '15

04 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í 02 Oct '15

02 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

SeaBIOS PAE experiment
by Kevin O'Connor 01 Oct '15

01 Oct '15

I was curious to see if SeaBIOS could run its 32bit code with PAE paging enabled. So, I put together some test code, and so far it seems to work. The patch below changes "transition32" to always enable PAE (if PAE has been detected as available). This means that all SeaBIOS 32bit "flat mode" code will end up running with paging enabled. Even the SMI handlers run with it on. The code is also available at: https://github.com/KevinOConnor/seabios/tree/testing The test code currently just creates an "identity mapping" of all memory in the first 4GB. However, it should be possible to setup page table entries to enable access to all ram/device memory - even above 4GB. I don't plan to commit the patch in its current state. In order for it to be useful, the identity mapping would need to be replaced with something more dynamic. That would likely require updating all the seabios driver code to use "ioremap()" before accessing any device memory. Some further notes: * The reason why PAE is interesting (instead of standard i386 paging) is that it allows for 64bit mappings and because one can set it up with just a single level page directory of 2MB pages. The single level page directory makes maintaining it much easier. * Since SeaBIOS doesn't touch much memory in practice, I think it would be possible to implement an ioremap() with a simple hashing scheme. That way, ioremap() wouldn't need any more storage beyond the 16KB page directory itself. * The SeaBIOS' malloc code could also be updated to remap pages which would make it possible for it to relocate itself above 4GB and to store data above 4GB. That's likely not all that useful, but I think it would be a little amusing for a 16bit bios to fully support 64bit memory. * I haven't done any performance tests. It's unclear what the performance impact of enabling paging on every 32bit entry point would be. -Kevin commit 6ffd9a0b0852c83850cc531a97d3f576bfc93e21 Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Mon Sep 28 13:55:29 2015 -0400 Experimental support for PAE paging Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> diff --git a/Makefile b/Makefile index 3a0d2e8..4ee5eb4 100644 --- a/Makefile +++ b/Makefile @@ -37,7 +37,7 @@ SRCBOTH=misc.c stacks.c output.c string.c block.c cdrom.c disk.c mouse.c kbd.c \ hw/lsi-scsi.c hw/esp-scsi.c hw/megasas.c SRC16=$(SRCBOTH) SRC32FLAT=$(SRCBOTH) post.c memmap.c malloc.c romfile.c x86.c optionroms.c \ - pmm.c font.c boot.c bootsplash.c jpeg.c bmp.c tcgbios.c sha1.c \ + pmm.c font.c boot.c bootsplash.c jpeg.c bmp.c tcgbios.c sha1.c paging.c \ hw/ahci.c hw/pvscsi.c hw/usb-xhci.c hw/usb-hub.c hw/sdcard.c \ fw/coreboot.c fw/lzmadecode.c fw/multiboot.c fw/csm.c fw/biostables.c \ fw/paravirt.c fw/shadow.c fw/pciinit.c fw/smm.c fw/smp.c fw/mtrr.c fw/xen.c \ diff --git a/src/Kconfig b/src/Kconfig index b873cd3..c28f671 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -122,6 +122,13 @@ endchoice selected, the memory is instead allocated from the "9-segment" (0x90000-0xa0000). + config PAGING + bool "PAE paging support" + default y + help + Enable paging in 32bit mode on processors that support PAE + paging. + config ROM_SIZE int "ROM size (in KB)" default 0 diff --git a/src/paging.c b/src/paging.c new file mode 100644 index 0000000..022fad0 --- /dev/null +++ b/src/paging.c @@ -0,0 +1,63 @@ +// CPU page table support +// +// Copyright (C) 2015 Kevin O'Connor <kevin(a)koconnor.net> +// +// This file may be distributed under the terms of the GNU LGPLv3 license. + +#include "malloc.h" // memalign_high +#include "memmap.h" // PAGE_SIZE +#include "output.h" // dprintf +#include "x86.h" // cpuid + +u32 PageDirPtr VARFSEG; + +#define PAE_MAP_SIZE (2*1024*1024) + +#define PG_P (1<<0) +#define PG_RW (1<<1) +#define PG_PS (1<<7) + +static void +fill_page_directory(u64 *dir) +{ + // Build dummy identity mapping for first 4GB + u32 i; + for (i=0; i<2048; i++) + dir[i] = i*PAE_MAP_SIZE | PG_P | PG_RW | PG_PS; +} + +// Detect PAE support and enable it if present +void +paging_preinit(void) +{ + if (!CONFIG_PAGING) + return; + // Check if CPU supports PAE + u32 eax, ebx, ecx, edx, cpuid_features = 0; + cpuid(0, &eax, &ebx, &ecx, &edx); + if (!eax) + return; + cpuid(1, &eax, &ebx, &ecx, &cpuid_features); + if (!(eax & (1<<6))) + return; + + dprintf(1, "PAE support found\n"); + u64 *pdp = malloc_high(sizeof(u64)*4); + u64 *dir = memalign_high(PAGE_SIZE, sizeof(u64)*2048); + if (!pdp || !dir) { + warn_noalloc(); + free(pdp); + free(dir); + return; + } + int i; + for (i=0; i<4; i++) + pdp[i] = ((u32)dir + i*4096) | PG_P; + fill_page_directory(dir); + + // Enable PAE + PageDirPtr = (u32)pdp; + cr3_write(PageDirPtr); + cr4_mask(0, CR4_PAE); + cr0_mask(0, CR0_PG); +} diff --git a/src/post.c b/src/post.c index e19b06c..d0f52fe 100644 --- a/src/post.c +++ b/src/post.c @@ -315,6 +315,7 @@ dopost(void) qemu_preinit(); coreboot_preinit(); malloc_preinit(); + paging_preinit(); // Relocate initialization code and call maininit(). reloc_preinit(maininit, NULL); diff --git a/src/romlayout.S b/src/romlayout.S index 823188b..3545612 100644 --- a/src/romlayout.S +++ b/src/romlayout.S @@ -51,12 +51,26 @@ transition32_nmi_off: orl $CR0_PE, %ecx movl %ecx, %cr0 +#if CONFIG_PAGING + movl %cs:PageDirPtr, %ecx + cmpl $0, %ecx + jz 1f + // Enable PAE paging + movl %ecx, %cr3 + movl %cr4, %ecx + orl $CR4_PAE, %ecx + movl %ecx, %cr4 + movl %cr0, %ecx + orl $CR0_PG, %ecx + movl %ecx, %cr0 +#endif + // start 32bit protected mode code - ljmpl $SEG32_MODE32_CS, $(BUILD_BIOS_ADDR + 1f) +1: ljmpl $SEG32_MODE32_CS, $(BUILD_BIOS_ADDR + 2f) .code32 // init data segments -1: movl $SEG32_MODE32_DS, %ecx +2: movl $SEG32_MODE32_DS, %ecx movw %cx, %ds movw %cx, %es movw %cx, %ss @@ -97,14 +111,25 @@ transition16big: .code16 // Disable protected mode 1: movl %cr0, %ecx - andl $~CR0_PE, %ecx + andl $~(CR0_PE|CR0_PG), %ecx movl %ecx, %cr0 +#if CONFIG_PAGING + cmpl $0, %cs:PageDirPtr + jz 2f + // Disable PAE paging + movl %cr4, %ecx + andl $~CR4_PAE, %ecx + movl %ecx, %cr4 + xorl %ecx, %ecx + movl %ecx, %cr3 +#endif + // far jump to flush CPU queue after transition to real mode - ljmpw $SEG_BIOS, $2f +2: ljmpw $SEG_BIOS, $3f // restore IDT to normal real-mode defaults -2: lidtw %cs:rmode_IDT_info +3: lidtw %cs:rmode_IDT_info // Clear segment registers xorw %cx, %cx diff --git a/src/stacks.c b/src/stacks.c index fa9c7db..555a2f5 100644 --- a/src/stacks.c +++ b/src/stacks.c @@ -28,7 +28,7 @@ struct { u8 cmosindex; u8 a20; u16 ss, fs, gs; - u32 cr0; + u32 cr0, cr3, cr4; struct descloc_s gdt; } Call16Data VARLOW; @@ -48,6 +48,10 @@ call32_prep(u8 method) // Called in 16bit protected mode?! return -1; SET_LOW(Call16Data.cr0, cr0); + if (CONFIG_PAGING && GET_GLOBAL(PageDirPtr)) { + SET_LOW(Call16Data.cr3, cr3_read()); + SET_LOW(Call16Data.cr4, cr4_read()); + } // Backup fs/gs and gdt SET_LOW(Call16Data.fs, GET_SEG(FS)); @@ -98,6 +102,14 @@ call32_post(void) u32 cr0_caching = GET_LOW(Call16Data.cr0) & (CR0_CD|CR0_NW); if (cr0_caching) cr0_mask(CR0_CD|CR0_NW, cr0_caching); + if (CONFIG_PAGING && GET_GLOBAL(PageDirPtr)) { + u32 cr4_pae = GET_LOW(Call16Data.cr4) & CR4_PAE; + if (cr4_pae) + cr4_mask(CR4_PAE, cr4_pae); + u32 cr3 = GET_LOW(Call16Data.cr3); + if (cr3) + cr3_write(cr3); + } } // Restore cmos index register diff --git a/src/util.h b/src/util.h index 327abeb..25a03ce 100644 --- a/src/util.h +++ b/src/util.h @@ -203,6 +203,10 @@ void vgarom_setup(void); void s3_resume_vga(void); extern int ScreenAndDebug; +// paging.c +extern u32 PageDirPtr; +void paging_preinit(void); + // pcibios.c void handle_1ab1(struct bregs *regs); void bios32_init(void); diff --git a/src/x86.h b/src/x86.h index 19d404f..b9b256d 100644 --- a/src/x86.h +++ b/src/x86.h @@ -14,6 +14,8 @@ #define CR0_NW (1<<29) // Not Write-through #define CR0_PE (1<<0) // Protection enable +#define CR4_PAE (1<<5) + // PORT_A20 bitdefs #define PORT_A20 0x0092 #define A20_ENABLE_BIT 0x02 @@ -92,6 +94,27 @@ static inline u16 cr0_vm86_read(void) { return cr0; } +static inline u32 cr3_read(void) { + u32 cr3; + asm("movl %%cr3, %0" : "=r"(cr3)); + return cr3; +} +static inline void cr3_write(u32 cr3) { + asm("movl %0, %%cr3" : : "r"(cr3)); +} + +static inline u32 cr4_read(void) { + u32 cr4; + asm("movl %%cr4, %0" : "=r"(cr4)); + return cr4; +} +static inline void cr4_write(u32 cr4) { + asm("movl %0, %%cr4" : : "r"(cr4)); +} +static inline void cr4_mask(u32 off, u32 on) { + cr4_write((cr4_read() & ~off) | on); +} + static inline u64 rdmsr(u32 index) { u64 ret;

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS