[PATCH] do_it: Create build directory and its parents for Nano-X and future x86 VBE Linux support

[Gedare Bloom]

On Sun, Oct 19, 2014 at 7:48 AM, Pavel Pisa <pisa at control.felk.cvut.cz> wrote:
> Hello Gedare and Joel,
>
> On Friday 17 of October 2014 10:17:24 Jan Dolezal wrote:
>> prevents possible mkdir and cd error when parents of build
>> directory are missing
>> ---
>>  do_it | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/do_it b/do_it
>
> please push Jan Dolezals's patch to
>
>   http://git.rtems.org/rtems-graphics-toolkit/
>
> it corrects Nano-X build.
>
Thanks Pavel. I didn't see it among the warning patches.

> Then there is quite large amount of patches for RTEM which
> Jan Dolezal works on to provide PC VESA BIOS Extension support
> for RTEMS. Mode selection is planned only during RTEMS startup
> before interrupts are enabled for now.
>
> Runtime VESA BIOS calls are extremely problematic.
>
>  - there is defined protected VBE 3.0 entry point, but it is not present
>    in QEMU VESA BIOS and on the most of the tested cards. Even if present
>    on some cards, it seems to be broken according to our attempts to use it.
>    This solution was my initial idea, but proved to be unusable
>    and cost enormous time.
>  - switching to real mode is no option after startup for RTOS - to work
>    at least potentially reliably requires to block all interrupts
>    on PIC/APIC/LAPIC level
>  - VM86 mode would be doable but requires significant additional
>    complexity and overhead for task switch or use separate TSS
>    nonsense for each task
>  - the last analyzed interresting solution is to include x86 instruction
>    set interpreter in RTEMS which would allow to run BIOS x86
>    real code sandboxed and with additional memory ranges protection
>    and with minimal impact on other RT code running in parallel.
>    This would be nice to do, allows to use x86 PCI VESA BIOS cards
>    on other PCI enabled architectures but it is above our current
>    capabilities and time constraints. On the other hand we can provide
>    example from NOVA microkernel which achieved and uses this goal.
>
This last option seems quite interesting. Can you link to the example
or any doc on how it is done?

> So the current goal is mode setup during RTEMS startup but real mode
> functions calls done from protected C code to achieve readability
> and flexibility. This is approach which Grub and many other systems
> and loaders uses so it should be most reliable and tested on real
> hardware.
>
> I am bringing actual Jan Dolezal's work to your attention now
> to do get some initial suggestions, then I expect that patches
> would be be send for review to RTEMS mailinglist.
> Probably during this month.
>
Great.

> The complete work
>
>   https://github.com/dolezaljan/rtems/commits/master
>
> The key changes for discussion and possible correction
> of work direction
>
>  - added header for VESA BIOS Extension
>    prepared from scratch to ensure clean license for RTEMS
>
>  - GDT entries manipulation functions +
>    GDT entries information getting functions + ...
>    GDT extension to more entries and changes in RTEMS
>    global GDT manipulation functions to allow setup
>    entries required for switching to real mode
>    These changes are in RTEMS x86 critical shared
>    code, so review by more people is needed
>
Joel is primary x86 maintainer around here. He should comment when
they come through.

>  - actual VESA BIOS calls and mode witching
>    this is not so critical, because it is optional
>    and does not influence code which does not use
>    new graphics features
>
> I would be happy if you help with review process.
> Do you want to have patch series on GitHub first
> or should be patches sent to RTEMS devel directly?
>
They probably won't get looked at on GitHub unless you ask someone
directly to have a look and provide the exact link.

-Gedare

> Best wishes,
>
>                  Pavel