[GSoC - x86_64] Console / serial communication

[Amaan Cheval]

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:
>> Hi!
>>
>> In the last thread about using FreeBSD's bootloader to bring UEFI
>> support to our port, Chris said this:
>>
>>> It has been a couple of years but I think FreeBSD contains some of the Intel
>>> code to interface to UEFI and via this you can get to the UEFI console. This
>>> should be easy but it comes with a side effect.
>>>
>>> UEFI boots in graphics mode and so it's console on a PC is a slow scroll one. On
>>> boards like a Minnow using the UEFI console has the advantage of being able to
>>> support any redirection UEFI has enabled such as a serial port. The disadvantage
>>> of this is performance and overhead. In time this may be a boot option.
>>>
>>> What I am not sure is the boundary between UEFI and the kernel and what is
>>> enabled or available when the kernel is loaded.
>>
>> Source: https://lists.rtems.org/pipermail/devel/2018-June/022136.html
>>
>> According to my understanding, the efi_console is not available to the
>> kernel - only to the loader.efi (the PE image of the bootloader, which
>> eventually loads the ELF kernel).
>
> OK.
>
>> (In brief, my reasoning for this belief is that efi_console is defined
>> and initialized only through the bootloader code (in stand/efi/main.c,
>> when cons_probe is called). The efi_console relies on UEFI's
>> BootServices, which won't be accessible when the ELF kernel is loaded,
>> because ExitBootServices() is called before loading the kernel (as
>> part of bi_load).)
>
> I suspect I was looking at a direct entry to RTEMS from EFI rather than the
> better way of using loader.efi.
>
>> Given that information, it makes more sense to actually port a console
>> driver that the ELF kernel uses, not that the bootloader uses.
>
> Yes this makes sense. Thank for you for researching this and resolving it.

Sure thing!

>
>>
>> I'll look into how FreeBSD implements their UART console
>> (https://github.com/freebsd/freebsd/blob/1cfbfa1fae9926303f69532a97a5a766fa672582/sys/dev/uart/uart_tty.c),
>> and look into possibly reusing RTEMS' existing drivers for UART
>> (NS16550?) as applicable.
>
> There are working drivers for this device in RTEMS already (libchip) and the
> i386 BSP has some support.

Ah, yeah, that's why I mentioned it - I'm completely unfamiliar with
these drivers, so I don't really have a way of picking _the_ one to
implement first, for our minimal BSP.

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

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

I only picked UART because it seems to be what's used when we use
QEMU's "-serial stdio" flags.

>
>>
>> I'm not sure I know enough about serial programming _yet_, so do let
>> me know if you think you have any resources that would be useful or if
>> you'd like to fine-tune my plan!
>
> I suggest you review the ARM and SPARC bsps and follow those models. The i386
> has support for PCI based UARTS which this BSP will need to support.

Will do!

>
>>
>> P.S. - Since we last disussed it, the context initialization and
>> switching are working, and the port does now make it to the user's
>> Init task! :D
>>
>
> Awesome.
>
> Chris