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

[Heinrich Schuchardt]

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.

So I would not see what should be so special about Shell.efi.

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.

Best regards

Heinrich