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

[Rob Clark]

On Thu, Oct 12, 2017 at 9:44 AM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> From: Rob Clark <robdclark at gmail.com>
>> Date: Thu, 12 Oct 2017 08:48:39 -0400
>>
>> 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.
>
> Seconded.  In many cases I'd want to continue using serial as the
> console even if a display is connected.

Sure, and this patch isn't preventing that.

>> >> 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) ;-)
>
> Display detection will always be somewhat fragile.  The old Sun
> workstations used to base the decision on whether a keyboard was
> connected.  With no keyboard detected the output would always go to
> serial.

s/always/sometimes/

For analog outputs it can be more tricky.  For any display technology
from this century, it isn't really that hard.

Boards that cannot reliably detect whether a display is connected
probably don't want to set efiout.

>> > 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).
>
> From my point of view a bootloader should only do "simple stuff".  All
> this fancy display stuff makes a serial console much harder to use.

Sure, but people who tinker with u-boot and low level stuff aren't the
only target audience here.

This patch provides a (completely optional) way to provide a sane
default that doesn't require a serial cable, yet still works with one
if you don't have a display connected.. some people expect to be able
to just plug in display + keyboard + power and get to a grub boot
menu, just like you would on an x86/uefi system.

BR,
-R