Re: [NILO-discuss] Zen and the art of running in real mode

[H. P. A. <hp...@zy...>]

Michael Brown wrote:
> 
> Even setting up descriptors to cover the high memory used by a card 
> doesn't help us in the case of being called in V86 mode, in which case we 
> really are constrained to base memory only.
> 

Indeed.  I don't see any reason to believe this is a permitted use of 
these interfaces, though, on the other hand it clearly works with stock 
PXE systems on FreeBSD.  I wonder if they require the INT 15h mover API 
to exist.

> 
> I think that providing a compile-time option to generate 16-bit code
> designed to run in real mode (as I described previously) is viable.  
> There are restrictions: most significantly, drivers that use memory-mapped
> I/O (readX/writeX) rather than inX/outX probably won't work.  Some drivers
> (e.g. prism2_pci) can probably be modified to use inX/outX.  Some drivers
> (e.g. depca.c) seem to use readX/writeX to access normal in-memory data
> structures; I'm not quite sure what's going on here.
> 

Well, you could use either the INT 15h AH=87h API, or some clever 
descriptor mangling (for the case of 16-bit PM) to support those operations.

> Within these restrictions, it should be perfectly possible to have a 
> compile-time option to generate 16-bit real-mode code.
> 
> This code would then run properly in V86 mode, since it would never 
> attempt a mode transition.
> 
> The PXE protected-mode entry point is actually a hack designed to allow 
> 16-bit real-mode code to be called in protected mode.  Code capable of 
> being run in real mode will work when called via the protected-mode entry 
> point, provided that we load %ds etc from the !PXE structure on entry.  
> Since our code is 32-bit code coerced into 16-bit opcodes using 
> .code16gcc, we're already using %esp as the stack register, so supporting 
> the EntryPointESP is a no-op, and we just need some glue logic to zero the 
> high word of %esp in order to support the (mandatory) EntryPointSP with 
> the same code.

Actually, you'll have to reload the %ss selector; the default sizes of 
stack operations are dependent on the stack segment descriptor.  The 
easiest way to deal with this is to switch stacks:

EntryPointESP:
	pushl %ds
	pushl %es
	movw %cs:DataSegment,%ds
	movw DataSegment,%es
	movl %esp,SavedStack
	movw %ss,SavedStack+4
	lssl MyStack,%esp
	call common_code
	lssl SavedStack,%esp
	popl %es
	popl %ds
	ret

> It's worth noting that the specification is incomplete with regard to 
> protected-mode operation.  In particular, it defines a "StatusCallout" 
> field that must contain a far pointer to a routine to be used for printing 
> status messages when in protected-mode (since BIOS interrupts will work 
> only in real mode), but nothing I can find anywhere in the document 
> describes what the parameters, actions or return value of this 
> StatusCallout routine actually are.

I don't think it has any; it's main purpose seems to be to suppress the 
default "print dots and watch for the [Esc] key" behaviour of newer PXE 
ROMs.

> Since protected-mode operation is so poorly-defined, I strongly suspect 
> that no existing programs ever attempt to call a PXE stack in protected 
> mode.

People *do* call the UNDI stack in protected mode.  I am not sure if 
there is another entry point to the UNDI stack, or how widely it's used.

> We could always cheat and simply refuse to print status messages to the 
> video console unless StatusCallout==0 (indicating "use internal printing 
> routines").

That would probably be as good a cheat as any.

> I appreciate that all this is quite involved, so I'm going to attempt a 
> brief summary:
> 
> o  We can support genuine real-mode operation, V86-mode operation and the 
>    PXE-specified 16-bit protected-mode operation.
> 
> o  Doing this gives us compatibility with FreeBSD and with any 
>    as-yet-undiscovered program that uses the PM entry point.
> 
> o  Not all drivers will work when used in this way.  This is a fundamental 
>    limitation and cannot be worked around.
> 
> o  We can do this simultaneously with supporting our normal 32-bit 
>    protected-mode operation.  (Simultaneously in the sense of "with the 
>    same source code, using compile-time options", rather than "with the 
>    same binary ROM image").

The good part of it is that it lets us be a "full-featured" PXE stack, 
as opposed to a perennial second-class citizen.  Not that the 
first-class citizens aren't shock-full of bugs and have tons of missing 
features (like menu support, which is broken in a fair number of the PXE 
stacks I've tried, just like CD-ROM booting menu support is.)

	-hpa