[GSoC - x86_64] Console / serial communication

[Chris Johns]

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.

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

Will a text based video console be supported?

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

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