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

[Rob Clark]

On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 10/12/2017 04:28 PM, Rob Clark wrote:
>> 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.
>
> Your assumption is illegal:
>
> If no terminal emulation is used don't expect any reply unless the user
> (or the control program at the other end of the line) is typing.
> Typically there is not even flow control on the serial connection.
>
> Only if a terminal emulation is active you may be able to determine the
> console size by putting the cursor into the lower right corner. Then
> send ESC[6n. An ANSI terminal will respond by ESC[n;mR, where n is the
> row and m is the column.

I think I'm ok with the requirement of a terminal emulator, at least
for sane default behavior.. things aren't really going to work without
a terminal emulator anyways.  You aren't going to be able to query the
terminal size, and you are going to see a whole lot of jibberish when
grub/shell/etc attempt to set the cursor position and set attributes.

We can make something like efiout=serial just force serial, term
emulator or not.  A sane default behavior doesn't have to be exclusive
to catering to someone's crazy oddball setup.  People with oddball
setups can set an env var.

>
>>
>> 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.
>>
>
> A bit off-topic:
> My horror is 4k resolution terminal mode with letters so small that you
> cannot read them without magnifying glasses. For grub 80x25 blown up to
> screen size is fully sufficient. I never had more than 5 lines to choose
> from.

yeah, but scaling up isn't going to be what happens ;-)

and 80x25 is kinda sub-optimal when you need to edit a kernel cmdline

BR,
-R