July 2015 - SeaBIOS - mail.coreboot.org

[RFC 0/2] QEMU fw_cfg dma interface
by Marc Marí Aug. 19, 2015

Aug. 19, 2015

These patches, with the support in QEMU (patches in the QEMU mailing list) make the Linux kernel setup and boot approximately 10x faster. TODO: * Other ways to boot when detecting fw_cfg DMA interface? * Is 0xfef00000 a good address? Is there any better address? Is it possible to not make it hardcoded? Marc Marí (2): Add QEMU fw_cfg dma interface support Add Linux boot code for the fw_cfg dma interface src/boot.c | 14 ++- src/config.h | 1 + src/fw/paravirt.c | 298 +++++++++++++++++++++++++++++++++++++++++++----------- src/fw/paravirt.h | 50 +++++++++ src/romlayout.S | 20 ++++ 5 files changed, 321 insertions(+), 62 deletions(-) -- 2.4.3

3 11

[PATCH 0/5] sdcard improvements
by Kevin O'Connor Aug. 5, 2015

Aug. 5, 2015

This series expands the sdcard init sequence (as detailed in the SDHCI spec). It will probably still only work under QEMU, but it's further along. -Kevin Kevin O'Connor (5): sdcard: Check if card is present before sending commands to card sdcard: Implement controller frequency setting according to sdhci spec sdcard: Make sure controller support 3.3V before enabling it sdcard: Set timeout control register during init (to max allowed timeout) sdcard: Improve SD card initialization command sequence src/hw/sdcard.c | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 101 insertions(+), 9 deletions(-) -- 1.9.3

1 6

[PATCH] smm: ignore bits 16, 18-31 of SMM revision ID at runtime too
by Kevin O'Connor July 30, 2015

July 30, 2015

Check only the relevant bits of the SMM revision ID for both the init check and during runtime checks. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- I think the patch below should handle the extra revision checks. --- src/fw/smm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/fw/smm.c b/src/fw/smm.c index 5145f14..8f042ee 100644 --- a/src/fw/smm.c +++ b/src/fw/smm.c @@ -64,11 +64,11 @@ handle_smi(u16 cs) return; u8 cmd = inb(PORT_SMI_CMD); struct smm_layout *smm = MAKE_FLATPTR(cs, 0); + u32 rev = smm->cpu.i32.smm_rev & SMM_REV_MASK; dprintf(DEBUG_HDL_smi, "handle_smi cmd=%x smbase=%p\n", cmd, smm); if (smm == (void*)BUILD_SMM_INIT_ADDR) { // relocate SMBASE to 0xa0000 - u32 rev = smm->cpu.i32.smm_rev & SMM_REV_MASK; if (rev == SMM_REV_I32) { smm->cpu.i32.smm_base = BUILD_SMM_ADDR; } else if (rev == SMM_REV_I64) { @@ -92,7 +92,7 @@ handle_smi(u16 cs) } if (CONFIG_CALL32_SMM && cmd == CALL32SMM_CMDID) { - if (smm->cpu.i32.smm_rev == SMM_REV_I32) { + if (rev == SMM_REV_I32) { u32 regs[8]; memcpy(regs, &smm->cpu.i32.eax, sizeof(regs)); if (smm->cpu.i32.ecx == CALL32SMM_ENTERID) { @@ -107,7 +107,7 @@ handle_smi(u16 cs) memcpy(&smm->cpu.i32.eax, regs, sizeof(regs)); smm->cpu.i32.eip = regs[3]; } - } else if (smm->cpu.i64.smm_rev == SMM_REV_I64) { + } else if (rev == SMM_REV_I64) { u64 regs[8]; memcpy(regs, &smm->cpu.i64.rdi, sizeof(regs)); if ((u32)smm->cpu.i64.rcx == CALL32SMM_ENTERID) { -- 1.9.3

1 0

[PATCH] smm: ignore bits 16,18-31 of SMM revision ID
by Paolo Bonzini July 30, 2015

July 30, 2015

Bits 16-31 of the SMM revision ID are feature bits. We only need to check that SMBASE relocation is supported, but do not care about other features. In particular, this allows the SMM I/O instruction restart feature to be present. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- src/fw/smm.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/src/fw/smm.c b/src/fw/smm.c index dabc677..6cb484e 100644 --- a/src/fw/smm.c +++ b/src/fw/smm.c @@ -18,8 +18,14 @@ #include "util.h" // smm_setup #include "x86.h" // wbinvd -#define SMM_REV_I32 0x00020000 -#define SMM_REV_I64 0x00020064 +/* + * Check SMM state save area format (bits 0-15) and require support + * for SMBASE relocation. + */ +#define SMM_REV_MASK 0x0002ffff + +#define SMM_REV_I32 0x00020000 +#define SMM_REV_I64 0x00020064 struct smm_state { union { @@ -62,9 +68,10 @@ handle_smi(u16 cs) if (smm == (void*)BUILD_SMM_INIT_ADDR) { // relocate SMBASE to 0xa0000 - if (smm->cpu.i32.smm_rev == SMM_REV_I32) { + u32 rev = smm->cpu.i32.smm_rev & SMM_REV_MASK; + if (rev == SMM_REV_I32) { smm->cpu.i32.smm_base = BUILD_SMM_ADDR; - } else if (smm->cpu.i64.smm_rev == SMM_REV_I64) { + } else if (rev == SMM_REV_I64) { smm->cpu.i64.smm_base = BUILD_SMM_ADDR; } else { warn_internalerror(); -- 2.3.5

2 3

[PATCH] smm: fix outl argument order
by Paolo Bonzini July 30, 2015

July 30, 2015

The value is the first argument and the port is the second, but the code was using the opposite order. Reported-by: Stefan Weil <sw(a)weilnetz.de> Reviewed-by: Stefan Weil <sw(a)weilnetz.de> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- src/fw/smm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/fw/smm.c b/src/fw/smm.c index 6cb484e..5145f14 100644 --- a/src/fw/smm.c +++ b/src/fw/smm.c @@ -184,7 +184,7 @@ static void piix4_apmc_smm_setup(int isabdf, int i440_bdf) /* enable SMI generation */ value = inl(acpi_pm_base + PIIX_PMIO_GLBCTL); - outl(acpi_pm_base + PIIX_PMIO_GLBCTL, value | PIIX_PMIO_GLBCTL_SMI_EN); + outl(value | PIIX_PMIO_GLBCTL_SMI_EN, acpi_pm_base + PIIX_PMIO_GLBCTL); smm_relocate_and_restore(); -- 2.4.3

2 1

qemu cannot find boot disk with seabios when vcpus is 76
by Han, Huaitong July 28, 2015

July 28, 2015

hi,all When qemu vcpus value is 76~86, the qemu cannot find boot disk. The problem happens on seabios: mptable_setup will use much ZoneFSeg memory with the increase of the vcpus,and init_atadrive zonefseg allocation fails,so the seabios cannot find disk. 87 vcpus works just because mptable_setup ZoneFSeg allocation fails, then init_atadrive gets the memory. Because I am not familiar with bios, init_atadrive with ZoneLow or ZoneHigh instead of ZoneFSeg causes problems. and ZoneFSeg does not seem to be extended. init_atadrive also cannot be ahead of mptable_setup. it maybe a way for qemu that using "CONFIG_MPTABLE" to omit mptable_setup, because qemu with 87 and more vcpus works well. Any advices can be given to me for the bugfix ? Thanks Huaitong

2 1

Re: [SeaBIOS] NVDIMM and SeaBIOS
by Marc Marí July 28, 2015

July 28, 2015

On Mon, 27 Jul 2015 21:40:59 -0400 "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > On Mon, Jul 27, 2015 at 05:13:52PM +0200, Marc Marí wrote: > > Hi again > > > > Another way to speed up boot times we are looking at is using > > Intel's new PMEM, based on NVDIMMs (non-volatile DIMMs). These are > > discoverable through ACPI tables and mapped in the address space > > (they can also be used as a block device). Intel already > > implemented the emulation for QEMU [1], and we think it might be > > even faster than QEMU's pflash. > > > > This generates a new problem: this new device is mapped above 4G. > > This means, the zone cannot be accessed directly by 32 bits > > SeaBIOS. There are some solutions to this problem. The ones I've > > read about are: > > - Do some magic with paging > > - Enable 64 bit long mode > > > > Which do you think is the best way to proceed, at least for the > > sake of testing this PMEM? > > > > From a wider point of view: do you think it's worth to move (all or > > some part) of SeaBIOS to 64 bits? > > > > [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/137514 > > I don't think it would make sense to convert all of SeaBIOS to 64bit > as SeaBIOS still needs to be able to run in 16bit and 32bit mode. So, > it would be an extra mode. > > I suspect to add something like this it would be easiest to just have > a kernel booting shim that used 64bit mode or setup paging. Yes, that seems the most sensible option. A link about implementation: http://wiki.osdev.org/Setting_Up_Long_Mode If there are no more ideas, I'll be working on it for the next weeks. Any suggestions/tips/other about x86 or how to do it are appreciated. > Note that if it's defined in the ACPI DSDT, then it could be a real > pain to parse. The DSDT is it's own interpreted language. It is not defined in the ACPI DSDT. It is a new ACPI table (ACPI version 6, NFIT table). I've already been able to read and parse that table from SeaBIOS. > Also, if the kernel has to be copied to a memory location, then I > would be surprised that DMA fw_cfg would be slower than a PMEM > solution. Ultimately, I would think that QEMU could copy the kernel > to ram as fast or faster than the guest could. Another thing that I have in my bucket of things to try is booting Linux directly in 32 bit or 64 bit mode. If the kernel is boot in 64 bit mode directly, the image can be mapped anywhere, including above 4G. This avoids copying, and some 16 bit mode things. But that's not the intention at this precise moment. It might be the next step. At the end of: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Docume… > It would be great if we could go on-list with this discussion. > Added the NVDIMM link again and CC'd list. Thanks Marc

1 0

bootorder, ATA-SFF, AHCI and CSM; oh my!
by Jonathan A. Kollasch July 24, 2015

July 24, 2015

Hi, I've discovered a mess: - bootorder paths for ATA-SFF devices do not use the channel/port-on-controller number in the path, instead they use a volatile and unique-to-each-channel number that has no relation to the actual arrangement of the hardware. For instance, on a MCP55-based machine (no AHCI, but plenty of ATA-SFF channels/ports: The master drive on the PATA channel is (and should be, but is only by coincidence) /pci@i0cf8/*@4/drive@0/disk@0 but the first SATA port on /pci@i0cf8/*@5 is currently detected by SeaBIOS as something other than /pci@i0cf8/*@5/drive@0/disk@0 (the drive@ number is something like 2) and the second SATA port is something other than /pci@i0cf8/*@5/drive@1/disk@0 (drive@ number is usually more like 3) The /pci@i0cf8/*@5 controller only has two ports on it. - bootprio_find_ata_device() is shared between the ahci.c and ata.c drivers. This becomes interesting in a system using SeaBIOS as CSM and/or having certain combinations of ATA-SFF and/or AHCI controllers. (And why does the SeaBIOS CSM even have drivers in it? I would have thought it would be using the UEFI drivers...but maybe we had to ExitBootServices() to work properly...) - Thus the chanid argument to csm_bootprio_ata() could be any of two unrelated things: - the global-based index of a ata.c channel - the controller-based port index of any of the ahci.c controllers in the system I've attached a patch that attempts to address the issue with the ata.c bootorder paths, but it doesn't really fix the actual problem. Jonathan Kollasch

2 7

[PATCH] ramdisk: Allow ramdisk support (CONFIG_FLASH_FLOPPY) under QEMU
by Kevin O'Connor July 24, 2015

July 24, 2015

Don't require coreboot to use CONFIG_FLASH_FLOPPY - with the latest QEMU, it's possible to place a floppy image into fw_cfg using the qemu command line (eg, "-fw_cfg name=floppyimg/MyFloppy,file=file.img"). Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/Kconfig | 13 +++++++------ src/hw/ramdisk.c | 2 +- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index b14e554..d70624e 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -96,12 +96,6 @@ endchoice the CBFS filesystem is at a non-standard location (eg, 0xffe00000 if CBFS ends 2Meg below the end of flash). - config FLASH_FLOPPY - depends on COREBOOT_FLASH - bool "Floppy images in CBFS" - default y - help - Support floppy images in coreboot flash. config MULTIBOOT depends on COREBOOT bool "multiboot support" @@ -220,6 +214,13 @@ menu "Hardware support" default y help Support floppy drive access. + config FLASH_FLOPPY + depends on DRIVES + bool "Floppy images from CBFS or fw_cfg" + default y + help + Support floppy images stored in coreboot flash or from + QEMU fw_cfg. config PS2PORT depends on KEYBOARD || MOUSE diff --git a/src/hw/ramdisk.c b/src/hw/ramdisk.c index e847824..4cdf95f 100644 --- a/src/hw/ramdisk.c +++ b/src/hw/ramdisk.c @@ -53,7 +53,7 @@ ramdisk_setup(void) if (!drive) return; drive->type = DTYPE_RAMDISK; - dprintf(1, "Mapping CBFS floppy %s to addr %p\n", filename, pos); + dprintf(1, "Mapping floppy %s to addr %p\n", filename, pos); char *desc = znprintf(MAXDESCSIZE, "Ramdisk [%s]", &filename[10]); boot_add_floppy(drive, desc, bootprio_find_named_rom(filename, 0)); } -- 1.9.3

1 1

[PATCH] Don't enable interrupts prior to IVT and PIC setup
by Kevin O'Connor July 24, 2015

July 24, 2015

The machine may crash if an interrupt occurs prior to the setup of the interrupt vector table (IVT) and programmable interrupt controller (PIC). This patch makes sure that interrupts remain disabled until these components are setup. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/fw/csm.c | 1 + src/post.c | 2 +- src/stacks.c | 13 ++++++++----- src/stacks.h | 2 +- 4 files changed, 11 insertions(+), 7 deletions(-) diff --git a/src/fw/csm.c b/src/fw/csm.c index 7cdb398..aee2f90 100644 --- a/src/fw/csm.c +++ b/src/fw/csm.c @@ -183,6 +183,7 @@ handle_csm_0002(struct bregs *regs) struct bios_data_area_s *bda = MAKE_FLATPTR(SEG_BDA, 0); bda->hdcount = 0; + thread_setup(); mathcp_setup(); timer_setup(); clock_setup(); diff --git a/src/post.c b/src/post.c index 6157b50..8cb7b7c 100644 --- a/src/post.c +++ b/src/post.c @@ -124,7 +124,6 @@ interface_init(void) bda_init(); // Other interfaces - thread_init(); boot_init(); bios32_init(); pmm_init(); @@ -167,6 +166,7 @@ platform_hardware_setup(void) // Init base pc hardware. pic_setup(); + thread_setup(); mathcp_setup(); timer_setup(); clock_setup(); diff --git a/src/stacks.c b/src/stacks.c index 1dbdfe9..1ad9ef0 100644 --- a/src/stacks.c +++ b/src/stacks.c @@ -558,12 +558,13 @@ getCurThread(void) return (void*)ALIGN_DOWN(esp, THREADSTACKSIZE); } -static int ThreadControl; +static u8 CanInterrupt, ThreadControl; // Initialize the support for internal threads. void -thread_init(void) +thread_setup(void) { + CanInterrupt = 1; if (! CONFIG_THREADS) return; ThreadControl = romfile_loadint("etc/threads", 1); @@ -673,11 +674,12 @@ void yield(void) { if (MODESEGMENT || !CONFIG_THREADS) { - check_irqs(); + if (MODESEGMENT || CanInterrupt) + check_irqs(); return; } struct thread_info *cur = getCurThread(); - if (cur == &MainThread) + if (cur == &MainThread && CanInterrupt) // Permit irqs to fire check_irqs(); @@ -705,7 +707,8 @@ yield_toirq(void) yield(); return; } - wait_irq(); + if (MODESEGMENT || CanInterrupt) + wait_irq(); } // Wait for all threads (other than the main thread) to complete. diff --git a/src/stacks.h b/src/stacks.h index 82c4c3c..a3b031c 100644 --- a/src/stacks.h +++ b/src/stacks.h @@ -28,7 +28,7 @@ extern struct thread_info MainThread; struct thread_info *getCurThread(void); void yield(void); void yield_toirq(void); -void thread_init(void); +void thread_setup(void); int threads_during_optionroms(void); void run_thread(void (*func)(void*), void *data); void wait_threads(void); -- 1.9.3

1 1