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