[PATCH 4/6] i386/shared/int16: real mode interrupt interface

[Pavel Pisa]

Hello Gedare and others,

On Wednesday 12 of November 2014 16:54:07 Gedare Bloom wrote:
> On Wed, Nov 12, 2014 at 10:07 AM, Jan Dolezal <dolezj21 at fel.cvut.cz> wrote:
> > ---
> >  c/src/lib/libbsp/i386/pc386/Makefile.am    |   2 +
> >  c/src/lib/libbsp/i386/pc386/preinstall.am  |   4 +
> >  c/src/lib/libbsp/i386/shared/int16/int16.c | 397
> > +++++++++++++++++++++++++++++ c/src/lib/libbsp/i386/shared/int16/int16.h
> > |  93 +++++++
> >  4 files changed, 496 insertions(+)
> >  create mode 100644 c/src/lib/libbsp/i386/shared/int16/int16.c
> >  create mode 100644 c/src/lib/libbsp/i386/shared/int16/int16.h
>
> These new files should probably go under i386/shared/irq  ?

The right location for this code is questionable and I would
personally prefer to keep it well separated from x86 protected
mode runtime support.

It is highly special. It allows to switch CPU to real mode
and then call BIOS interrupt and then switch back to protected
mode. The actual implementation is limited. The BIOS calls
are allowed only during system initialization before first
interrupt source (i.e. tick timer) is enabled.
This is enough for video mode selection during RTEMS
startup with mode/resolution selected as command line parameter.

It would be quite usesfull (but dangerous) to support BIOS
calls during real time executive and applications running
state. There are next theoretical options to consider

 - there is VBE 3 documented VESA BIOS only solution
   to copy and patch VESA BIOS to be usable directly
   from 16-bit protected mode descriptors. It was my initial
   idea and Jan Dolezal has spent horrible amount of time
   to try this but QEMU does not include BIOS with this functionality
   and these little card which has been found to declare this
   support present has proven to be broken and we have even
   found similar conclusion about no way in this direction
   published by others. Even if the BIOS supports protected mode
   calls then it has to run with multiple selectors and this
   would require significant overhead addition to RTEMS i386
   context switch and interrupt code to preserve descriptors
   for task interrupted in 16-bit protected BIOS code

 - use of VM86 support of i386. This allows to run real mode
   code in the firs 1MB of linear address space mapped
   to physical address space by page tables. To support that
   mode requires to add some code to interrupt and context
   switch but overhead cab be probably limited compared
   to previous option.

 - use of x86 code interpreter. Complex solution which
   we have no resources to implement with correct license
   now. But this would probably fit best requirement
   of safety concerns of RTEMS grade control system.
   That solution would cause no additional overhead
   code inclusion in RTEMS context switch and allows
   to monitor and limit memory accesses from BIOS code.
   It could be used for running addon cards BIOS on non x86
   architectures as well .... But ...

Generally, I suggest to keep this stuff configurable
and not to mix it with core and allways used i386 CPU support.

The name "int16" is questionable, may it be misleading.
We spoke about "i386_rmcall" prefix for real mode calls.
It could be even "bioscall" or "biosint" but in the fact
this shared part of the code has no direct connection
to BIOS. It is generic support to call real mode interrupt.

x86 graphics support is generally compromise driven solution.
But if there are cases where graphics is desired to work
on RTEMS (even on embedded non x86 targets) then there
is significant need to support graphic on pc386 to run
test builds of system and graphics framework on x86 (even in QEMU)
because native architecture development and testing is faster
and x86 is common base. And there is no other reasonably
complex solution on x86 to support more graphics cards
hardware variants than VESA BIOS. I.e. native drivers would be nice
dream but there is not enough power in RTEMS community to implement
it and maintain it for more boards and it is not RTEMS focus anyway.
As an option, the cirrus driver can be used for pure emulated
environment but this is far from use on any real hardware.

Best wishes,

               Pavel