[U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Mark Kettenis]

> From: Rob Clark <robdclark at gmail.com>
> Date: Thu, 12 Oct 2017 10:28:43 -0400
> 
> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <agraf at suse.de> wrote:
> > On 10/12/2017 03:40 PM, Rob Clark wrote:
> >>
> >> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt <xypron.glpk at gmx.de>
> >> wrote:
> >>>
> >>>
> >>> On 10/12/2017 02:48 PM, Rob Clark wrote:
> >>>>
> >>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf <agraf at suse.de> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 12.10.17 00:07, Rob Clark wrote:
> >>>>>>
> >>>>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf <agraf at suse.de>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10.10.17 14:23, Rob Clark wrote:
> >>>>>>>>
> >>>>>>>> In some cases, it is quite useful to have (for example) EFI on
> >>>>>>>> screen
> >>>>>>>> but u-boot on serial port.
> >>>>>>>>
> >>>>>>>> This adds two new optional environment variables, "efiin" and
> >>>>>>>> "efiout",
> >>>>>>>> which can be used to set EFI console input/output independently of
> >>>>>>>> u-boot's input/output.  If unset, EFI console will default to stdin/
> >>>>>>>> stdout as before.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
> >>>>>>>
> >>>>>>>
> >>>>>>> With this patch, we lose the ability to have the efi in/out go to
> >>>>>>> both
> >>>>>>> graphical and serial console, right? This is critical functionality
> >>>>>>> to
> >>>>>>> have, since we don't necessarily know which output/input a user ends
> >>>>>>> up
> >>>>>>> using.
> >>>>>>
> >>>>>>
> >>>>>> I'll think about how to support iomux.. but some things like console
> >>>>>> size are just not going to work properly there.  And as long as we fix
> >>>>>
> >>>>>
> >>>>> Yeah, those probably would need to get special cased.
> >>>>>
> >>>>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
> >>>>>> simply not set efiout var and have things working as before, so you
> >>>>>> don't loose any existing functionality (although, like I said, if the
> >>>>>> two different consoles have different sizes things aren't going to
> >>>>>> work properly for anything other than simple cases).
> >>>>>>
> >>>>>> In most cases, the display driver should be able to detect whether a
> >>>>>> display is connected.. this is what I've done on dragonboard410c, so
> >>>>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back
> >>>>>> to serial, else you get efi on screen like you would on a "real"
> >>>>>> computer.  For boards that have a display driver that isn't able to do
> >>>>>> the basic check of whether a cable is plugged in, just don't set
> >>>>>> "efiout" (or fix the display driver) ;-)
> >>>>>
> >>>>>
> >>>>> Are you sure that's what happens on a "real" computer? As far as I
> >>>>> remember from all ARM servers running edk2 based firmware that I've
> >>>>> touched so far, the default is always to display on serial *and*
> >>>>> graphical output at the same time.
> >>>>
> >>>>
> >>>> Well, I suppose some of the arm64 server vendors have done a better
> >>>> job than others on firmware.. you'd hope they would probe EDID, and
> >>>> report correct console dimensions based on display resolution, etc.
> >>>>
> >>>> Doing both serial and display works for simple stuff, but it goes
> >>>> badly once the efi payload starts trying to change the cursor position
> >>>> and write to specific parts of the screen (which both Shell.efi and
> >>>> grub try to do).
> >>>>
> >>>> BR,
> >>>> -R
> >>>>
> >>> Hello Rob,
> >>>
> >>> I do not know which program you use for connecting to your serial
> >>> console. I
> >>> use minicom which is a Debian/Ubuntu package. I had no problem using
> >>> grub,
> >>> vim, nano or any other console program.
> >>>
> >>> Minicom just provides a VT100 emulation and that is close enough to what
> >>> Linux expects.
> >>
> >> fwiw, I generally use kermit so my terminal emulator is whatever
> >> "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
> >> isn't so much the issue..
> >>
> >>> So I would not see what should be so special about Shell.efi.
> >>
> >> I'm not explaining the problem well, but you can see basically the
> >> same issue if you resize your terminal emulator to something smaller
> >> than what grub/shell/etc think you are using.
> >>
> >> I guess if they just fall back to assuming 80x25 like agraf mentioned,
> >> that would kind of work.  It just means shell or grub will only use
> >> the tiny upper-left corner of your monitor.
> >>
> >>> My U-Boot system all have video but I never have a monitor connected.
> >>>
> >>> So being able to use serial even if video is available is a necessity.
> >>
> >> If the video driver doesn't detect that it is unconnected, someone
> >> should really fix that, otherwise you'll have problems booting an
> >> image where grub tries to use gfxterm if GOP is present (but we are
> >> really getting off topic here)
> >>
> >> Either way, you still have the option of not setting efiout (or
> >> setting it to serial)
> >>
> >> But for end users (at least of boards that I care about), if they plug
> >> in a monitor they should get grub on screen.  Not everyone has a
> >> serial cable attached.
> >
> >
> > I fully agree there. The same applies the other way around too. Even if they
> > have a monitor attached, they should get grub on serial if serial is a valid
> > output :). Just attaching a monitor doesn't mean you only use that monitor
> > to control the system.
> 
> We could, I suppose, try probing the serial console's size, as an
> approximation of hotplug detect for serial.  If we timeout without
> getting a response, assume no serial console.

By spitting out random control characters and hope they match the
terminal emulation on the other end?  Sounds like a bad idea to me to
do that by default.

Or would you only do it for EFI payload that uses more than just the
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL?  That might be acceptable.