This series enables seabios to run on some Baytrail CPU based
chromebooks. At least some of these machines do not support routing
of legacy interrupts and at least some have SDHCI controllers that do
not appear as regular PCI devices. This series is mainly a hack to
get some minimal support on the hardware.
This series is also available at:
https://github.com/KevinOConnor/seabios/tree/baytrail-testing
-Kevin
Kevin O'Connor (3):
Add minimal support for machines without hardware interrupts
ps2: Eliminate "etc/ps2-poll-only"; use CONFIG_HARDWARE_IRQ instead
sdcard: Allow sdcard addresses to be specified in CBFS files
docs/Runtime_config.md | 2 +-
src/Kconfig | 13 ++++++++++++-
src/clock.c | 31 +++++++++++++++++++++++++------
src/hw/pic.c | 14 ++++++++++++++
src/hw/pic.h | 4 ++++
src/hw/ps2port.c | 16 ++++++----------
src/hw/sdcard.c | 48 ++++++++++++++++++++++++++++++++++++------------
src/hw/timer.c | 2 ++
src/stacks.c | 5 ++++-
src/util.h | 1 +
10 files changed, 105 insertions(+), 31 deletions(-)
--
1.9.3
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
Implement support for booting from a PMEM region compatible with NVDIMM and
NFIT specifications.
The current implementation is still slow. When running a Linux guest on top of
QEMU in x86:
Using actual -kernel option:
QEMU startup time: .080
BIOS startup time: .060
Kernel setup time: .590
Total time: .730
Using -kernel option and fw_cfg DMA patch:
QEMU startup time: .080
BIOS startup time: .039
Kernel setup time: .002
Total time: .121
Using this patch series and adding the vmlinuz as a NVDIMM device:
QEMU startup time: .080
BIOS startup time: .065
Kernel setup time: .015
Total time: .160
This patch series is not ready for merging. There are things missing and
questions to be answered:
- Is it necessary to retrieve any other data from the NVDIMM?
- Is there any other nicer (and faster) option for the page table?
- Make NVDIMM a compile-time option, as the other devices.
- Add some kind of wrapper to the boot files instead of a direct vmlinux.
- Add NVDIMM boot priority support.
- Add support for intitrd and cmdline. Maybe in another NVDIMM, or in the
same, or through fw_cfg.
- Reorder code to change to long mode less times.
Any other proposals for improvements are appreciated
Marc Marí (3):
Basic NVDIMM PMEM support
Transitions to and from 64 bits
Add NVDIMM booting support
Makefile | 3 +-
src/boot.c | 18 ++++++++
src/config.h | 2 +
src/fw/biostables.c | 80 ++++++++++++++++++++++++++++++++
src/hw/nvdimm.c | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++++
src/hw/nvdimm.h | 12 +++++
src/misc.c | 4 ++
src/post.c | 2 +
src/romlayout.S | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++
src/stacks.c | 77 +++++++++++++++++++++++++++++++
src/stacks.h | 2 +
src/std/acpi.h | 40 ++++++++++++++++
src/util.h | 3 ++
src/x86.h | 1 +
14 files changed, 497 insertions(+), 1 deletion(-)
create mode 100644 src/hw/nvdimm.c
create mode 100644 src/hw/nvdimm.h
--
2.4.3
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 16a1b6e and SeaBIOS commit e4d2b8c
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: .002
Total time: .121
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
This series simplifies some of the existing trampoline code.
-Kevin
Kevin O'Connor (5):
Unify smm/sloppy variants of call32_prep/post and call16_helper
Rename Call32Data to Call16Data
Unify inline assembler in variants of call16 functions
Unify call32_sloppy() and call32()
Use transition32_nmi_off from call32() and call16_back()
src/romlayout.S | 10 +-
src/stacks.c | 282 +++++++++++++++++++++-----------------------------------
2 files changed, 106 insertions(+), 186 deletions(-)
--
2.4.3
Dear SeaBIOS folks,
building SeaBIOS from master, the version string shows 1.8.0-…, which
is more current than the rel-1.8.0-148-g75cb2b9 release. This is
confusing.
Should the stable branches be merged back into the master branch to get
a less confusing behavior? Or is there a different way to handle this?
Thanks,
Paul