On Thu, Oct 12, 2017 at 9:44 AM, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Rob Clark robdclark@gmail.com Date: Thu, 12 Oct 2017 08:48:39 -0400
On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf agraf@suse.de wrote:
On 12.10.17 00:07, Rob Clark wrote:
On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf agraf@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@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.
Seconded. In many cases I'd want to continue using serial as the console even if a display is connected.
Sure, and this patch isn't preventing that.
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) ;-)
Display detection will always be somewhat fragile. The old Sun workstations used to base the decision on whether a keyboard was connected. With no keyboard detected the output would always go to serial.
s/always/sometimes/
For analog outputs it can be more tricky. For any display technology from this century, it isn't really that hard.
Boards that cannot reliably detect whether a display is connected probably don't want to set efiout.
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).
From my point of view a bootloader should only do "simple stuff". All this fancy display stuff makes a serial console much harder to use.
Sure, but people who tinker with u-boot and low level stuff aren't the only target audience here.
This patch provides a (completely optional) way to provide a sane default that doesn't require a serial cable, yet still works with one if you don't have a display connected.. some people expect to be able to just plug in display + keyboard + power and get to a grub boot menu, just like you would on an x86/uefi system.
BR, -R