Am 12.10.2017 um 18:00 schrieb Mark Kettenis <mark.kette...@xs4all.nl>:
>> From: Rob Clark <robdcl...@gmail.com> >> Date: Thu, 12 Oct 2017 10:28:43 -0400 >> >>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <ag...@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.g...@gmx.de> >>>> wrote: >>>>> >>>>> >>>>>> On 10/12/2017 02:48 PM, Rob Clark wrote: >>>>>> >>>>>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf <ag...@suse.de> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 12.10.17 00:07, Rob Clark wrote: >>>>>>>> >>>>>>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf <ag...@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 <robdcl...@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. > > By spitting out random control characters and hope they match the > terminal emulation on the other end? Sounds like a bad idea to me to > do that by default. We actually do exactly that today already :). > > Or would you only do it for EFI payload that uses more than just the > EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL? That might be acceptable. Simply only to the first call that wants to know the screen size ;) Alex > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot