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

[Alexander Graf]

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.

I think for multi-out we really just have to do what edk2 does and limit 
the screen size to 80x25. I guess you'd just create an iomux target 
there that would return the fake size info?


Alex