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

[Marty C. <md...@en...>]

On Mar 8, 2005, at 10:00 AM, Michael Brown wrote:
> Too many e-mail threads for me, so I've grouped everything I'm 
> replying to
> in one message.  There's an executive summary at the end.

Thanks for this.  I find it helpful and illuminating.

> Currently I know of no clients that attempt to use the protected-mode
> entry point, and only FreeBSD that uses the real-mode entry point in 
> V86
> mode.

I think the FreeBSD people might well fix this (assuming it wouldn't 
break other stuff) if they were informed of what to do.  I know this 
came up on the Etherboot list.  Do you recall if any FreeBSD folks 
spoke up?

> 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.

This must refer to the FreeBSD folks again.  I wonder if they made 
whatever the proper call would be (assuming this way of calling is a 
bug on their part) if it is likely to break anything for them.  Any 
idea?

> 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.

Drivers we can fix.  Older ones are probably simpler anyway, and newer 
ones probably use inX/outX already.

> 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.

Let's hope the gcc compiler continues to support this.  I guess there's 
no other really viable option at the moment.

> 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.

If you say so :)  Sounds like a somewhat fragile hack, but sometimes 
that's all we've got that gets the job done.

> 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.

Are things that do this "broken" or "violating the spec" somehow?

What I'm getting at, is how hard we should try to get people to fix 
their code to work with ours?  I can already hear comments like "well 
it works with my Intel boot ROM on my eepro100... and also with my 
3C905 MBA Boot ROM..."   It would be nice to have some good reasons why 
they should fix it.

The pain of supporting undesirable behaviors is, err, tedious at times.

> o  Not all drivers will work when used in this way.  This is a 
> fundamental
>    limitation and cannot be worked around.

This makes sense, and hopefully we can document where this is likely 
(or known) to occur.

> 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").

Are we really talking about two different parts/products here?  Are we 
talking about one that works with most loaders, and another that works 
with a few broken legacy loaders that didn't follow the spec very well?

If that is what we have to face, then so be it.  I just want to know 
how to explain to people on rom-o-matic.net and in our documentation 
which ROM images they probably want.

This may only be something we can figure out empirically, like so many 
things.

It's unsatisfying to have to have the compile-time option, such that 
there will be NILO ROMs out there that will be more compatible with 
legacy loaders, and other NILO ROMs that will be required to use newer 
cards.

So does this mean that FreeBSD attempting to use a gigabit card may 
simply fail?
That would suck.  Of course if this happens we could explain to the 
FreeBSD people why this is, and they could fix their code.  It would be 
nice if the fix also worked for the legacy ROMs as well.

As ugly as this may be at a low-level, I think it's worth the attempt 
to make a free PXE stack, and I have a feeling we'll learn a lot from 
the experience.

Sounds like it's time to import some code into that lonely nilo cvs 
directory, eh, Michael? :)

Marty