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

[Alexander Graf]

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.

Not sure that's terribly helpful. Most of these servers have built-in 
BMC chips that just go to a fake video console, so they always get EDID 
information, but that doesn't mean that it's sensible for what the user 
ends up seeing.

I think what happens is that in most cases they just assume you have a 
80x25 console :).

> 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).

Yes, and on basically all arm servers what you see happening is that 
grub gets squeezed into 80x25 for the text output. For graphical output, 
at least SUSE usually just defaults to gfxterm which directly drives GOP.


Alex