Hi! Quick question since the BSP guide is outdated - I see several "methods" of RTEMS' console management. The guide says to use console-termios.c (and rtems_termios_device_install) as the "new" method. https://docs.rtems.org/branches/master/bsp-howto/console.html#build-system-and-files
Most BSPs (beagle, pc386, malta) using NS16550 use legacy-console.c, though - are NS16550 and Termios mutually exclusive for now? Or is it simply that none of the old NS16550 users have been ported over to using console-termios.c as well? What would be the expectation from a new BSP? On Tue, Jun 26, 2018 at 12:42 PM, Amaan Cheval <amaan.che...@gmail.com> wrote: > On Tue, Jun 26, 2018 at 12:15 PM, Chris Johns <chr...@rtems.org> wrote: >> On 26/06/2018 14:29, Amaan Cheval wrote: >>> On Tue, Jun 26, 2018 at 4:10 AM, Chris Johns <chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
