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

[Rob Clark]

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.

That would also let us pick the minimum of each dimension to report to
the payload, which is less horrible than just having an 80x25 grub
menu on your 4k screen.  And if no serial attached, then we can use
the full screen.

BR,
-R