public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "PierreGondois" <pierre.gondois@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: devel@edk2.groups.io, ardb+tianocore@kernel.org,
	leif@nuviainc.com, sami.mujawar@arm.com, patrik.berglund@arm.com,
	marcin.juszkiewicz@linaro.org
Subject: Re: [PATCH 1/1] ArmPkg/PlatformBootManagerLib: Add path to boot UEFI Shell over UiApp
Date: Fri, 31 Mar 2023 10:47:56 +0200	[thread overview]
Message-ID: <81c4bdc8-b584-661e-803e-e80c95e9cecf@arm.com> (raw)
In-Reply-To: <4d1c3209-87d6-546d-e638-b15d0239e8f3@arm.com>

Hello Ard,

On 2/13/23 09:39, Pierre Gondois wrote:
> Hello Ard,
> 
> On 2/9/23 17:57, Ard Biesheuvel wrote:
>> On Tue, 7 Feb 2023 at 10:07, <pierre.gondois@arm.com> wrote:
>>>
>>> From: Pierre Gondois <pierre.gondois@arm.com>
>>>
>>> The UEFI Shell is a non-active boot option, at the opposite of UiApp.
>>> If no valid boot option is found, UiApp is selected. UiApp requires a
>>> human interaction. When installing a new EDKII image in CIs or when
>>> scripting is required, this is problematic.
>>>
>>> If no valid boot option is discovered, add a path to directly go to
>>> the UEFI Shell where the startup.nsh script is automatically executed.
>>> The UEFI Shell is launched after connecting possible devices, but
>>> before the reset that is meant to automatically make them visible.
>>>
>>> The new PcdUefiShellDefaultBootEnable must be set to TRUE to enable
>>> this behaviour. The Pcd is set to false by default.
>>>
>>
>> Is this similar to how we implemented this on RPi4? IIRC, a similar
>> issue came up there as well.
> 
> I'm not finding an equivalent for the Rpi4. I see that the
> BootDiscoveryPolicy was added, but this regards which devices to connect
> during boot IIUC. The UEFI Shell also seems to have been added to the
> Boot Manager Menu, but this should not select the UEFI Shell by default.
> 

Are you referring to the following ?
https://edk2.groups.io/g/devel/message/60719

If yes I don't think this patch aims to achieve the same thing.
The goal here is to reach the UEFI shell (i.e. make it an active option).
I believe the patch mentioned above doesn't modify that and is more about
making it visible in UiApp BootManager.

Please let me know if you were referring to another modification,
Regards,
Pierre

  reply	other threads:[~2023-03-31  8:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07  9:06 [PATCH 1/1] ArmPkg/PlatformBootManagerLib: Add path to boot UEFI Shell over UiApp PierreGondois
2023-02-09 16:57 ` Ard Biesheuvel
2023-02-13  8:39   ` PierreGondois
2023-03-31  8:47     ` PierreGondois [this message]
2023-04-14 12:22       ` [edk2-devel] " PierreGondois
2023-04-14 12:45   ` PierreGondois
     [not found]   ` <1755CDCBA23EBCF9.16809@groups.io>
2023-04-21  8:51     ` [edk2-devel] " PierreGondois
2023-02-09 17:14 ` Marcin Juszkiewicz
2023-02-13 14:27 ` Patrik Berglund
2023-02-14 13:36 ` Patrik Berglund
2023-04-21 14:57 ` Ard Biesheuvel
2023-04-25  6:57   ` PierreGondois

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81c4bdc8-b584-661e-803e-e80c95e9cecf@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox