SeaBIOS

seabios@seabios.org

3770 discussions

Re: [SeaBIOS] [coreboot] Seabios problems
by congedete＠voila.fr 16 Jan '10

16 Jan '10

Here is the report as attachment. > Message du 16/01/10 à 12h59 > De : "Kevin O'Connor" <kevin(a)koconnor.net> > A : congedete(a)voila.fr > Copie à : seabios(a)seabios.org, "coreboot" <coreboot(a)coreboot.org> > Objet : Re: [coreboot] Seabios problems > > > On Sat, Jan 16, 2010 at 12:06:01PM +0100, congedete(a)voila.fr wrote: > > Hello Kevin, > > > > I can't give you the full log for the keyboard problem. I think this > > is a timeout issue: when I run Seabios in debuglevel=8, no problem, > > but if debuglevel=1 or even 4, my keyboard don't want to initialize > > most of the time. So, I suppose that sending debug data to the port > > gives time to the keyboard to initialize correctly. > > Okay - can you send a log with a failure when at debug level 4 then? > > > The attachment files are the logs you asked me reporting the Vista > > booting error. Do you use DMA since version 0.5.1 to boot ? > > Okay - I'll take a look. It seems there is an issue with DMA on your > board. What's 'lspci' report for your machine? > > -Kevin > > ____________________________________________________ Vous n’avez pas encore adressé vos voeux ? Retrouvez nos cartes sur http://carte-de-voeux.voila.fr

1 0

Advise on updating SeaBIOS in stable
by Anthony Liguori 14 Jan '10

14 Jan '10

Hi, I'm ready to cut another qemu stable release and I'm contemplating whether to update to 0.5.1 in stable. Generally speaking, we try to limit stable to bug fixes and changes that aren't user visible. 0.5.1 looks like a point on the master branch as opposed to a separate branch. I wonder what the thinking is within SeaBIOS about what sort of changes will be in the 0.5.x series vs. what would result in 0.6.0. Regards, Anthony Liguori

4 6

int 1589 test case?
by Kevin O'Connor 10 Jan '10

10 Jan '10

Hi Sebastian, Do you have a test case for int1589 bios support? I've coded what I think is a working implementation (see below), but I'm not sure how to test it. BTW, I think the Bochs BIOS implementation has bh and bl backwards. -Kevin diff --git a/src/pic.c b/src/pic.c index f421bec..8992a8b 100644 --- a/src/pic.c +++ b/src/pic.c @@ -10,15 +10,14 @@ #include "config.h" // CONFIG_* void -pic_setup(void) +set_pics(u8 irq0, u8 irq8) { - dprintf(3, "init pic\n"); // Send ICW1 (select OCW1 + will send ICW4) outb(0x11, PORT_PIC1_CMD); outb(0x11, PORT_PIC2_CMD); // Send ICW2 (base irqs: 0x08-0x0f for irq0-7, 0x70-0x77 for irq8-15) - outb(0x08, PORT_PIC1_DATA); - outb(0x70, PORT_PIC2_DATA); + outb(irq0, PORT_PIC1_DATA); + outb(irq8, PORT_PIC2_DATA); // Send ICW3 (cascaded pic ids) outb(0x04, PORT_PIC1_DATA); outb(0x02, PORT_PIC2_DATA); @@ -30,6 +29,13 @@ pic_setup(void) outb(~0, PORT_PIC2_DATA); } +void +pic_setup(void) +{ + dprintf(3, "init pic\n"); + set_pics(0x08, 0x70); +} + // Handler for otherwise unused hardware irqs. void VISIBLE16 handle_hwpic1(struct bregs *regs) diff --git a/src/pic.h b/src/pic.h index 290fcb0..586ef38 100644 --- a/src/pic.h +++ b/src/pic.h @@ -98,6 +98,7 @@ __enable_hwirq(int hwirq, void (*func)(void)) __enable_hwirq(irq, func); \ } while (0) +void set_pics(u8 irq0, u8 irq8); void pic_setup(void); #endif // pic.h diff --git a/src/system.c b/src/system.c index ffcced9..bf1fc62 100644 --- a/src/system.c +++ b/src/system.c @@ -182,6 +182,47 @@ handle_1588(struct bregs *regs) set_success(regs); } +// Switch to protected mode +static void +handle_1589(struct bregs *regs) +{ + set_a20(1); + + set_pics(regs->bl, regs->bh); + + u64 *gdt_far = (void*)(regs->si + 0); + u16 gdt_seg = regs->es; + SET_FARVAR(gdt_seg, gdt_far[7], GDT_CODE | GDT_LIMIT(0x0ffff) + | GDT_BASE(0xf0000)); + + regs->ds = 3<<3; // 3rd gdt descriptor is %ds + regs->es = 4<<3; // 4th gdt descriptor is %es + regs->code.seg = 6<<3; // 6th gdt descriptor is %cs + + set_code_success(regs); + + asm volatile( + // Load new descriptor tables + " lgdtw %%es:(1<<3)(%%si)\n" + " lidtw %%es:(2<<3)(%%si)\n" + + // Enable protected mode + " movl %%cr0, %%eax\n" + " orl $" __stringify(CR0_PE) ", %%eax\n" + " movl %%eax, %%cr0\n" + + // far jump to flush CPU queue after transition to protected mode + " ljmpw $(7<<3), $1f\n" + + // GDT points to valid descriptor table, now load SS + "1:movw $(5<<3), %%ax\n" + " movw %%ax, %%ds\n" + " movw %%ax, %%ss\n" + : + : "S"(gdt_far) + : "eax", "cc"); +} + // Device busy interrupt. Called by Int 16h when no key available static void handle_1590(struct bregs *regs) @@ -309,6 +350,7 @@ handle_15(struct bregs *regs) case 0x86: handle_1586(regs); break; case 0x87: handle_1587(regs); break; case 0x88: handle_1588(regs); break; + case 0x89: handle_1589(regs); break; case 0x90: handle_1590(regs); break; case 0x91: handle_1591(regs); break; case 0xc0: handle_15c0(regs); break;

2 10

[ANN] SeaBIOS 0.5.1
by Kevin O'Connor 09 Jan '10

09 Jan '10

I've tagged a new release of SeaBIOS. For more information on the release, please see: http://seabios.org/Releases New in this release is: * Support for 32bit PCI BIOS * Support for int1589 calls * MPTable fixes for OpenBSD * ATA DMA and bus-mastering support * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download -Kevin

1 0

wrong memsize in smbios_init()
by Sebastian Herbszt 07 Jan '10

07 Jan '10

src/smbios.c has u64 memsize = RamSizeOver4G; if (memsize) memsize += 0x100000000ull; else memsize = RamSize; RamSizeOver4G = "total ram" - "start of pci hole" (e.g. 0xe0000000 in qemu, 0xc0000000 in bochs) Adding 4GB is wrong. With 33 GB of RAM i end up with 16+16+2 instead of 16+16+1 in smbios tables. The patch below fixes it for me. above_4g_mem_size in qemu is a possible misnomer. - Sebastian --- a/src/smbios.c +++ b/src/smbios.c @@ -405,11 +405,7 @@ smbios_init(void) int cpu_num; for (cpu_num = 1; cpu_num <= MaxCountCPUs; cpu_num++) add_struct(4, p, cpu_num); - u64 memsize = RamSizeOver4G; - if (memsize) - memsize += 0x100000000ull; - else - memsize = RamSize; + u64 memsize = RamSize + RamSizeOver4G; memsize = memsize / (1024 * 1024); int nr_mem_devs = (memsize + 0x3fff) >> 14; add_struct(16, p, memsize, nr_mem_devs);

3 3

Re: [SeaBIOS] Missing BIOS32 in QEMU 0.12.1
by Kevin O'Connor 07 Jan '10

07 Jan '10

On Sun, Jan 03, 2010 at 10:37:58PM +0100, Aurelien Jarno wrote: > Hi, > > I have just discovered that contrary to QEMU 0.11.x, version 0.12.1 does > not support BIOS32. This is due to to the switch from pc-bios to > SeaBIOS. This prevents booting certain OS like Hurd. Unfortunately QEMU > 0.12.x does not support pc-bios anymore. > > I have seen that BIOS32 support has been recently added to SeaBIOS. Can > we imagine a new SeaBIOS release, that we include in QEMU 0.12.2 ? > > Aurelien > > -- > Aurelien Jarno GPG: 1024D/F1BCDB73 > aurelien(a)aurel32.net http://www.aurel32.net Hi Aurelien, I'm not sure if your original mail made it to the qemu mailing list. I'm okay with tagging a new SeaBIOS release. Whether or not a qemu release is pushed out with it is up to the qemu developers. -Kevin

2 1

ram_probe() displays wrong size for RamSizeOver4G
by Sebastian Herbszt 06 Jan '10

06 Jan '10

I have modified Bochs to support the needed cmos bytes for specifying memory above pci hole. If i set it up to 5120 MB i get the following: 00000271154i[BIOS ] Ram Size=0xc0000000 (0xffffffff80000000 high) The "high" value looks odd (upper 32 bit should be 0). - Sebastian

2 2

FDPT not registered when physical == logical ?!
by Samuel Thibault 04 Jan '10

04 Jan '10

Hello, Reading fill_fdpt, I see that when nlc == npc && nlh == nph && nlspt == npspt, SET_IVT(0x41,etc.) is not done. Shouldn't it be anyway? Samuel

2 1

[PATCH] Detect latest FC12 gcc -combine breakage
by Kevin O'Connor 03 Jan '10

03 Jan '10

It looks like the latest FC12 compiler has broken the "-combine" flag in a slightly different way. This patch updates the test case to make sure the build still doesn't try to use it. I've already committed this change (and also pushed my queue of patches). -Kevin diff --git a/tools/test-gcc.sh b/tools/test-gcc.sh index 3bb91e9..ce3497b 100755 --- a/tools/test-gcc.sh +++ b/tools/test-gcc.sh @@ -55,6 +55,7 @@ void func1(struct ts *r); struct s1_s { int v; } g1; void __attribute__((externally_visible)) func2() { struct s1_s *l1 = &g1; + l1->v=0; } EOF cat - > $TMPFILE2 <<EOF

1 0

[PATCH] Make MTRR region 0xc0000-0x100000 be cached.
by Kevin O'Connor 03 Jan '10

03 Jan '10

The current MTRR code in SeaBIOS uses uncached ram for 0xc0000-0x100000. This seems overly pessimistic as "write protect" should be sufficient. (Note, a WP mtrr does not prevent writes - it is a caching strategy for memory that can be read-only.) I'm not sure how much KVM really uses the MTRRs, but if it does honor them this should make bootup a bit faster as it will allow caching of the SeaBIOS code. This change also clears all the variable mtrrs, and makes sure all the mtrrs are set before they are enabled. -Kevin diff --git a/src/mtrr.c b/src/mtrr.c index 7d1df09..ed239c8 100644 --- a/src/mtrr.c +++ b/src/mtrr.c @@ -44,42 +44,42 @@ void mtrr_setup(void) dprintf(3, "init mtrr\n"); - int i, vcnt, fix, wc; - u32 mtrr_cap; - union { - u8 valb[8]; - u64 val; - } u; - - mtrr_cap = rdmsr(MSR_MTRRcap); - vcnt = mtrr_cap & 0xff; - fix = mtrr_cap & 0x100; - wc = mtrr_cap & 0x400; + u32 mtrr_cap = rdmsr(MSR_MTRRcap); + int vcnt = mtrr_cap & 0xff; + int fix = mtrr_cap & 0x100; if (!vcnt || !fix) return; - // Fixed MTRRs + // Disable MTRRs + wrmsr_smp(MSR_MTRRdefType, 0); + + // Set fixed MTRRs + union u64b { + u8 valb[8]; + u64 val; + } u; u.val = 0; - for (i = 0; i < 8; ++i) + int i; + for (i = 0; i < 8; i++) if (RamSize >= 65536 * (i + 1)) u.valb[i] = MTRR_MEMTYPE_WB; wrmsr_smp(MSR_MTRRfix64K_00000, u.val); u.val = 0; - for (i = 0; i < 8; ++i) - if (RamSize >= 65536 * 8 + 16384 * (i + 1)) + for (i = 0; i < 8; i++) + if (RamSize >= 0x80000 + 16384 * (i + 1)) u.valb[i] = MTRR_MEMTYPE_WB; wrmsr_smp(MSR_MTRRfix16K_80000, u.val); - wrmsr_smp(MSR_MTRRfix16K_A0000, 0); - wrmsr_smp(MSR_MTRRfix4K_C0000, 0); - wrmsr_smp(MSR_MTRRfix4K_C8000, 0); - wrmsr_smp(MSR_MTRRfix4K_D0000, 0); - wrmsr_smp(MSR_MTRRfix4K_D8000, 0); - wrmsr_smp(MSR_MTRRfix4K_E0000, 0); - wrmsr_smp(MSR_MTRRfix4K_E8000, 0); - wrmsr_smp(MSR_MTRRfix4K_F0000, 0); - wrmsr_smp(MSR_MTRRfix4K_F8000, 0); + wrmsr_smp(MSR_MTRRfix16K_A0000, 0); // 0xA0000-0xC0000 is uncached + int j; + for (j = 0; j < 8; j++) { + u.val = 0; + for (i = 0; i < 8; i++) + if (RamSize >= 0xC0000 + j * 0x8000 + 4096 * (i + 1)) + u.valb[i] = MTRR_MEMTYPE_WP; + wrmsr_smp(MSR_MTRRfix4K_C0000 + j, u.val); + } - // Variable MTRRs + // Set variable MTRRs int phys_bits = 36; cpuid(0x80000000u, &eax, &ebx, &ecx, &edx); if (eax >= 0x80000008) { @@ -88,6 +88,10 @@ void mtrr_setup(void) phys_bits = eax & 0xff; } u64 phys_mask = ((1ull << phys_bits) - 1); + for (i=0; i<vcnt; i++) { + wrmsr_smp(MTRRphysBase_MSR(i), 0); + wrmsr_smp(MTRRphysMask_MSR(i), 0); + } /* Mark 3.5-4GB as UC, anything not specified defaults to WB */ wrmsr_smp(MTRRphysBase_MSR(0), BUILD_MAX_HIGHMEM | MTRR_MEMTYPE_UC); wrmsr_smp(MTRRphysMask_MSR(0)

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS