From owner-freebsd-current@freebsd.org Wed Mar 4 10:40:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1D40E26B35E for ; Wed, 4 Mar 2020 10:40:06 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48XVkr2ryhz4DsS for ; Wed, 4 Mar 2020 10:40:04 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id t11so1758594wrw.5 for ; Wed, 04 Mar 2020 02:40:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=8oOQvFDfYglAJlDVxRA7AGu4CARIBxEcL21ZqcNOIDk=; b=mHPTrGeIZoQyH0euryhG/Nn405nE/SQD2SX9OY3xKA4uSyqQIJcOfMQTq11/w1ESRo NvHDu1dPiHATWyrs2ByJQCdKREbK9UEpqiDk8bRgDw7n2T9mghVNt51J0FoakTNdbkYB d9MAcZexNQOkD9SAFwboFcan/t8bL2eZzwZBHt77pGJUcCp0p2pDFGZfoAEL9KuwLTfR 11DW7Z3MRoaECKRDTb4iACfBa7i6ziSN6wgQ3h2o3DFTSSblA17YfS0x4jAr1Ujn90or EBZubmYV4eevyw3ES8tu0rw+Y8FUk9jsCdcS8wX9NNaPJQE9ZLk8clCUy4qRQXl/xZiS p7JA== X-Gm-Message-State: ANhLgQ0or749iV4kO2EToHyQIsiiOJgq9eAYxGE1AR4weeaw2sNsl4Cc PWHUS5olSZoawCd2qybO+5M/8rCQKiw= X-Google-Smtp-Source: ADFU+vtv4miXU/FNKe6OvJQXLXDSCxsjQhSVSuJ4KwJxybTlB/ffhhPizaezvzYl1o8TDn6wA/dwbQ== X-Received: by 2002:adf:dccb:: with SMTP id x11mr3439343wrm.214.1583318401819; Wed, 04 Mar 2020 02:40:01 -0800 (PST) Received: from lion.0xfce3.net (p4FD3AF8F.dip0.t-ipconnect.de. [79.211.175.143]) by smtp.gmail.com with ESMTPSA id y10sm3356862wma.26.2020.03.04.02.40.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2020 02:40:01 -0800 (PST) Sender: Gordon Bergling Date: Wed, 4 Mar 2020 11:40:00 +0100 From: Gordon Bergling To: Toomas Soome Cc: freebsd-current@freebsd.org Subject: Re: about loader & console Message-ID: <20200304104000.GA24526@lion.0xfce3.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 11:39AM up 6 days, 23:14, 4 users, load averages: 0.22, 0.35, 1.11 X-Rspamd-Queue-Id: 48XVkr2ryhz4DsS X-Spamd-Bar: / X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[gbergling@googlemail.com,gbergling@gmail.com]; FREEMAIL_TO(0.00)[me.com]; RECEIVED_SPAMHAUS_PBL(0.00)[143.175.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(0.00)[ip: (-9.01), ipnet: 2a00:1450::/32(-2.40), asn: 15169(-1.66), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[gbergling@googlemail.com,gbergling@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DMARC_POLICY_QUARANTINE(1.50)[googlemail.com : SPF not aligned (relaxed), DKIM not aligned (relaxed),quarantine]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 10:40:06 -0000 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Gordon Bergling Mobile: +49 170 23 10 948 Web: https://www.gordons-perspective.com/ Mail: gbergling@gmail.com Think before you print!