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
