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 <chr...@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 <chr...@rtems.org >> <mailto:chr...@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 >> _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
