Date: Sat, 29 Jul 2006 19:31:38 +0200 From: Adrian Steinmann <ast@webgroup.ch> To: John Baldwin <john@baldwin.cx> Cc: Danny Braniss <danny@cs.huji.ac.il>, freebsd-embedded@freebsd.org, Steven McCoy <fnjordy@gmail.com> Subject: Re: pxeboot PC Engines WRAP Message-ID: <20060729173137.GA89529@webgroup.ch> In-Reply-To: <200607281236.54468.john@baldwin.cx> References: <856cdecb0607270534m34d9b4e3g4ee2714e18fcaeb7@mail.gmail.com> <20060728152206.GA29095@webgroup.ch> <200607281236.54468.john@baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 28, 2006 at 12:36:54PM -0400, John Baldwin wrote: > This is because the BIOS you are talking to here is trying to enter > protected mode on its own, which simply does not play well with VM86 at all. > It's not something you are going to "fix" in VM86 unless you change BTX > drastically to pop back into real mode to call the BIOS and handle IRQs > rather than using vm86 mode. PC-Engines says that only the int 15, function 87 goes back into protected mode, and that seems to be trapped in boot/i386/btx/btx/btx.S line 609 so the FreeBSD BTX should cover that case. Or am I misunderstanding something here? The disassembled code you mention: > 00000000 660F01975200 o32 lgdt [bx+0x52] > 00000006 0F20C0 mov eax,cr0 > 00000009 0C01 or al,0x1 > 0000000B 0F22C0 mov cr0,eax > 0000000E 66FFAF6A00 jmp dword far [bx+0x6a] > 00000013 66B810008ED0 mov eax,0xd08e0010 > 00000019 89EC mov sp,bp > 0000001B 8ED8 mov ds,ax > 0000001D 8EC0 mov es,ax > 0000001F 8E db 0x8E seems to indeed stem from http://www.pcengines.ch/tb13.zip INT1X.8 where the "Int 15, AH=87: block move" is handled in "unreal mode", as described in http://www.pcengines.ch/tb13.pdf. So would that mean that BTX didn't trap that or something else was amiss before? Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060729173137.GA89529>