SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH] ata: Many CPUs cause seabios not to find boot disk
by Huaitong Han 06 Aug '15

06 Aug '15

When CPUs are 76, mptable_setup will alloc much fseg memory,and init_atadrive allocation fails. when CPUs are 86, mptable_setup allocation is too much to be met, and init_atadrive allocs success. So when CPUs are 76~85, seabios cannot find boot disk because init_atadrive allocation fails. Set a reserved area from fsegzone for atadrive allocation, and the fsegzone space also increases by the reserved area space. Signed-off-by: Huaitong Han <huaitong.han(a)intel.com> diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py index b976fb0..a7bc5b1 100755 --- a/scripts/layoutrom.py +++ b/scripts/layoutrom.py @@ -62,7 +62,7 @@ BUILD_BIOS_SIZE = 0x10000 BUILD_ROM_START = 0xc0000 BUILD_LOWRAM_END = 0xa0000 # Space to reserve in f-segment for dynamic allocations -BUILD_MIN_BIOSTABLE = 2048 +BUILD_MIN_BIOSTABLE = 2304 # Layout the 16bit code. This ensures sections with fixed offset # requirements are placed in the correct location. It also places the diff --git a/src/hw/ata.c b/src/hw/ata.c index fbbbbc1..12bd01f 100644 --- a/src/hw/ata.c +++ b/src/hw/ata.c @@ -710,7 +710,7 @@ ata_extract_model(char *model, u32 size, u16 *buffer) static struct atadrive_s * init_atadrive(struct atadrive_s *dummy, u16 *buffer) { - struct atadrive_s *adrive = malloc_fseg(sizeof(*adrive)); + struct atadrive_s *adrive = malloc_reserved_fseg(sizeof(*adrive)); if (!adrive) { warn_noalloc(); return NULL; @@ -920,7 +920,7 @@ init_controller(struct pci_device *pci, int chanid, int irq , u32 port1, u32 port2, u32 master) { static int ataid = 0; - struct ata_channel_s *chan_gf = malloc_fseg(sizeof(*chan_gf)); + struct ata_channel_s *chan_gf = malloc_reserved_fseg(sizeof(*chan_gf)); if (!chan_gf) { warn_noalloc(); return; diff --git a/src/malloc.c b/src/malloc.c index c4cb171..16114f5 100644 --- a/src/malloc.c +++ b/src/malloc.c @@ -296,6 +296,19 @@ malloc_getspace(struct zone_s *zone) return maxspace - reserve; } +u32 malloc_get_zone_space(struct zone_s *zone) +{ + // XXX - results not reliable when CONFIG_THREAD_OPTIONROMS + u32 totalspace = 0; + struct allocinfo_s *info; + hlist_for_each_entry(info, &zone->head, node) { + u32 space = info->allocend - info->dataend; + totalspace += space; + } + + return totalspace; +} + // Set a handle associated with an allocation. void malloc_sethandle(void *data, u32 handle) diff --git a/src/malloc.h b/src/malloc.h index 2bcb5bf..c70a468 100644 --- a/src/malloc.h +++ b/src/malloc.h @@ -20,6 +20,10 @@ int _free(void *data); u32 malloc_getspace(struct zone_s *zone); void malloc_sethandle(void *data, u32 handle); void *malloc_findhandle(u32 handle); +u32 malloc_get_zone_space(struct zone_s *zone); + +//Set a reserved zone to prevent key memory allocation failure +#define RESERVED_FSEG_ZONE 256 #define MALLOC_DEFAULT_HANDLE 0xFFFFFFFF // Minimum alignment of malloc'd memory @@ -32,6 +36,13 @@ static inline void *malloc_high(u32 size) { return _malloc(&ZoneHigh, size, MALLOC_MIN_ALIGN); } static inline void *malloc_fseg(u32 size) { + u32 allspace = malloc_get_zone_space(&ZoneFSeg); + if (allspace < (size + RESERVED_FSEG_ZONE)) + return NULL; + + return _malloc(&ZoneFSeg, size, MALLOC_MIN_ALIGN); +} +static inline void *malloc_reserved_fseg(u32 size){ return _malloc(&ZoneFSeg, size, MALLOC_MIN_ALIGN); } static inline void *malloc_tmplow(u32 size) { -- 1.9.1

3 5

Re: [SeaBIOS] Problems booting USB's on Chromebook Pixel 2015
by Kevin O'Connor 05 Aug '15

05 Aug '15

On Tue, Aug 04, 2015 at 12:31:35PM +0100, Paul Hurst wrote: > 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. It is odd that you are seeing screen corruption. Did you try different Linux distributions on your USB sticks? > 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. If you can get into Linux from SeaBIOS then that should be enough to obtain the SeaBIOS "cbmem" debug log. To do this, you'll need to download the coreboot source code (see http://coreboot.org/ ) and then build the tool in the 'util/cbmem/ directory. Then run "cbmem -c" under Linux (booted via SeaBIOS) and forward the full log to this mailing list. Getting the SeaBIOS debug log is the next key step to figuring out the problem. > 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. It is possible to update seabios. I've done it on my acer c720 chromebook. I don't have a pixel, but I imagine the steps are similar. It's possible to build seabios directly from source, create a rom using coreboot's cbfstool, and install it using the flashrom tool that comes with chromeos. I also understand that there are some scripts that automate it (eg, http://johnlewis.ie/ ). -Kevin

1 0

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

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

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

31 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 29 Jul '15

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

25 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS