public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Pankaj Bansal <pankaj.bansal@nxp.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: ArmPkg/PlatformBootManagerLib : Multiple UEFI Shell Boot entries
Date: Mon, 21 Nov 2016 11:28:50 +0000	[thread overview]
Message-ID: <DBXPR04MB144FEB0914CCC7E3AD7EB9DF1B50@DBXPR04MB144.eurprd04.prod.outlook.com> (raw)

Hello Edk2 team,

We are observing that sometimes "UEFI Shell" entry is created even though it is present in boot manager menu in our ARMV8 NXP board
When this happens multiple times, we see multiple entries of "UEFI Shell" in boot manager menu:

/------------------------------------------------------------------------------\
|                                Boot Manager                                  |
\------------------------------------------------------------------------------/

                                                         Device Path :
   Boot Manager Menu                                     MemoryMapped(0xB,0xFF5
                                                         B1000,0xFFAC17D7)/FvFi
   UEFI Shell                                            le(7C04A583-9E3E-4F1C-
   UEFI Misc Device                                      AD65-E05268D0B4D1)
   UEFI Misc Device 2
   UEFI Misc Device 3
   UEFI Misc Device 4
   UEFI Shell
   UEFI PXEv4 (MAC:6805CA04D56A)
   UEFI Shell
   UEFI Shell
   UEFI Shell
   UEFI Shell
   UEFI Shell
                                                       v /------------------------------------------------------------------------------\
|                                                                              |
| ^v=Move Highlight       <Enter>=Select Entry      Esc=Exit                   |
\------------------------------------------------------------------------------/

We see that commit https://github.com/tianocore/edk2/commit/0e2c6c552990edcd6352c2395860cb0df62b158d can fix this problem.

	Remove any boot options that point to binaries built into the firmware and
	have become stale due to any of the following:
	- FvMain's base address or size changed (historical -- see commit
	  https://github.com/tianocore/edk2/commit/e191a3114f4c8fc0a05e4dc7bb72935f18ff4de9),
	- FvMain's FvNameGuid changed,
	- the FILE_GUID of the pointed-to binary changed,
	- the referenced binary is no longer built into the firmware.

	For example, multiple such "EFI Internal Shell" boot options can coexist.
	They technically differ from each other, but may not describe any built-in
	shell binary exactly. Such options can accumulate in a varstore over time,
	and while they remain generally bootable (thanks to the efforts of
	BmGetFileBufferByFvFilePath()), they look bad.

	Filter out any stale options.


But this commit is for ArmVirtPkg/PlatformBootManagerLib, while we use ArmPkg/PlatformBootManagerLib.
Can this commit be ported from ArmVirtPkg to ArmPkg? Are there any side effects/ precautions for doing so?

Thanks & Regards,
Pankaj Bansal



             reply	other threads:[~2016-11-21 11:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-21 11:28 Pankaj Bansal [this message]
2016-11-21 11:31 ` ArmPkg/PlatformBootManagerLib : Multiple UEFI Shell Boot entries Ard Biesheuvel

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=DBXPR04MB144FEB0914CCC7E3AD7EB9DF1B50@DBXPR04MB144.eurprd04.prod.outlook.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