Hi ,
I am working on a Boot manager
I have following set-up
in USB i have directory EFI->BOOT->Bootx64.efi(my EFI)
My EFI does load an image, before that I am trying to
EfiBootManagerRefreshAllBootOption () I am trying to refresh all but option
.but it hangs on EfiBootManagerRefreshAllBootOptio
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
IntelFrameworkPkg/IntelFrameworkPkg.dec
IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
ShellPkg/ShellPkg.dec
[LibraryClasses]
HiiLib
DebugLib
UefiLib
MemoryAllocationLib
UefiBootServicesTableLib
UefiApplicationEn
Hi,
when i import both lib in my project my EFI hangs at
EfiRefreshAllBootOptions, i removed LegacyBootManager and it worked fine .i
need both lib as i need to boot legacy from EFI, how this issue can be
resolved?
here is piece of inf file
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModule
This link is correct ...
https://github.com/tianocore/edk2-platforms/tree/minnowboard-max-udk2015
If you cannot get the link to work, go to this link first ...
https://github.com/tianocore/edk2-platforms
... then click on the 'Branch' button and select 'minnowboard-max-udk2015' from
the dropdow
Hi,
A few questions here.
What is the proposed directory structure for the edk2-patforms branches?
Will it be the same as in
https://github.com/tianocore/edk2-platforms/tree/minnowboard-max-udk2015, which
is just the same as edk2?
Or, will it be the similar to platform specific part of the dir
On 10/05/16 03:30, Yonghong Zhu wrote:
> Update the tools_def.template to add NOOPT support with GCC tool chains.
>
> Cc: Liming Gao
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu
> ---
> BaseTools/Conf/tools_def.template | 28 +++
Hi everyone. I have a problem with understanding the description of TE
files and its relocations.
The specifications says this:
"17.2 XIP Images
For execute-in-place (XIP) images that do not require relocations,
loading a TE image simply
requires that the loader adjust the image’s entry point from
On 10/05/16 04:47, spam collector wrote:
>
> - Original Message -
>> From: "Laszlo Ersek"
>> To: "spam collector"
>> Cc: edk2-de...@ml01.01.org
>> Sent: Tuesday, October 4, 2016 10:22:34 AM
>> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>> * The first stage improvem
Tapan,
Could this be a side effect of your patch? Should we allow the UefiShellLib to
continue without this protocol and then return an error only when the OpenFile
is called?
Also, it looks like we never properly initialize mUnicodeCollationProtocol. We
check for NULL in Constructor, but no
It's possible. But I think gEfiUnicodeCollation2ProtocolGuid protocol is
necessary for even other Shell libraries other than UefiShellLib in order to
have Shell parser and other command line processing to work properly. That's
why I added ASSERT if UefiShellLib fails to locate the protocol.
Re
I have found that it just dont return from
*mBmRefreshLegacyBootOption (); .*
have a look at code. let me know the possible cause of it ...
I need urgent help
EfiBootManagerRefreshAllBootOption (
VOID
)
{
EFI_STATUSStatus;
EFI_BOOT_MANAGER_LOAD_OPTION *NvBootOptions;
On 5 October 2016 at 15:48, Laszlo Ersek wrote:
> On 10/05/16 03:30, Yonghong Zhu wrote:
>> Update the tools_def.template to add NOOPT support with GCC tool chains.
>>
>> Cc: Liming Gao
>> Cc: Laszlo Ersek
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Yonghong Zhu
> On Oct 5, 2016, at 8:08 AM, valerij zaporogeci wrote:
>
> Hi everyone. I have a problem with understanding the description of TE
> files and its relocations.
TE is basically PE/COFF with a smaller header. Unlike ELF (Mach-O, etc.)
PE/COFF includes the headers in the executable image. The TE
Reviewed-by: Satya Yarlagadda
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Maurice
Ma
Sent: Wednesday, October 05, 2016 5:49 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [edk2] [PATCH] IntelFsp2Pkg/Tools: Add PE32 section rebasing
On 10/05/16 18:06, Ard Biesheuvel wrote:
> On 5 October 2016 at 15:48, Laszlo Ersek wrote:
>> On 10/05/16 03:30, Yonghong Zhu wrote:
>>> Update the tools_def.template to add NOOPT support with GCC tool chains.
>>>
>>> Cc: Liming Gao
>>> Cc: Laszlo Ersek
>>> Contributed-under: TianoCore Contribut
On 5 October 2016 at 18:56, Laszlo Ersek wrote:
> On 10/05/16 18:06, Ard Biesheuvel wrote:
>> On 5 October 2016 at 15:48, Laszlo Ersek wrote:
>>> On 10/05/16 03:30, Yonghong Zhu wrote:
Update the tools_def.template to add NOOPT support with GCC tool chains.
Cc: Liming Gao
Cc:
Update Quark North Cluster SMM dispatcher logic to handle
case where an SMI handler unregisters itself.
https://bugzilla.tianocore.org/show_bug.cgi?id=51
This issue was reproduced using the unit test at:
https://github.com/mdkinney/edk2/tree/Bug51/Reproduce
An ASSERT() is generated the 4th time
This series fixes the following two issues:
QuarkSocPkg QncSmmDispatcher passes incorrect context to SMI handler
https://bugzilla.tianocore.org/show_bug.cgi?id=136
QuarkSockg Use after free in QNCSmmCoreDispatcher
https://bugzilla.tianocore.org/show_bug.cgi?id=51
These issues can be reproduc
https://bugzilla.tianocore.org/show_bug.cgi?id=136
1) Add CallbackContext field to the DATABASE_RECORD structure that
is set to the RegisterContent value passed to QNCSmmCoreRegister().
This is the content that must be passed to the SMI handler when
its source is triggered.
2) Update usa
I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is
included to the platform build. If UefiShellLib has such dependency on
the protocol then according to EDKII Module Writer's Guide you need to
specify the dependency on protocol in the module .inf to ensure the
drivers prop
Thank you, Andrew, I guess I understood. PE/TE images get relocated at
FV creation time, they execute directly from FV and they are linked at
where they really will lie in XIP memory. And the alignment value
chosen is not that minimum of 512 byte, mentioned in the PE
specification. Now it's clear.
Daniil --
Per your point about modules: Adding a dependency expression to a library
should NOT have any effect on an application, since applications do not have
dependency expressions.
So this would indicate that you are trying to link a driver against the
UefiShellLib. Is this correct?
This
> On Oct 5, 2016, at 12:24 PM, Daniil Egranov wrote:
>
> I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is
> included to the platform build. If UefiShellLib has such dependency on the
> protocol then according to EDKII Module Writer's Guide you need to specify
> the dep
On 10/05/16 21:48, Andrew Fish wrote:
>
>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov wrote:
>>
>> I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is
>> included to the platform build. If UefiShellLib has such dependency on the
>> protocol then according to EDKII Module W
How about moving protocol locate from constructor to the actual function level
and returning an error if it fails to locate (See attached patch file).
Tapan
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, October 05, 2016 3:18 PM
To: Andrew Fish ; Danii
That should work. We also need to initialize the variable to NULL in the
constructor.
Do we need to be case insensitive for this? Can we use memcmp instead of the
prototol?
-Jaben
> -Original Message-
> From: Shah, Tapan [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016
Yes, it has to be case insensitive per the latest Shell spec.
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, October 05, 2016 3:35 PM
To: Shah, Tapan ; Laszlo Ersek ; Andrew
Fish ; Daniil Egranov
Cc: edk2-devel-01 ; Leif Lindholm
; Carsey, Jaben
Jaben --
In which cases would you have the Shell protocol present and not have the
Unicode Collation protocol?
By my count, the Shell itself cannot function without it (see
ProcessCommandLine()).
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Beh
On 10/05/16 22:24, Shah, Tapan wrote:
> How about moving protocol locate from constructor to the actual function
> level and returning an error if it fails to locate (See attached patch file).
What function is that precisely? The hunk headers in the patch don't show.
If it is a function that is
Move gEfiUnicodeCollation2ProtocolGuid protocol outside of UefiShellLib
constructor
function.
Locate gEfiUnicodeCollation2ProtocolGuid protocol in ShellOpenFileByName() which
consumes this protocol API.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah
---
ShellP
On 10/05/16 22:44, Tim Lewis wrote:
> Jaben --
>
> In which cases would you have the Shell protocol present and not have the
> Unicode Collation protocol?
That's exactly the question!
According to the spec, at least if the system cannot boot from a disk
device, then the collation protocol need
> On Oct 5, 2016, at 12:24 PM, valerij zaporogeci wrote:
>
> Thank you, Andrew, I guess I understood. PE/TE images get relocated at
> FV creation time, they execute directly from FV and they are linked at
> where they really will lie in XIP memory.
Pedantically speaking PE/TE images are not lin
> On Oct 5, 2016, at 1:58 PM, Laszlo Ersek wrote:
>
> On 10/05/16 22:44, Tim Lewis wrote:
>> Jaben --
>>
>> In which cases would you have the Shell protocol present and not have the
>> Unicode Collation protocol?
>
> That's exactly the question!
>
> According to the spec, at least if the sys
On 10/05/2016 02:48 PM, Andrew Fish wrote:
On Oct 5, 2016, at 12:24 PM, Daniil Egranov wrote:
I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is
included to the platform build. If UefiShellLib has such dependency on the
protocol then according to EDKII Module Writer's
On 10/05/16 22:53, Daniil Egranov wrote:
>
>
> On 10/05/2016 02:48 PM, Andrew Fish wrote:
>>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov
>>> wrote:
>>>
>>> I have the same ASSERT issue on Juno platform even the EnglishDxe.inf
>>> is included to the platform build. If UefiShellLib has such
>>> d
Is it possible that Daniil has UnicodeCollation and not UnicodeCollation2? The
shell itself can handle this case, but the ShellLib cannot.
Tim
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, October 05, 2016 1:58 PM
To: Tim Lewis ; Carsey, Jaben ;
Shah
> On Oct 5, 2016, at 1:53 PM, Daniil Egranov wrote:
>
>
>
> On 10/05/2016 02:48 PM, Andrew Fish wrote:
>>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov wrote:
>>>
>>> I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is
>>> included to the platform build. If UefiShellLib
On 10/05/16 22:59, Andrew Fish wrote:
>
>> On Oct 5, 2016, at 1:58 PM, Laszlo Ersek wrote:
>>
>> On 10/05/16 22:44, Tim Lewis wrote:
>>> Jaben --
>>>
>>> In which cases would you have the Shell protocol present and not have the
>>> Unicode Collation protocol?
>>
>> That's exactly the question!
>
If he has a DXE driver that consumes the shell lib (a valid case), then my
original suggestion stands: move it to ShellLibConstructorWorker. This is where
the ShellLib's internal pointers to the Shell protocol are initialized.
Tim
-Original Message-
From: af...@apple.com [mailto:af...@a
All,
What are your thoughts about Tapan's suggestion to move the protocol location
to the only function that needs it?
Andrew,
We cannot publish a dependency. There are DXE driver dynamic shell commands
that launch before the shell runs and produce the appropriate protocol so that
the shell w
On 10/05/16 23:05, Andrew Fish wrote:
> I'm guessing that your DXE Driver is dispatching prior UEFI Driver that
> publishes the protocol.
BTW... Why is EnglishDxe a UEFI_DRIVER rather than a DXE_DRIVER? It
doesn't conform to the UEFI driver model. (I'm not saying it *must* not
be a UEFI_DRIVER,
> On Oct 5, 2016, at 2:15 PM, Carsey, Jaben wrote:
>
> All,
> What are your thoughts about Tapan's suggestion to move the protocol location
> to the only function that needs it?
>
> Andrew,
>
> We cannot publish a dependency. There are DXE driver dynamic shell commands
> that launch before
Hi all,i need urgent help regarding this issue.
> On 05-Oct-2016, at 9:05 PM, Saqib Khan wrote:
>
>
> I have found that it just dont return from mBmRefreshLegacyBootOption (); .
>
> have a look at code. let me know the possible cause of it ...
> I need urgent help
>
> EfiBootManagerRefres
That is not enough. That gets called by the constructor. We need to not check
in either constructor or the constructor worker.
That difference only matters for the shell binary itself.
-Jaben
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
On 10/05/16 23:15, Carsey, Jaben wrote:
> All,
> What are your thoughts about Tapan's suggestion to move the protocol location
> to the only function that needs it?
As I wrote elsewhere in the thread, that will eliminate the assert, but
it will break ShellOpenFileByName() for good (under the same
Jaben --
Here is the relevant piece of code. There is *no way* for Unicode Collation to
execute without the Shell Protocol existing! There is no way for the Shell
Protocol to exist without (at least) Unicode Collation or Unicode Collation 2
from existing.
So adding a check to the function does
Laszlo,
There are many types of UEFI Drivers and they are enumerated in the
UEFI Driver Writer's Guide. Some follow the UEFI Driver Model and
some do not.
A driver that only consumes/produces UEFI services/protocols without a depex
should be a UEFI Driver. If there is a depex or use of any PI
> On Oct 5, 2016, at 2:23 PM, Saqib Khan wrote:
>
>
>
> Hi all,i need urgent help regarding this issue.
>
Saqib,
You likely have a bug in your CSM. So that is your gEfiLegacyBiosProtocolGuid
implementation and all the 16-bit legacy BIOS code.
So you should contact the people you got you
On 10/05/2016 04:15 PM, Carsey, Jaben wrote:
All,
What are your thoughts about Tapan's suggestion to move the protocol location
to the only function that needs it?
Andrew,
We cannot publish a dependency. There are DXE driver dynamic shell commands
that launch before the shell runs and prod
Thank you very much, Andrew.
The last question. Regarding that scheme you depicted, which entity
will have ImageBase address when TE image is loaded in the memory? A
'conceptual' stripped Pe headers, or Te header?
Which is placed (even conceptually) at ImageBase address?
P <--- This? (would have be
On 10/05/16 23:34, Kinney, Michael D wrote:
> Laszlo,
>
> There are many types of UEFI Drivers and they are enumerated in the
> UEFI Driver Writer's Guide. Some follow the UEFI Driver Model and
> some do not.
>
> A driver that only consumes/produces UEFI services/protocols without a depex
> shou
> On Oct 5, 2016, at 2:45 PM, valerij zaporogeci wrote:
>
> Thank you very much, Andrew.
> The last question. Regarding that scheme you depicted, which entity
> will have ImageBase address when TE image is loaded in the memory? A
> 'conceptual' stripped Pe headers, or Te header?
> Which is place
Laszlo,
As Tim clarified, the API already fail when the shell protocol was not present
and the shell already needs the UnicodeCollation protocol.
The goal here is not to allow the library to function without the shell
protocol (and thereby the UnicodeCollation protocol). The goal is to allow t
Tested-by: Bruce Cran
Sent from my iPhone
> On Oct 5, 2016, at 12:06 PM, Ard Biesheuvel wrote:
>
>> On 5 October 2016 at 18:56, Laszlo Ersek wrote:
>>> On 10/05/16 18:06, Ard Biesheuvel wrote:
On 5 October 2016 at 15:48, Laszlo Ersek wrote:
> On 10/05/16 03:30, Yonghong Zhu wrote:
>
On 10/04/2016 07:30 PM, Yonghong Zhu wrote:
Update the tools_def.template to add NOOPT support with GCC tool chains.
Cc: Liming Gao
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
Reviewed-by: Bruce Cran
Tested-by: Bruce Cran
Tested w
>> The ImageBase is the same for PE/COFF and TE.
>> In the code ImageAddress points to the start of T or P (well P can have a
>> DOS header
>> prepended etc). I think a lot of the code operates on ImageAddress and thus
>> needs the
>> adjustment.
Well, I don't want to abuse your attention. Just
And pushed.
Reviewed-by: Jaben Carsey
> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Tapan Shah
>
> Subject: [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of
https://bugzilla.tianocore.org/show_bug.cgi?id=132
This patch allows FILE DATA statements in [FmpPayload] sections
to refer to a file that does not exist at the time the FDF file
is parsed. There are cases where these FILE DATA statements refer
to FD or FV images that are generated as part of the
> On Oct 5, 2016, at 4:25 PM, valerij zaporogeci wrote:
>
>>> The ImageBase is the same for PE/COFF and TE.
>>> In the code ImageAddress points to the start of T or P (well P can have a
>>> DOS header
>>> prepended etc). I think a lot of the code operates on ImageAddress and thus
>>> needs the
The patch reads a valid MAC address form the Juno IOFPGA registers
and pushes it into onboard Marvell Yukon NIC.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daniil Egranov
---
.../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 141 +
.../Drivers/
- Original Message -
> From: "Laszlo Ersek"
> To: "spam collector"
> Cc: edk2-de...@ml01.01.org
> Sent: Wednesday, October 5, 2016 8:28:46 AM
> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>
> On 10/05/16 04:47, spam collector wrote:
> >
> > - Original Message --
- Original Message -
> From: "Laszlo Ersek"
> To: "spam collector"
> Cc: edk2-de...@ml01.01.org
> Sent: Wednesday, October 5, 2016 8:28:46 AM
> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>
> I recommend trying the following (32-bit command line), with Gerd's package:
62 matches
Mail list logo