Hi Deb,
c)Our signed driver (.efi) when converted into .rom image fails to load from
the shell under secure boot.
Could you reproduce this issue on NT32 platform? if yes, please send out your
procedures.
Thanks,
Guo
From: Debabrata Chattopadhyay [mailto:debabrata.chattopadh...@pmcs.com]
Sent: T
Hi all,
I have an UEFI application in which I try to allocate memory of type
EfiBootServicesData, using the AllocatePages function. In order to find the
next available (unallocated) memory space - of type EfiConventionalMemory - I
use the GetMemoryMap function. The problem which I'm facing is t
Hi:
Allocation requests of Type AllocateAddress means allocate pages at the
address pointed to by Memory on input. If the requested pages could not be
found, EFI_NOT_FOUND will return.
For your issue, the memory described by PhysicalAddress should not be
available. So, EFI_NOT_FOUND returns
All the patches required to build UEFI for the ARM Foundation and Base
Models have been committed to subversion (revision 14628).
The wikipage
(https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatfor
mPkg/AArch64) has been updated to use the repository instead of the
snapshot.
Hi Liming,
Yes, GetMemoryMap function sees that memory pointed by PhysicaAddress as free -
marked as EfiConventionalMemory -,
but when trying to allocate memory there, using the AllocatePages function, it
fails with EFI_NOT_FOUND status.
Here is the memory map I am retrieving:
PhysicalAddress
Looks good.
Reviewed-by: Jaben Carsey
From: Dong, Eric
Sent: Tuesday, September 03, 2013 6:54 PM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [PATCH]ShellPkg: Get best language first before get string.
Importance: High
Hi Jaben,
Can you help to review this pat
Hello All,
Please go through the trail information and let me know your suggestions.
*My setup Details:*
My motherboard (Host-x86) is connected with arm based PCI board over
PCIe.There are four SATA and SCSI devices are connected on arm board.
*My requirement :*
We have written a PCI linux dev
Hi,
So when a driver produces two protocol interfaces to access the device
using the same protocol GUID. How do you open each instance?
Say you look for all BlkIo protocol devices via HandleBuffer, then want to
look if an ATA or SCSI passthru is attached as well, so use same handle,
but ATA pass
On Sep 4, 2013, at 3:11 PM, "David F." wrote:
> Hi,
>
> So when a driver produces two protocol interfaces to access the device using
> the same protocol GUID. How do you open each instance?
>
They are produced on different handles, as only a single protocol GUID can
exist per handle.
> S
Using ATA passthru, say you get a device using protocol block_io ... now
you use LocalDevicePath to look for the ATA PassThru, it gives you the
device handle with one of the ATA PassThru protocols available on that
handle. But where is the other one / how would I find it? Or is it simply
if you'
David -
Yes, you work your way back from the device path node that has the Block I/O
installed on it.
Tim
From: David F. [mailto:df7...@gmail.com]
Sent: Wednesday, September 04, 2013 4:47 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Multiple Protocols on same driver...
Using ATA
Tim - okay, and that will take you back to the Logical version? I take it
you can't work backwards to find the physical version of the ATA PassThru
protocol in cases where both the physical and logical interfaces are being
exposed?
On Wed, Sep 4, 2013 at 4:55 PM, Tim Lewis wrote:
> David –***
On 08/28/13 20:12, Laszlo Ersek wrote:
> The prefix matching logic in Match()
> [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
> to specify full (absolute) device paths. However, partial (relative)
> device paths starting with a HD() node are valid for booting. By not
>
Suggestion:
Instead of :
if (OpenProtocolFindIt (Handle, Protocol) != NULL) {
return NULL;
}
Have a counter and return the existing safe handle already open.
On Close of course would reduce the counter...
--
Lear
Dear MdePkg maintainer,
According to UEFI specification section6.1 at CreateEventEx():
Prototype
typedef
EFI_STATUS
CreateEventEx (
IN UINT32 Type,
IN EFI_TPL NotifyTpl,
IN EFI_EVENT_NOTIFY NotifyFunction OPTIONAL,
IN CONST VOID *NotifyContext OPTIONAL,
IN CONST EFI_GUID *EventGroup OPTIONAL,
OUT
Mars:
The patch is good. Reviewed-by: Liming Gao
Besides, have you verified this patch in GCC tool chain? If yes, I will help
you commit it.
Thanks
Liming
From: Mars Lin [mailto:mars_...@phoenix.com]
Sent: Thursday, September 05, 2013 10:07 AM
To: edk2-devel@lists.sourceforge.net
Subject:
Liming,
No, I do not verify this in GCC tool chain. Please help to test it.
Thanks for your help!
-Mars
From: Gao, Liming [mailto:liming@intel.com]
Sent: Thursday, September 05, 2013 10:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] EfiCreateEventReadyToBootEx and
EfiC
Sorin:
When your Shell Application is loaded, it will take some memory. Its taken
memory may conflict with your allocated memory.
Have you tried to allocate other free memory range, such as 1461,
2020?
Thanks
Liming
From: Sorin Vinturis [mailto:sorin.vintu...@yahoo.com]
Sent: Wednes
Mars:
This patch can pass GCC build. I will help commit it at r14631.
Thanks
Liming
From: Mars Lin [mailto:mars_...@phoenix.com]
Sent: Thursday, September 05, 2013 10:54 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] EfiCreateEventReadyToBootEx and
EfiCreateEventLegacyBootE
19 matches
Mail list logo
