On Thu, Nov 13, 2014 at 7:27 PM, Pavel Pisa <p...@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 <dolez...@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 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
