pxeboot PC Engines WRAP

Adrian Steinmann ast at webgroup.ch
Sat Jul 29 17:33:34 UTC 2006


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


More information about the freebsd-embedded mailing list