SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] Problems booting USB's on Chromebook Pixel 2015
by Paul Hurst 04 Aug '15

04 Aug '15

Hi there Kevin, Hope you are well. I am running a 2015 Chromebook Pixel LS and I'm wondering if you could possibly help me as I'm at my whits end :-) I have enabled developer mode and legacy boot/usb boot using the commands readily available on Google but whenever I try to boot from any USB stick (I've tried USB 2 and 3), The screen just corrupts and the machine appears to hang. I know its running SeaBios as it tells me after I have pressed CTRL+L and it then offers me a boot menu with my devices correctly listed but its after that where the corruption starts. Completely by fluke on one of my linux usb sticks, I removed it and reinserted it while the corruption was on screen and that did actually allow the boot but obviously this isnt good for my USB integrity. I do hope you can help, I found your email via a google search as someone else seems to have had the same issue but there where no fix instructions that I could find. Finally, I've tried to see if its possible to update/re-install seaBios but there's nothing i can see online for beginners such as me. Thanks for your time. Paul -- [image: --] Paul Hurst [image: http://]about.me/paul.hurst <http://about.me/paul.hurst?promo=email_sig>

1 0

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

30 Jul '15

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 30 Jul '15

30 Jul '15

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 30 Jul '15

30 Jul '15

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 28 Jul '15

28 Jul '15

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í 28 Jul '15

28 Jul '15

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 25 Jul '15

25 Jul '15

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 24 Jul '15

24 Jul '15

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 24 Jul '15

24 Jul '15

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

[PATCH] timer: Add CONFIG_TSC_TIMER build option to disable the CPU TSC timer
by Kevin O'Connor 23 Jul '15

23 Jul '15

Allow users to remove the CPU timestamp counter support at compile time. The PMTIMER is frequently used instead of the TSC and this compile time option allows one to strip a few bytes from the final binary. This change also defaults the internal timer to use the PIT based timer until the PMTIMER or TSC is detected. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/Kconfig | 10 ++++++++-- src/hw/timer.c | 23 ++++++++--------------- 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index 14c38fb..b14e554 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -316,10 +316,16 @@ menu "Hardware support" help Initialize the Memory Type Range Registers (on emulators). config PMTIMER - bool "Use ACPI timer" + bool "Support ACPI timer" default y help - Use the ACPI timer instead of the TSC for timekeeping (on qemu). + Detect and use the ACPI timer for timekeeping. + config TSC_TIMER + bool "Support CPU timestamp counter as timer" + default y + help + Support for using the CPU timestamp counter as an internal + timing source. endmenu menu "BIOS interfaces" diff --git a/src/hw/timer.c b/src/hw/timer.c index 5edc9fd..882b772 100644 --- a/src/hw/timer.c +++ b/src/hw/timer.c @@ -49,8 +49,8 @@ #define PMTIMER_HZ 3579545 // Underlying Hz of the PM Timer #define PMTIMER_TO_PIT 3 // Ratio of pmtimer rate to pit rate -u32 TimerKHz VARFSEG; -u16 TimerPort VARFSEG; +u32 TimerKHz VARFSEG = DIV_ROUND_UP(PMTIMER_HZ, 1000 * PMTIMER_TO_PIT); +u16 TimerPort VARFSEG = PORT_PIT_COUNTER0; u8 ShiftTSC VARFSEG; @@ -92,6 +92,7 @@ tsctimer_setup(void) t = (t + 1) >> 1; } TimerKHz = DIV_ROUND_UP((u32)t, 1000 * PMTIMER_TO_PIT); + TimerPort = 0; dprintf(1, "CPU Mhz=%u\n", (TimerKHz << ShiftTSC) / 1000); } @@ -100,24 +101,16 @@ tsctimer_setup(void) void timer_setup(void) { - if (CONFIG_PMTIMER && TimerPort) { - dprintf(3, "pmtimer already configured; will not calibrate TSC\n"); + if (!CONFIG_TSC_TIMER || (CONFIG_PMTIMER && TimerPort != PORT_PIT_COUNTER0)) return; - } + // Check if CPU has a timestamp counter u32 eax, ebx, ecx, edx, cpuid_features = 0; cpuid(0, &eax, &ebx, &ecx, &edx); if (eax > 0) cpuid(1, &eax, &ebx, &ecx, &cpuid_features); - - if (!(cpuid_features & CPUID_TSC)) { - TimerPort = PORT_PIT_COUNTER0; - TimerKHz = DIV_ROUND_UP(PMTIMER_HZ, 1000 * PMTIMER_TO_PIT); - dprintf(3, "386/486 class CPU. Using TSC emulation\n"); - return; - } - - tsctimer_setup(); + if (cpuid_features & CPUID_TSC) + tsctimer_setup(); } void @@ -154,7 +147,7 @@ static u32 timer_read(void) { u16 port = GET_GLOBAL(TimerPort); - if (!port) + if (CONFIG_TSC_TIMER && !port) // Read from CPU TSC return rdtscll() >> GET_GLOBAL(ShiftTSC); if (CONFIG_PMTIMER && port != PORT_PIT_COUNTER0) -- 1.9.3

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS