| Message ID | 20171010122309.25313-7-robdclark@gmail.com |
|---|---|
| State | Rejected, archived |
| Delegated to: | Alexander Graf |
| Headers | show |
| Series | efi_loader: patches for Shell.efi | expand |
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. Alex
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. 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 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) ;-) BR, -R > > Alex
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. > > 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. Alex
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. >> >> 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
On 10/12/2017 02:48 PM, Rob Clark wrote: > 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. >>> >>> 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. So I would not see what should be so special about Shell.efi. 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. Best regards Heinrich
On 10/12/2017 02:48 PM, Rob Clark wrote: > 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. >>> 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. Not sure that's terribly helpful. Most of these servers have built-in BMC chips that just go to a fake video console, so they always get EDID information, but that doesn't mean that it's sensible for what the user ends up seeing. I think what happens is that in most cases they just assume you have a 80x25 console :). > 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). Yes, and on basically all arm servers what you see happening is that grub gets squeezed into 80x25 for the text output. For graphical output, at least SUSE usually just defaults to gfxterm which directly drives GOP. Alex
On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt <xypron.glpk@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@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. >>>> >>>> >>>> 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. BR, -R
On Thu, Oct 12, 2017 at 9:11 AM, Alexander Graf <agraf@suse.de> wrote: > On 10/12/2017 02:48 PM, Rob Clark wrote: >> >> 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. >>>> >>>> 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. > > > Not sure that's terribly helpful. Most of these servers have built-in BMC > chips that just go to a fake video console, so they always get EDID > information, but that doesn't mean that it's sensible for what the user ends > up seeing. > > I think what happens is that in most cases they just assume you have a 80x25 > console :). oh, right.. BMC's.. well, let's not strive to be as horrible as enterprise hardware ;-) BR, -R
> 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. > >> 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. > > 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.
On 10/12/2017 03:40 PM, Rob Clark wrote: > On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt <xypron.glpk@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@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. >>>>> >>>>> 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
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
On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <agraf@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@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@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. >>>>>> >>>>>> >>>>>> 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
On 10/12/2017 04:28 PM, Rob Clark wrote: > On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <agraf@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@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@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. >>>>>>> >>>>>>> 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. Now we're talking - that sounds much nicer indeed :) Alex
> From: Rob Clark <robdclark@gmail.com> > Date: Thu, 12 Oct 2017 10:28:43 -0400 > > On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <agraf@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@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@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. > >>>>>> > >>>>>> > >>>>>> 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. Or would you only do it for EFI payload that uses more than just the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL? That might be acceptable.
Am 12.10.2017 um 18:00 schrieb Mark Kettenis <mark.kettenis@xs4all.nl>: >> From: Rob Clark <robdclark@gmail.com> >> Date: Thu, 12 Oct 2017 10:28:43 -0400 >> >>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <agraf@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@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@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. >>>>>>>> >>>>>>>> >>>>>>>> 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 > >
On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt <xypron.glpk@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@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@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@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. >>>>>>>> >>>>>>>> >>>>>>>> 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
On 10/12/2017 04:28 PM, Rob Clark wrote: > On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf <agraf@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@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@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. >>>>>>> >>>>>>> >>>>>>> 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. > > 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. Regards Heinrich
On 10/12/2017 11:26 PM, Rob Clark wrote: > On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt <xypron.glpk@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@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@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@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. >>>>>>>>> >>>>>>>>> >>>>>>>>> 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. > I thought you were close to finishing off this patch series. Is this patch essential? Or could you simply resubmit the series without this patch and sort the questions about this patch out later? Best regards Heinrich >> >>> >>> 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 >
On Thu, Oct 12, 2017 at 7:48 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 10/12/2017 11:26 PM, Rob Clark wrote: >> On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt <xypron.glpk@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@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@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@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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >> > > I thought you were close to finishing off this patch series. > > Is this patch essential? > > Or could you simply resubmit the series without this patch and sort the > questions about this patch out later? > I talked to agraf on IRC.. there were a couple patches that I suggested to pull in asap for 2017.11.. the rest of the new proto's/etc for Shell.efi, including this, aren't really immediately useful for end users, so I suggested a separate efi-next-for-2018.1 (?) which we can start to pull these patches into, as well as other things you are working on, to better coordinate our work on further UEFI features independently of fixes destined for 2017.11. At this point, the new protocol stuff I mostly wanted to get into *some* branch so we aren't stepping on each other's toes. For this particular patch, IMHO the main prerequisite is to fix u-boot's output layer so puts() == fputs(stdout), which I'm not quite yet sure how to do. Once that is done, this patch changes *no* behaviour if you don't set efiout/efiin variables, so there should be no controversy. Although I do like the idea of expanding this to (at least for default behavior, not preventing anyone to override it for special cases) to try to detect if a serial console is attached.. that would let us improve the default behavior to cater to both u-boot dev's who like their serial ports and end users (who are the real target audience) in a more sane way.. BR, -R
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index c25d6b16f2..1333f9cb71 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -47,6 +47,38 @@ static struct cout_mode efi_cout_modes[] = { const efi_guid_t efi_guid_console_control = CONSOLE_CONTROL_GUID; +static struct stdio_dev *efiin, *efiout; + +static int efi_tstc(void) +{ + return efiin->tstc(efiin); +} + +static int efi_getc(void) +{ + return efiin->getc(efiin); +} + +static int efi_printf(const char *fmt, ...) +{ + va_list args; + uint i; + char printbuffer[CONFIG_SYS_PBSIZE]; + + va_start(args, fmt); + + /* + * For this to work, printbuffer must be larger than + * anything we ever want to print. + */ + i = vsnprintf(printbuffer, sizeof(printbuffer), fmt, args); + va_end(args); + + /* Print the string */ + efiout->puts(efiout, printbuffer); + return i; +} + #define cESC '\x1b' #define ESC "\x1b" @@ -111,16 +143,16 @@ static int term_read_reply(int *n, int maxnum, char end_char) char c; int i = 0; - c = getc(); + c = efi_getc(); if (c != cESC) return -1; - c = getc(); + c = efi_getc(); if (c != '[') return -1; n[0] = 0; while (1) { - c = getc(); + c = efi_getc(); if (c == ';') { i++; if (i >= maxnum) @@ -164,7 +196,7 @@ static efi_status_t EFIAPI efi_cout_output_string( *utf16_to_utf8((u8 *)buf, string, n16) = '\0'; - fputs(stdout, buf); + efiout->puts(efiout, buf); for (p = buf; *p; p++) { switch (*p) { @@ -217,14 +249,14 @@ static int query_console_serial(int *rows, int *cols) u64 timeout; /* Empty input buffer */ - while (tstc()) - getc(); + while (efi_tstc()) + efi_getc(); - printf(ESC"[18t"); + efi_printf(ESC"[18t"); /* Check if we have a terminal that understands */ timeout = timer_get_us() + 1000000; - while (!tstc()) + while (!efi_tstc()) if (timer_get_us() > timeout) return -1; @@ -246,16 +278,13 @@ static efi_status_t EFIAPI efi_cout_query_mode( EFI_ENTRY("%p, %ld, %p, %p", this, mode_number, columns, rows); if (!console_size_queried) { - const char *stdout_name = env_get("stdout"); int rows, cols; console_size_queried = true; - if (stdout_name && !strcmp(stdout_name, "vidconsole") && + if (!strcmp(efiout->name, "vidconsole") && IS_ENABLED(CONFIG_DM_VIDEO)) { - struct stdio_dev *stdout_dev = - stdio_get_by_name("vidconsole"); - struct udevice *dev = stdout_dev->priv; + struct udevice *dev = efiout->priv; struct vidconsole_priv *priv = dev_get_uclass_priv(dev); rows = priv->rows; @@ -342,9 +371,9 @@ static efi_status_t EFIAPI efi_cout_set_attribute( EFI_ENTRY("%p, %lx", this, attribute); if (attribute) - printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg); + efi_printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg); else - printf(ESC"[0;37;40m"); + efi_printf(ESC"[0;37;40m"); return EFI_EXIT(EFI_SUCCESS); } @@ -354,7 +383,7 @@ static efi_status_t EFIAPI efi_cout_clear_screen( { EFI_ENTRY("%p", this); - printf(ESC"[2J"); + efi_printf(ESC"[2J"); return EFI_EXIT(EFI_SUCCESS); } @@ -365,7 +394,7 @@ static efi_status_t EFIAPI efi_cout_set_cursor_position( { EFI_ENTRY("%p, %ld, %ld", this, column, row); - printf(ESC"[%d;%df", (int)row, (int)column); + efi_printf(ESC"[%d;%df", (int)row, (int)column); efi_con_mode.cursor_column = column; efi_con_mode.cursor_row = row; @@ -378,7 +407,7 @@ static efi_status_t EFIAPI efi_cout_enable_cursor( { EFI_ENTRY("%p, %d", this, enable); - printf(ESC"[?25%c", enable ? 'h' : 'l'); + efi_printf(ESC"[?25%c", enable ? 'h' : 'l'); return EFI_EXIT(EFI_SUCCESS); } @@ -464,28 +493,28 @@ static efi_status_t read_key_stroke(struct efi_key_data *key_data) }; char ch; - if (!tstc()) { + if (!efi_tstc()) { /* No key pressed */ return EFI_NOT_READY; } - ch = getc(); + ch = efi_getc(); if (ch == cESC) { /* Escape Sequence */ - ch = getc(); + ch = efi_getc(); switch (ch) { case cESC: /* ESC */ pressed_key.scan_code = 23; break; case 'O': /* F1 - F4 */ - pressed_key.scan_code = getc() - 'P' + 11; + pressed_key.scan_code = efi_getc() - 'P' + 11; break; case 'a'...'z': key_state.key_shift_state = EFI_SHIFT_STATE_VALID | EFI_EFI_LEFT_ALT_PRESSED; break; case '[': - ch = getc(); + ch = efi_getc(); switch (ch) { case 'A'...'D': /* up, down right, left */ pressed_key.scan_code = ch - 'A' + 1; @@ -497,16 +526,16 @@ static efi_status_t read_key_stroke(struct efi_key_data *key_data) pressed_key.scan_code = 5; break; case '1': /* F5 - F8 */ - pressed_key.scan_code = getc() - '0' + 11; - getc(); + pressed_key.scan_code = efi_getc() - '0' + 11; + efi_getc(); break; case '2': /* F9 - F12 */ - pressed_key.scan_code = getc() - '0' + 19; - getc(); + pressed_key.scan_code = efi_getc() - '0' + 19; + efi_getc(); break; case '3': /* DEL */ pressed_key.scan_code = 8; - getc(); + efi_getc(); break; } break; @@ -584,7 +613,7 @@ static void EFIAPI efi_console_timer_notify(struct efi_event *event, void *context) { EFI_ENTRY("%p, %p", event, context); - if (tstc()) { + if (efi_tstc()) { read_keys(); efi_con_in.wait_for_key->is_signaled = true; efi_signal_event(efi_con_in.wait_for_key); @@ -723,6 +752,27 @@ struct efi_object efi_console_input_obj = { .handle = &efi_console_input_obj, }; +static struct stdio_dev *get_stdio_dev(const char *envname, int default_dev) +{ + const char *name; + struct stdio_dev *dev = NULL; + + name = env_get(envname); + if (name) { + dev = stdio_get_by_name(name); + if (dev && dev->start) { + int ret = dev->start(dev); + if (ret < 0) + dev = NULL; + } + } + + if (!dev) + dev = stdio_devices[default_dev]; + + return dev; +} + /* This gets called from do_bootefi_exec(). */ int efi_console_register(void) { @@ -733,6 +783,9 @@ int efi_console_register(void) list_add_tail(&efi_console_output_obj.link, &efi_obj_list); list_add_tail(&efi_console_input_obj.link, &efi_obj_list); + efiout = get_stdio_dev("efiout", stdout); + efiin = get_stdio_dev("efiin", stdin); + r = efi_create_event(EVT_NOTIFY_WAIT, TPL_CALLBACK, efi_key_notify, NULL, &efi_con_in.wait_for_key); if (r != EFI_SUCCESS) {
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> --- As mentioned yesterday, this triggers some problems w/ qemu + 'bootefi hello' since puts() != fputs(stdout). So you can hold off applying this one for now if you want until we figure out a solution. It is not strictly required, only nice-to-have (and nice for enabling debug traces on serial without interfering with Shell.efi output on screen) lib/efi_loader/efi_console.c | 111 ++++++++++++++++++++++++++++++++----------- 1 file changed, 82 insertions(+), 29 deletions(-)