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
next 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