Help on boot manager 'Boot Manager Menu' and direct boot

Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Hi ,
I am looking for information/Help. If UEFI passed different information to OS, in below boot path

  1.  Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on console, select device to boot OS
  2.  Let the boot OS without user intervention from same device as of 1

I could see, UEFI pass different memory map in case of 1 and 2.
Is there some other/extra information is being shared with OS/OS Loader.

For me, if I use 1) for booting  then OS boots okay,
If I use option 2) for booting then when user-space prints are printed as garbage. Whereas kernel space prints are good on serial console

Thanks
Udit

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Andrew Fish]

Udit,

Memory map differences would be expected as UiApp.efi is going to allocate memory too. The OS Loader starts off as an EFI Application so it needs to know EFI time allocations in addition to what allocations are legal for the OS to use. 

In general how EFI communicates with the OS is via EFI NVRAM Variables. You can look at the Table in section "3.3 Globally Defined Variables" of the UEFI Spec. The OSprot will also figure out information about the platform from ACPI tables published by the EFI firmware. Also the OS Loader is an EFI App so it can access any protocol mentioned in the UEFI Spec. So form example on a Unix like OS the OS Loader may construct a Device Tree and pass it up to the kernel. It is going to be the code in the OS loader that does all this magic. If your working with a FOSS OS you may want to try and dump that device tree, and see if something is different. Then you could try to figure out the code in the OS Loader that produces that part of the device tree. 

Thanks,

Andrew Fish

> On Nov 28, 2018, at 5:42 PM, Udit Kumar <udit.kumar@nxp.com> wrote:
> 
> Hi ,
> I am looking for information/Help. If UEFI passed different information to OS, in below boot path
> 
>  1.  Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on console, select device to boot OS
>  2.  Let the boot OS without user intervention from same device as of 1
> 
> I could see, UEFI pass different memory map in case of 1 and 2.
> Is there some other/extra information is being shared with OS/OS Loader.
> 
> For me, if I use 1) for booting  then OS boots okay,
> If I use option 2) for booting then when user-space prints are printed as garbage. Whereas kernel space prints are good on serial console
> 
> Thanks
> Udit
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Thanks for pointers Andrew
But if I use emulated runtime variables or say efi=noruntime, I am getting same behavior.
On device tree, I see device tree same in both cases.

In case of direct boot, only user space console is corrupted whereas kernel space console
already prints good characters.

FYI, 
Both user space and kernel space are on same kermit session

Regards
Udit


> -----Original Message-----
> From: afish@apple.com <afish@apple.com>
> Sent: Thursday, November 29, 2018 7:22 AM
> To: Udit Kumar <udit.kumar@nxp.com>
> Cc: edk2-devel@lists.01.org; Ni, Ruiyu <ruiyu.ni@intel.com>; Zeng, Star
> <star.zeng@intel.com>
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> Udit,
> 
> Memory map differences would be expected as UiApp.efi is going to allocate
> memory too. The OS Loader starts off as an EFI Application so it needs to know
> EFI time allocations in addition to what allocations are legal for the OS to use.
> 
> In general how EFI communicates with the OS is via EFI NVRAM Variables. You
> can look at the Table in section "3.3 Globally Defined Variables" of the UEFI
> Spec. The OSprot will also figure out information about the platform from ACPI
> tables published by the EFI firmware. Also the OS Loader is an EFI App so it can
> access any protocol mentioned in the UEFI Spec. So form example on a Unix like
> OS the OS Loader may construct a Device Tree and pass it up to the kernel. It is
> going to be the code in the OS loader that does all this magic. If your working
> with a FOSS OS you may want to try and dump that device tree, and see if
> something is different. Then you could try to figure out the code in the OS
> Loader that produces that part of the device tree.
> 
> Thanks,
> 
> Andrew Fish
> 
> > On Nov 28, 2018, at 5:42 PM, Udit Kumar <udit.kumar@nxp.com> wrote:
> >
> > Hi ,
> > I am looking for information/Help. If UEFI passed different
> > information to OS, in below boot path
> >
> >  1.  Enter into Setup menu (By pressing Esc key), On display of
> > UiApp.efi on console, select device to boot OS  2.  Let the boot OS
> > without user intervention from same device as of 1
> >
> > I could see, UEFI pass different memory map in case of 1 and 2.
> > Is there some other/extra information is being shared with OS/OS Loader.
> >
> > For me, if I use 1) for booting  then OS boots okay, If I use option
> > 2) for booting then when user-space prints are printed as garbage.
> > Whereas kernel space prints are good on serial console
> >
> > Thanks
> > Udit
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel&amp;data=02%7C01%7Cudit.ku
> >
> mar%40nxp.com%7C2188b5d2f4cb4c3fafbf08d6559d53d7%7C686ea1d3bc2b4c
> 6fa92
> >
> cd99c5c301635%7C0%7C0%7C636790531534117827&amp;sdata=lD8yDYmuqO
> hf5co6y
> > gkjTV9HTi1Kft8y4xJFOgU6TJE%3D&amp;reserved=0

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Laszlo Ersek]

On 11/29/18 04:09, Udit Kumar wrote:
> Thanks for pointers Andrew
> But if I use emulated runtime variables or say efi=noruntime, I am getting same behavior.
> On device tree, I see device tree same in both cases.
> 
> In case of direct boot, only user space console is corrupted whereas kernel space console
> already prints good characters.
> 
> FYI, 
> Both user space and kernel space are on same kermit session

I can only think of some terminal control sequences that are *not*
printed to the terminal when you don't enter UiApp manually. I don't
understand how that could cause the exact symptom you describe, but I
have no better explanation.

Can you try other serial communication programs on your desktop? Such as
"minicom" or "screen"?

Also, can you try changing your "console=..." kernel param(s)?

Thanks
Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Thanks Laszlo,

 
> I can only think of some terminal control sequences that are *not* printed to
> the terminal when you don't enter UiApp manually. I don't understand how that
> could cause the exact symptom you describe, but I have no better explanation.
> 
> Can you try other serial communication programs on your desktop? Such as
> "minicom" or "screen"?

Screen didn't help.
Moreover , using different OS distributions show same similar behavior !!
 
> Also, can you try changing your "console=..." kernel param(s)?

You meant baud-rate ? 

On uefi side,  could you help me if there is some extra information passed to OS in path 
UiApp -> BootDevice, 

I could see , some of additional protocols are installed in above path, I am not sure if those are
used  by  OS or OS Loader (grub in my case)  somehow.


> Thanks
> Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Laszlo Ersek]

On 11/29/18 14:12, Udit Kumar wrote:
> Thanks Laszlo,
> 
>  
>> I can only think of some terminal control sequences that are *not* printed to
>> the terminal when you don't enter UiApp manually. I don't understand how that
>> could cause the exact symptom you describe, but I have no better explanation.
>>
>> Can you try other serial communication programs on your desktop? Such as
>> "minicom" or "screen"?
> 
> Screen didn't help.
> Moreover , using different OS distributions show same similar behavior !!
>  
>> Also, can you try changing your "console=..." kernel param(s)?
> 
> You meant baud-rate ? 

Yes, and more. The options that the "console=" kernel parameter takes.

> 
> On uefi side,  could you help me if there is some extra information passed to OS in path 
> UiApp -> BootDevice, 

I don't think so. Nothing comes to my mind anyway.

> I could see , some of additional protocols are installed in above path, I am not sure if those are
> used  by  OS or OS Loader (grub in my case)  somehow.

Well, UiApp generally connects all drivers to all devices -- normally a
platform BDS would not want to do this, for the sake of booting quickly
--, which likely results in more protocol instances being installed in
the system. That shouldn't cause a difference for how serial behaves
once the OS has booted.

Thanks
Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Thanks Laszlo/Andrew
Finally I manage to get logs from user-space,  problem  was fifo of PL011 uart was not getting enable in case of direct boot.
But in case of boot via UiApp, some piece of code was setting serial port attribute to enable this ( I still to figure out from where). 
OS rely on boot-loader to enable this bit.
 
Regards
Udit

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Thursday, November 29, 2018 11:31 PM
> To: Udit Kumar <udit.kumar@nxp.com>; afish@apple.com
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org; Zeng, Star
> <star.zeng@intel.com>
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> On 11/29/18 14:12, Udit Kumar wrote:
> > Thanks Laszlo,
> >
> >
> >> I can only think of some terminal control sequences that are *not*
> >> printed to the terminal when you don't enter UiApp manually. I don't
> >> understand how that could cause the exact symptom you describe, but I have
> no better explanation.
> >>
> >> Can you try other serial communication programs on your desktop? Such
> >> as "minicom" or "screen"?
> >
> > Screen didn't help.
> > Moreover , using different OS distributions show same similar behavior !!
> >
> >> Also, can you try changing your "console=..." kernel param(s)?
> >
> > You meant baud-rate ?
> 
> Yes, and more. The options that the "console=" kernel parameter takes.
> 
> >
> > On uefi side,  could you help me if there is some extra information
> > passed to OS in path UiApp -> BootDevice,
> 
> I don't think so. Nothing comes to my mind anyway.
> 
> > I could see , some of additional protocols are installed in above
> > path, I am not sure if those are used  by  OS or OS Loader (grub in my case)
> somehow.
> 
> Well, UiApp generally connects all drivers to all devices -- normally a platform
> BDS would not want to do this, for the sake of booting quickly --, which likely
> results in more protocol instances being installed in the system. That shouldn't
> cause a difference for how serial behaves once the OS has booted.
> 
> Thanks
> Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Laszlo Ersek]

On 11/30/18 10:13, Udit Kumar wrote:
> Thanks Laszlo/Andrew
> Finally I manage to get logs from user-space,  problem  was fifo of PL011 uart was not getting enable in case of direct boot.
> But in case of boot via UiApp, some piece of code was setting serial port attribute to enable this ( I still to figure out from where). 
> OS rely on boot-loader to enable this bit.

Are you using the latest edk2?

I vaguely recall some refactoring around PL011 (and in general, serial) attributes from a year (or more?) ago. Hmm....

b462f25a21e1 MdeModulePkg/SerialDxe: Describe correctly EFI_DEVICE_ERROR for SetAttributes
13d378fc82d4 MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes
7ce5af40c98b MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported

and

91cc526b15ff MdeModulePkg/SerialDxe: Fix not able to change serial attributes

Thanks
Laszlo

>> -----Original Message-----
>> From: Laszlo Ersek <lersek@redhat.com>
>> Sent: Thursday, November 29, 2018 11:31 PM
>> To: Udit Kumar <udit.kumar@nxp.com>; afish@apple.com
>> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org; Zeng, Star
>> <star.zeng@intel.com>
>> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
>>
>> On 11/29/18 14:12, Udit Kumar wrote:
>>> Thanks Laszlo,
>>>
>>>
>>>> I can only think of some terminal control sequences that are *not*
>>>> printed to the terminal when you don't enter UiApp manually. I don't
>>>> understand how that could cause the exact symptom you describe, but I have
>> no better explanation.
>>>>
>>>> Can you try other serial communication programs on your desktop? Such
>>>> as "minicom" or "screen"?
>>>
>>> Screen didn't help.
>>> Moreover , using different OS distributions show same similar behavior !!
>>>
>>>> Also, can you try changing your "console=..." kernel param(s)?
>>>
>>> You meant baud-rate ?
>>
>> Yes, and more. The options that the "console=" kernel parameter takes.
>>
>>>
>>> On uefi side,  could you help me if there is some extra information
>>> passed to OS in path UiApp -> BootDevice,
>>
>> I don't think so. Nothing comes to my mind anyway.
>>
>>> I could see , some of additional protocols are installed in above
>>> path, I am not sure if those are used  by  OS or OS Loader (grub in my case)
>> somehow.
>>
>> Well, UiApp generally connects all drivers to all devices -- normally a platform
>> BDS would not want to do this, for the sake of booting quickly --, which likely
>> results in more protocol instances being installed in the system. That shouldn't
>> cause a difference for how serial behaves once the OS has booted.
>>
>> Thanks
>> Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Hi Laszlo 

> Are you using the latest edk2?
Yes, when I hit the bug, first step was to move to latest edk2. But this didn't helped.

I am not sure, why we are keeping PL011 Fifo mode off in default configuration.  

Regards
Udit

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Monday, December 3, 2018 3:27 PM
> To: Udit Kumar <udit.kumar@nxp.com>; afish@apple.com
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org; Zeng, Star
> <star.zeng@intel.com>
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> On 11/30/18 10:13, Udit Kumar wrote:
> > Thanks Laszlo/Andrew
> > Finally I manage to get logs from user-space,  problem  was fifo of PL011 uart
> was not getting enable in case of direct boot.
> > But in case of boot via UiApp, some piece of code was setting serial port
> attribute to enable this ( I still to figure out from where).
> > OS rely on boot-loader to enable this bit.
> 
> Are you using the latest edk2?
> 
> I vaguely recall some refactoring around PL011 (and in general, serial) attributes
> from a year (or more?) ago. Hmm....
> 
> b462f25a21e1 MdeModulePkg/SerialDxe: Describe correctly
> EFI_DEVICE_ERROR for SetAttributes
> 13d378fc82d4 MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes
> 7ce5af40c98b MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is
> not supported
> 
> and
> 
> 91cc526b15ff MdeModulePkg/SerialDxe: Fix not able to change serial attributes
> 
> Thanks
> Laszlo
> 
> >> -----Original Message-----
> >> From: Laszlo Ersek <lersek@redhat.com>
> >> Sent: Thursday, November 29, 2018 11:31 PM
> >> To: Udit Kumar <udit.kumar@nxp.com>; afish@apple.com
> >> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org; Zeng, Star
> >> <star.zeng@intel.com>
> >> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct
> boot
> >>
> >> On 11/29/18 14:12, Udit Kumar wrote:
> >>> Thanks Laszlo,
> >>>
> >>>
> >>>> I can only think of some terminal control sequences that are *not*
> >>>> printed to the terminal when you don't enter UiApp manually. I don't
> >>>> understand how that could cause the exact symptom you describe, but I
> have
> >> no better explanation.
> >>>>
> >>>> Can you try other serial communication programs on your desktop? Such
> >>>> as "minicom" or "screen"?
> >>>
> >>> Screen didn't help.
> >>> Moreover , using different OS distributions show same similar behavior !!
> >>>
> >>>> Also, can you try changing your "console=..." kernel param(s)?
> >>>
> >>> You meant baud-rate ?
> >>
> >> Yes, and more. The options that the "console=" kernel parameter takes.
> >>
> >>>
> >>> On uefi side,  could you help me if there is some extra information
> >>> passed to OS in path UiApp -> BootDevice,
> >>
> >> I don't think so. Nothing comes to my mind anyway.
> >>
> >>> I could see , some of additional protocols are installed in above
> >>> path, I am not sure if those are used  by  OS or OS Loader (grub in my case)
> >> somehow.
> >>
> >> Well, UiApp generally connects all drivers to all devices -- normally a platform
> >> BDS would not want to do this, for the sake of booting quickly --, which likely
> >> results in more protocol instances being installed in the system. That
> shouldn't
> >> cause a difference for how serial behaves once the OS has booted.
> >>
> >> Thanks
> >> Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Laszlo Ersek]

On 12/03/18 11:03, Udit Kumar wrote:
> Hi Laszlo 
> 
>> Are you using the latest edk2?
> Yes, when I hit the bug, first step was to move to latest edk2. But this didn't helped.
> 
> I am not sure, why we are keeping PL011 Fifo mode off in default configuration.  

Sorry, I don't know: although the subject logic has gone through several
updates over time, the default that you point out seems to go back to
commit 051e63bb551a ("ArmPlatformPkg/PL011Uart: Allowed to change UART
settings in its initialization function", 2012-02-29). And that commit
doesn't explain the default.

Thanks
Laszlo

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Ard Biesheuvel]

On Mon, 3 Dec 2018 at 14:45, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 12/03/18 11:03, Udit Kumar wrote:
> > Hi Laszlo
> >
> >> Are you using the latest edk2?
> > Yes, when I hit the bug, first step was to move to latest edk2. But this didn't helped.
> >
> > I am not sure, why we are keeping PL011 Fifo mode off in default configuration.
>
> Sorry, I don't know: although the subject logic has gone through several
> updates over time, the default that you point out seems to go back to
> commit 051e63bb551a ("ArmPlatformPkg/PL011Uart: Allowed to change UART
> settings in its initialization function", 2012-02-29). And that commit
> doesn't explain the default.
>

The default setting for
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth is 1 not 0,
and so you will end up with a 1 character FIFO setting. I wonder if we
could improve PL011UartInitializePort () in PL011UartLib to deal with
this better.

Note that this also affects platforms that can switch between DT and
ACPI boot: the same PL011 is described as a 'dumb' SBSA uart in the
latter case, and so it is up to the firmware to configure the UART
FIFO correctly, or you will not be able to use the UART under the ACPI
OS.

Re: Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Hi Ard 

> -----Original Message-----
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Sent: Monday, December 3, 2018 7:35 PM
> To: Laszlo Ersek <lersek@redhat.com>
> Cc: Udit Kumar <udit.kumar@nxp.com>; Andrew Fish <afish@apple.com>; Leif
> Lindholm <leif.lindholm@linaro.org>; Ruiyu Ni <ruiyu.ni@intel.com>; edk2-
> devel@lists.01.org; Zeng, Star <star.zeng@intel.com>
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> On Mon, 3 Dec 2018 at 14:45, Laszlo Ersek <lersek@redhat.com> wrote:
> >
> > On 12/03/18 11:03, Udit Kumar wrote:
> > > Hi Laszlo
> > >
> > >> Are you using the latest edk2?
> > > Yes, when I hit the bug, first step was to move to latest edk2. But this didn't
> helped.
> > >
> > > I am not sure, why we are keeping PL011 Fifo mode off in default
> configuration.
> >
> > Sorry, I don't know: although the subject logic has gone through
> > several updates over time, the default that you point out seems to go
> > back to commit 051e63bb551a ("ArmPlatformPkg/PL011Uart: Allowed to
> > change UART settings in its initialization function", 2012-02-29). And
> > that commit doesn't explain the default.
> >
> 
> The default setting for
> gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth is 1 not 0, and so
> you will end up with a 1 character FIFO setting. I wonder if we could improve

Setting this Pcd to zero will fix problem for me, 
With  PcdUartDefaultReceiveFifoDepth as 1, we are disabling the Fifo at IP level whereas for 0 we are enabling IP fifo.

> PL011UartInitializePort () in PL011UartLib to deal with this better.

Suggest, if IP level Fifo can be kept enabled, always ?

> Note that this also affects platforms that can switch between DT and ACPI boot:
> the same PL011 is described as a 'dumb' SBSA uart in the latter case, and so it is
> up to the firmware to configure the UART FIFO correctly, or you will not be able
> to use the UART under the ACPI OS.

For my ACPI boot (without SPCR table), I hit the same issue.

OS  (Linux, not sure of other OSes) except FIFO to be enabled by firmware/boot-loader. 

Regards
Udit