[GSoC - x86_64] Console / serial communication

[Amaan Cheval]

On Tue, Jun 26, 2018 at 12:15 PM, Chris Johns <chrisj at rtems.org> wrote:
> On 26/06/2018 14:29, Amaan Cheval wrote:
>> On Tue, Jun 26, 2018 at 4:10 AM, Chris Johns <chrisj at rtems.org> wrote:
>>> On 25/06/2018 21:40, Amaan Cheval wrote:
>>>
>>> Will a text based video console be supported?
>>
>> As above, I can't say :P
>> The only guiding factor I have for GSoC is to do the _minimal_ needed
>> port first, because the project is quite wide - once _all_ the basics
>> (clock next, some of IRQ, maybe ACPI) are done, we can look into what
>> to improve further if we have the time.
>
> Sure this is best approach.
>
>> Given the possibility that we may not be able to add more than one
>> console this summer, which would we want the most? Which driver? (I'm
>> trying to do my own research too, of course, but if there's an obvious
>> one you can think of, let me know!)
>
> Lets see how the serial UART goes first.

Cool.

Just as a note for the future: loader.efi does seem to set some EFI
framebuffer (efifb) work up - I suspect it's similar to how some
bootinfo is passed to the kernel
(http://fxr.watson.org/fxr/source/i386/include/bootinfo.h?v=FREEBSD11#L48).
This is worth investigating later for:
- Seeing how the ELF kernel detects memory info
- How to access the UEFI UGA/GOP graphics APIs
- Accessing UEFI's RuntimeServices (most of them seem unnecessary, but
ResetSystem may be usefu in lieu of ACPI work)

For now I'm just focusing on the UART work, and then hopefully we can
get hello.exe passing and get the minimal BSP upstreamed after major
cleanups (- if the UART work takes too long, I believe we ought to
clean up and merge _some_ before phase 2 regardless).

>
>>
>> I only picked UART because it seems to be what's used when we use
>> QEMU's "-serial stdio" flags.
>>
>
> This is a good option and I often use it on a PC.
>
> Chris