March 2010 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel
by Kevin O'Connor July 12, 2011

July 12, 2011

On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote: > > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > >> Should a kernel fail during boot, I'd suspect it doesn't like one of > >> the apm/pcibios callbacks, or it doesn't like one of the > >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code > >> (see http://seabios.org/Download ) and increasing the debugging by > >> modifying src/config.h. Specifically, you could increase > >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to > >> 1. Also, you could try disabling some of the features to see if that > >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / > >> CONFIG_MPTABLE). > > > > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the > image boots up fine. Gleb, have you seen this thread? Some of the recent changes to smbios that look like possible culprits are: Make SMBIOS table pass MS SVVP test Use MaxCountCPUs during building of per cpu tables. Add malloc_high/fseg() and rework bios table creation to use them. There were other changes, but the comments indicate they were only ports of changes already in bochs. I suppose it's also possible the lack of smbios is turning off some other feature in the guest (eg, acpi) that's the real culprit. -Kevin

5 10

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode
by Sebastian Herbszt May 16, 2010

May 16, 2010

I have tried SeaBIOS 0.5.1 on Bochs cvs with FreeDOS 1.0 Final boot floppy. Loading from floppy was utterly slow and then FreeDOS dumped Invalid Opcode at 0013 0000 0202 800F 01F3 20F4 10AA 10AA 109A 0000 0000 0000 00 00 Bad or missing Command Interpreter: A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FRE EDOS\FDAUTO.BAT Enter the full shell command line: Bochs log has 00477945139i[BIOS ] Booting from Floppy... 00510608951i[BIOS ] Booting from 0000:7c00 05264161428i[FDD ] controller reset in software 05445136148i[FDD ] controller reset in software 05625186768i[FDD ] controller reset in software 05803824012i[FDD ] controller reset in software 05985259728i[FDD ] controller reset in software 05985285461i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0) Same floppy and Bochs version work fine and fast with Bochs BIOS. Any clues? - Sebastian

3 14

[ANNOUNCE] SeaBIOS 0.6.0
by Kevin O'Connor March 27, 2010

March 27, 2010

I've tagged a new release of SeaBIOS. For more information on the release, please see: http://seabios.org/Releases New in this release: * USB hub support * USB drive booting support * USB keyboard auto-repeat support * USB EHCI controller support * Several improvements to compatibility of PS2 port handlers for old code * Support for qemu e820 interface * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download -Kevin

1 0

Re: [SeaBIOS] SeaBIOS 16-bit compiler
by Kevin O'Connor March 26, 2010

March 26, 2010

Hi Michal, I'm CC'ing the SeaBIOS mailing list. On Thu, Mar 25, 2010 at 06:32:50AM -0700, Michal Necasek wrote: > Have you ever looked into the possibility of using a real 16-bit > compiler for the 16-bit bits? One obvious candidate would be Open > Watcom C/C++. Microsoft Visual C++ 1.52 is also a very capable > 16-bit compiler, but probably not a real option for SeaBIOS due to > limited availability and host platform support. This has come up a couple of times in the past. One thing to note is that SeaBIOS actually has more 32bit code than it does 16bit code. Also, large portions of the code are compiled in both modes. I hear Open Watcom works well for 16bit code, but I'd guess gcc does a better job with regular 32bit code. A solution for the 16bit code wouldn't work well if it reduced the code sharing with the 32bit code. Either all the code would need to be compiled with Open Watcom or the final SeaBIOS binary would need to be a mix of gcc and Open Watcom code - both seem risky. The other difficulty with Open Watcom is its availability. It's nice to be able to compile SeaBIOS without requiring special packages. That was a big advantage for the qemu/kvm maintainers. -Kevin

3 5

Next release
by Kevin O'Connor March 21, 2010

March 21, 2010

FYI - I'm planning on tagging a new version of SeaBIOS. Given the new USB features, I think I'll call it v0.6.0. I'll probably add the tag in the next few days. In the mean time, I'm going to be running through some tests and fixing any defect I find. If you know of any issues, please report them. Thanks, -Kevin

1 0

MINIX 3.1.6 works in QEMU-0.12.3 only with KVM disabled
by Antoine Leca March 18, 2010

March 18, 2010

Hello folks, I am working on Minix, and we detected a problem which might be related with SeaBIOS. In short, Minix' boot monitor (first written in 1992, and which supports 80286 architectures), while in 16-bit real mode, uses BIOS service 15/87 to move blocks into high memory. It stopped working recently with kvm on Intel. On 03/10/2010 12:26 PM, Erik van der Kouwe wrote on kvm mailing list: >> I've submitted this bug report a week ago: >> http://sourceforge.net/tracker/?func=detail&aid=2962575&group_id=180599&ati… To which Avi Kivity wrote on 2010-03-10 13:03:25 +0200: > MINIX is using big real mode which is currently not well supported by kvm on Intel hardware: > >> (qemu) info registers >> EIP=0000f4a7 EFL=00023002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 >> ES =0000 00000000 0000ffff 0000f300 >> CS =f000 000f0000 0000ffff 0000f300 >> SS =9492 00094920 0000ffff 0000f300 >> DS =97ce 00097cec 0000ffff 0000f300 > > A ds.base of 0x97cec cannot be translated to a real mode segment. I searched the issue; if you are interested in the details, please read http://groups.google.com/group/minix3/msg/40f44df0c434cfa6 I notice it might be related to the switch from Bochs to SeaBIOS. http://bochs.sourceforge.net/cgi-bin/lxr/source/bios/rombios.c has: 3555 case 0x87: ... 3640 mov eax, cr0 3641 or al, #0x01 3642 mov cr0, eax 3643 ;; far jump to flush CPU queue after transition to prot. mode 3644 JMP_AP(0x0020, protected_mode) 3645 3646 protected_mode: 3647 ;; GDT points to valid descriptor table, now load SS, DS, ES ... 3657 rep 3658 movsw ;; move CX words from DS:SI to ES:DI 3659 3660 ;; make sure DS and ES limits are 64KB 3661 mov ax, #0x28 3662 mov ds, ax 3663 mov es, ax 3664 3665 ;; reset PG bit in CR0 ??? 3666 mov eax, cr0 3667 and al, #0xFE 3668 mov cr0, eax In SeaBIOS, the applicable code is in src/system.c, and looks like (now this is AT&T assembly): 83 static void 84 handle_1587(struct bregs *regs) .... 127 // Enable protected mode 128 " movl %%cr0, %%eax\n" 129 " orl $" __stringify(CR0_PE) ", %%eax\n" 130 " movl %%eax, %%cr0\n" 131 132 // far jump to flush CPU queue after transition to prot. mode 133 " ljmpw $(4<<3), $1f\n" 134 135 // GDT points to valid descriptor table, now load DS, ES ... 144 " rep movsw\n" 145 146 // Disable protected mode 147 " movl %%cr0, %%eax\n" 148 " andl $~" __stringify(CR0_PE) ", %%eax\n" 149 " movl %%eax, %%cr0\n" Note that while the basic scheme is the same, the "cleaning up" of lines 3660-3663 "make sure DS and ES limits are 64KB" is not present. IIUC, the virtualized CPU goes back to real mode with those segments sets as they are in protected mode, and yes with Minix boot monitor they happenned to NOT be paragraph-aligned. And aligning it kills the bug... Avi Kivity seems to think this is a possible explanation; and he does not see any harm in adding that cleaning up, while it could have the benefical property to avoid possible faults while virtualizing the CPU (which is a bit tricky with Intel hardware in real mode.) Is it possible to add such "cleaning up" to SeaBIOS too? Antoine

4 6

Re: [SeaBIOS] [Qemu-devel] Regression: more 0.12 regression (SeaBIOS related?)
by Kevin O'Connor March 15, 2010

March 15, 2010

On Mon, Mar 08, 2010 at 10:04:57AM +0800, Roy Tam wrote: > Hi all, > > I found some regression bugs that seems relate to SeaBIOS and I hope > we can add back booting with Bochs BIOS in git so that we can further > testing that the bug is in SeaBIOS or in QEMU 0.12. > Following list is the regression that I encountered and which works in 0.11.1: Thanks for the report. It would help quite a bit if you could gather some additional debugging information from SeaBIOS. The simplest way is to grab: http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100228 and replace the standard bios.bin with this file. Then launch qemu with the additional parameter "-serial file:mylog". Then forward the "mylog" file back. SeaBIOS has a wealth of debugging information that could help solve these issues. > http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip [...] > http://homepage1.nifty.com/bible/dos/fdos0138.lzh I'll take a look. -Kevin

3 16

Re: [SeaBIOS] [Bochs-developers] [Bug #2956217] INT13 AH=8 returns wrong valueswhen cylinders=1
by Sebastian Herbszt March 14, 2010

March 14, 2010

Sebastian Herbszt wrote: > The following disk description is used to trigger this bug: > ata0-master: type=disk, path=fdtest.img, mode=flat, cylinders=1, heads=150, spt=63 > > The current BIOS returns CX=0xFFFF. This value is wrong. > > rombios.c got > > nlc = nlc - 2; /* 0 based, last sector not used */ > SET_AL(0); > SET_CH(nlc & 0xff); > SET_CL(((nlc >> 2) & 0xc0) | (nlspt & 0x3f)); > SET_DH(nlh - 1); > > with BX_USE_ATADRV and without it's > > max_cylinder = hd_cylinders - 2; /* 0 based */ > SET_AL(0); > SET_CH(max_cylinder & 0xff); > SET_CL(((max_cylinder >> 2) & 0xc0) | (hd_sectors & 0x3f)); > SET_DH(hd_heads - 1); > > nlc and max_cylinder are Bit16u so substracting 2 from 1 gets us the wrong value. > > Section "INT 13 - DISK - GET DRIVE PARAMETERS (PC,XT286,CONV,PS,ESDI,SCSI)" > from Ralf Browns "Interrupt List, part 2 of 18" got > > "the maximum cylinder number reported in CX is usually two less than > the total cylinder count reported in the fixed disk parameter table > (see INT 41h,INT 46h) because early hard disks used the last cylinder > for testing purposes; however, on some Zenith machines, the maximum > cylinder number reportedly is three less than the count in the fixed > disk parameter table. > for BIOSes which reserve the last cylinder for testing purposes, the > cylinder count is automatically decremented" > > I don't think Bochs BIOS uses "the last cylinder for testing purpose" so i would suggest > decrementing by 1 not 2. This should also fix the reported problem. > > Thoughts? > > - Sebastian SeaBIOS has the same problem and similar wrong comment about last sector when decrementing the cylinder count: } else if (regs->dl < EXTSTART_CD) { // Hard drive count = GET_BDA(hdcount); nlc--; // last sector reserved } else { - Sebastian

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS error with Nextstep bootloader
by Kevin O'Connor March 14, 2010

March 14, 2010

On Mon, Feb 22, 2010 at 02:56:22AM +0000, Natalia Portillo wrote: > Ok, QEMU is absolutely unable to boot nextstep/openstep, while using > SeaBIOS. > > Changing to old Bochs BIOS, makes it work, however no video is > output (until NeXT starts using VESA). Hi Natalia, Is nextstep/openstep something that can be freely downloaded? It would help if you can extract some SeaBIOS debugging info. I've uploaded a SeaBIOS image with the debug level set to 8 and serial debugging enabled. It is at: http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100228 Can you use this image with qemu, add "-serial file:mylog" to qemu's command line, and forward the resulting "mylog" file back? Also, please include the full qemu command line that you used. Thanks, -Kevin

3 14

Re: [SeaBIOS] [coreboot] Seabios problems
by Kevin O'Connor March 14, 2010

March 14, 2010

On Thu, Jan 21, 2010 at 07:11:20PM +0100, congedete(a)voila.fr wrote: > Thanks. It applied correctly now. > > I'm able to press F12 and then I can use the keyboard to choose a kernel in grub2. > The problem is if I don't press F12, the keyboard is locked in grub2. I had to revert the patch I applied to fix the problem with your keyboard. I commited a slightly different patch to latest SeaBIOS git. Can you check if your keyboard still works? Thanks, -Kevin

1 0