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

[Gedare Bloom]

On Thu, Nov 13, 2014 at 7:27 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> 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.
>
OK thanks for the background info. Keeping it separate makes sense.
I'd prefer realmode_int or something. This should all get explained
somewhere (developer wiki, once it is up) so we don't lose track of
these issues. x86 code interpreter is an interesting project.

-Gedare

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