[GSoC - x86_64] Console / serial communication

[Amaan Cheval]

As it turns out, yes, the UEFI firmware and FreeBSD's loader.efi _do_
also communicate with the COM ports (serial/UART), leading to that
output. Setting console="nullconsole" in loader.conf silences _some_
of the loader output, but not the earlier boot1.efi output (the EFI
image that reads loader.conf and loads loader.efi).
https://i.imgur.com/oINwNhO.png

I'll bench this for now since I don't think it'll be a problem - I
believe our tests can ignore extra output outside of the actual test
region, yes?

On Fri, Jun 29, 2018 at 6:09 AM, Chris Johns <chrisj at rtems.org> wrote:
> On 28/06/2018 16:40, Amaan Cheval wrote:
>> I believe it isn't, but QEMU is being "helpful" and multiplexing the COM1
>> (RTEMS) stream with the VGA/VBE/etc. text mode streams.
>
> OK.
>
>>
>> I'm looking into how to either:
>> - Make QEMU only print COM1 to stdio
>> - Or, how to quiet FreeBSD through configuration (loader.conf lets us set
>> console to comconsole, vidconsole, nullconsole, and efi)
>>
>> I'll let y'all know as things progress!
>
> Thanks.
>
>>
>> Would it be a blocker if we couldn't quiet the UEFI firmware and loader.efi?
>>
>
> Not at all. I was just curious and hopeful it just worked.
>
> Chris
>
>> On Thu, Jun 28, 2018, 3:39 AM Chris Johns <chrisj at rtems.org
>> <mailto:chrisj at rtems.org>> wrote:
>>
>>     On 28/06/2018 00:37, Amaan Cheval wrote:
>>     > Since we skipped our meeting today, here's a quick screengrab of UART
>>     > working with -serial stdio on QEMU (just inb/outb instructions
>>     > directly, without termios or ns16550):
>>     > https://i.imgur.com/tumtD3Z.png
>>
>>     Nice. Is the loader.efi also using the UART?
>>
>>     Chris
>>