Re: about loader & console

Hi Toomas,

thank you very much for telling us your plans for the FreeBSD boot system. I looked a while ago at the illumos and SmartOS boot process myself and found it more appealing compared to what we have at FreeBSD right now.

I had a look at the source repositories and saw that they have something like a frame buffer at the early start of the operating system and this made them able to put graphics at the early boot stage. I made a very basic plan to adapt those changes to FreeBSD, but my knowledge in the corner of the boot process was to limited, to say at least.

Thanks for stepping up on this…

Gordon

PS: You may want to submit your e-mail to the FreeBSD quarterly status report.

On Mon, Mar 02, 2020 at 10:47:41AM +0200, Toomas Soome wrote:
> Hi!
> 
> I have been busy with other bits for some time, but now back to poking some bits.
> 
> What we have now (on current):
> 
> x86: 
> 
> vidconsole on BIOS systems. Text mode, the screen is managed by teken terminal emulator, we “draw” on vga text buffer. 
> comconsole: serial port driver shared by BIOS and UEFI mode.
> efi: Text mode, console “device” which can have gfx display, serial port or both connected as back end device, connection is done by the firmware. We write by using UEFI Simple Text Output Protocol. See also ConOut UEFI variable.
> 
> To manage the screen, the efi console also defaults to use teken terminal emulator, however, if the serial port is multiplexed to ConOut, we can not have “our” terminal emulator to draw the screen, as that would distort the serial console. And worse, at least some UEFI firmware implementations do not pass ESC code via simple text output protocol, causing the console being filled by broken CSI sequences.
> 
> arm: efi console is the same state as in x86, no serial driver to provide comconsole, the serial console is only available via redirection from firmware.
> 
> I actually do have basic comconsole implementation via UEFI Serial IO protocol, but unfortunately, the UEFI API does not provide good way to identify serial ports, we only do get array of handles of serial ports. The SIO handle is opaque.
> 
> What we want to get: 
> 
> We would like to have framebuffer console (at least on efi), where we do “draw” the glyphs and do not use simple text output protocol for console output. 
> 
> Why: this will allow us to provide more consistent screen output, draw images and we would not depend on simple text output any more.
> 
> UEFI gfx console is already built on framebuffer - on physical systems we do get FB address, size and few other attributes, and after passing this all to kernel, the kernel will draw the conole, as Simple Text Output Protocol is not available once we start the kernel.
> 
> To get this done, we need console font. To be able to output text, I do plan to build into loader binary the limited set (ascii + box drawing) 8x16 font, and once we have gained access to the disk, we will load best matching font for the current resolution. This makes first problem - we have font files in usr/share/vt/fonts, but there are too many options where the /usr might be, so we would need to copy some of those fonts to /boot tree. I’d use terminus fonts there for consistency (glyph range) for various glyph sizes. And the kernel default built in font is 8x16 terminus.
> 
> With ability to draw our glyphs, we can build console device list in console variable, just as it is currently done with x86 BIOS version. If we should still use the console name “efi” for FB console or leave efi for pure Simple Text Output based console, is something we would need to decide.
> 
> Once we can draw the FB console on UEFI, it is not too hard to add the implementation for BIOS VBE interface.
> 
> To sum it all up:
> 
> 0. my assumption is/was that we do not change the name of the console driver, to keep the expected values people are used with. However, it is quite easy to introduce new console types, if needed.
> 1. We need to provide serial driver on all platforms.
> 2. Provide option to switch between “text” and gfx mode. In some systems (BIOS VGA) the gfx performance may be very low and text mode might be preferred. 
> 3. The screen updates are to be implemented via teken callback mechanism (as it is also done in kernel for that matter).
> 4. The support to display images is using pnglite (and therefore png format). Interpreters need updates to support the feature.
> 
> I actually do have the core implementation for UEFI already, but polishing it up will still get some time. Actually I am cheating there quite a bit because I have done all this work already once and now I am porting it to different terminal emulator.
> 
> I hope this writeup does give some light about what is happening in this area.
> 
> thanks,
> toomas
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

-- 
Gordon Bergling
Mobile: +49 170 23 10 948
Web: https://www.gordons-perspective.com/
Mail: gbergling_at_gmail.com

Think before you print!