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

[Rob Clark]

On Thu, Oct 12, 2017 at 7:48 PM, Heinrich Schuchardt  wrote:
> On 10/12/2017 11:26 PM, Rob Clark wrote:
>> On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt  
>> wrote:
>>> On 10/12/2017 04:28 PM, Rob Clark wrote:
 On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
> On 10/12/2017 03:40 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
>> wrote:
>>>
>>>
>>> On 10/12/2017 02:48 PM, Rob Clark wrote:

 On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>
>
>
> On 12.10.17 00:07, Rob Clark wrote:
>>
>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
>> 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 
>>>
>>>
>>> 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.
>>>

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

[Heinrich Schuchardt]

On 10/12/2017 11:26 PM, Rob Clark wrote:
> On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt  
> wrote:
>> On 10/12/2017 04:28 PM, Rob Clark wrote:
>>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
 On 10/12/2017 03:40 PM, Rob Clark wrote:
>
> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
> wrote:
>>
>>
>> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>>
>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



 On 12.10.17 00:07, Rob Clark wrote:
>
> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
> 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 
>>
>>
>> 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
> 

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

[Rob Clark]

On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt  wrote:
> On 10/12/2017 04:28 PM, Rob Clark wrote:
>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
>>> On 10/12/2017 03:40 PM, Rob Clark wrote:

 On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
 wrote:
>
>
> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>>
>>>
>>>
>>> On 12.10.17 00:07, Rob Clark wrote:

 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
 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 
>
>
> 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 

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

[Heinrich Schuchardt]

On 10/12/2017 04:28 PM, Rob Clark wrote:
> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
>> On 10/12/2017 03:40 PM, Rob Clark wrote:
>>>
>>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
>>> wrote:


 On 10/12/2017 02:48 PM, Rob Clark wrote:
>
> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>
>>
>>
>> On 12.10.17 00:07, Rob Clark wrote:
>>>
>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
>>> 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 


 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 

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

[Alexander Graf]

Am 12.10.2017 um 18:00 schrieb Mark Kettenis :

>> From: Rob Clark 
>> Date: Thu, 12 Oct 2017 10:28:43 -0400
>> 
>>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
 On 10/12/2017 03:40 PM, Rob Clark wrote:
 
 On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
 wrote:
> 
> 
>> On 10/12/2017 02:48 PM, Rob Clark wrote:
>> 
>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>> 
>>> 
>>> 
 On 12.10.17 00:07, Rob Clark wrote:
 
 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
 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 
> 
> 
> 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 

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

[Mark Kettenis]

> From: Rob Clark 
> Date: Thu, 12 Oct 2017 10:28:43 -0400
> 
> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
> > On 10/12/2017 03:40 PM, Rob Clark wrote:
> >>
> >> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
> >> wrote:
> >>>
> >>>
> >>> On 10/12/2017 02:48 PM, Rob Clark wrote:
> 
>  On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
> >
> >
> >
> > On 12.10.17 00:07, Rob Clark wrote:
> >>
> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
> >> 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 
> >>>
> >>>
> >>> 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)

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

[Alexander Graf]

On 10/12/2017 04:28 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:

On 10/12/2017 03:40 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
wrote:


On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
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 


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

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

[Rob Clark]

On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
> On 10/12/2017 03:40 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
>> wrote:
>>>
>>>
>>> On 10/12/2017 02:48 PM, Rob Clark wrote:

 On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>
>
>
> On 12.10.17 00:07, Rob Clark wrote:
>>
>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
>> 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 
>>>
>>>
>>> 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 

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

[Rob Clark]

On Thu, Oct 12, 2017 at 9:44 AM, Mark Kettenis  wrote:
>> From: Rob Clark 
>> Date: Thu, 12 Oct 2017 08:48:39 -0400
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>> >
>> >
>> > On 12.10.17 00:07, Rob Clark wrote:
>> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
>> >>>
>> >>> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Alexander Graf]

On 10/12/2017 03:40 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt  wrote:


On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 


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

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Mark Kettenis]

> From: Rob Clark 
> Date: Thu, 12 Oct 2017 08:48:39 -0400
> 
> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
> >
> >
> > On 12.10.17 00:07, Rob Clark wrote:
> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
> >>>
> >>> 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.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Rob Clark]

On Thu, Oct 12, 2017 at 9:11 AM, Alexander Graf  wrote:
> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>>
>>>
>>> On 12.10.17 00:07, Rob Clark wrote:

 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Rob Clark]

On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt  wrote:
>
>
> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>>
>>>
>>>
>>> On 12.10.17 00:07, Rob Clark wrote:

 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
>
>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Alexander Graf]

On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:


On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 

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

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Heinrich Schuchardt]

On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 


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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Rob Clark]

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>
>
> On 12.10.17 00:07, Rob Clark wrote:
>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
>>>
>>> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Alexander Graf]

On 12.10.17 00:07, Rob Clark wrote:
> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
>>
>> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Rob Clark]

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  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 
>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Alexander Graf]

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 

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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot