Hello,
Has anybody encountered this error from Signtool when signing the UEFI driver?
Done Adding Additional Store
SignTool Error: SignedCode::Sign returned error: 0x800700C1
%1 is not a valid Win32 application.
SignTool Error: An error occurred while attempting to sign: MyDriver.efi
If
Hi,
> The implementation of this would be horrid, and it's made even more
> horrid by the fact that it would then have to do the platform-specific
> unlocking in its Legacy16Boot method, before re-enabling the normal
> stack-swapping code. And the CSM isn't really supposed to do that kind
> of p
Hi Zeng,
You are right.
When I did "svn up" I see no changes in this codes.
But when I erased the folder and type "svn up" I got a fresh copy with other
sources. Strange.
I seems have to refresh the whole EDK2 folder to be sure it is recent.
Regards,
Sergey.
21.01.2013, в 5:38, Zeng, Star напис
Hi Isakov,
thanks for replying.
As you said it worked for youwhat type of storage it was? i mean ATA or
NVMe storage?
I am having issue with Application on EfiSys which is on NVMe Storage.
thanks,
Baban
On Sat, Jan 19, 2013 at 8:57 AM,
wrote:
> Send edk2-devel mailing list submissions to
Ass
Thanks, w
Kevin
戴連輝
US mobile: +1 (503) 610-8080
US office: +1 (971) 222-3939
Taiwan mobile: +886-9-7071-9364
___
--
Master Visual Studio, SharePoint, SQL,
Hi Andrew,
Got it.
Thank you for your response.
--
BR
winddy_zhang
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your s
On Sun, 2013-01-20 at 20:36 -0600, David Woodhouse wrote:
> Here's a slightly more concrete version of that proposal:
The implementation may look something like this:
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBoot
On Jan 20, 2013, at 7:57 PM, winddy wrote:
> Hi experts,
>I find in variable driver, at runtime, if remain writable NVRAM space is
> not enough for caller's request, it will directly return
> EFI_OUT_OF_RESOURCES. I think FaultTolerantWrite driver could work at
> runtime(by SMM or others)
On Sun, 2013-01-20 at 19:54 -0800, Andrew Fish wrote:
> The basic problem is as soon as the CSM calls something outside the
> CSM code, then you don't know what kind of memory has been overwritten
> or hardware written to. So the design was always it is not safe to
> come back, as there is not a cl
Hi experts,
I find in variable driver, at runtime, if remain writable NVRAM space is
not enough for caller's request, it will directly return EFI_OUT_OF_RESOURCES.
I think FaultTolerantWrite driver could work at runtime(by SMM or others), so
why we do not do it? Is there any known issue or j
On Jan 20, 2013, at 5:53 PM, "Li, Elvin" wrote:
> If it matters, bear in mind that most of my CSM calls for now are just
> dummies that do almost nothing except return success. The only thing my
> CSM really does is populate the interrupt vectors (INT 15h is needed
> even to *return* from the Leg
On Mon, 2013-01-21 at 01:53 +, Li, Elvin wrote:
> [Li, Elvin] It is unlucky that CSM32 does not support returning back
> from legacy boot at all. If legacy boot is failed, a full function of
> CSM16 normally keep in legacy environment and INT19 handler indicates
> “No bootable device -- insert
On Sun, 2013-01-20 at 17:42 -0600, David Woodhouse wrote:
> It would be nice if there was a field in the EFI_COMPATIBILITY16_TABLE
> which let the CSM code indicate how much it wants locked. Then we could
> lock just the option roms and the bit that the CSM asks us to lock,
> while leaving RAM in b
David:
Some comments are added below. Search [Li, Elvin].
Thanks
Elvin
-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org]
Sent: Friday, January 18, 2013 8:44 PM
To: Li, Elvin
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] CSM and keyboard handling
Hi Sergey,
The latest UpdateWorkingBlock.c is attached for you, and I couldn't see any
code fragment like you stated. Could you help double confirm it in your code?
Thanks.
Star
-Original Message-
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Friday, January 18, 2013 8:06 PM
To: ed
On Sun, 2013-01-20 at 18:39 -0500, Joe Vernaci wrote:
> AFAIK the __attribute__((packed)) only allows for unaligned member
> accesses but assumes the root of the structure will be aligned.
I have often wished that that were true (or at least for GCC to have a
'nopadding' attribute for which is *i
I've made some progress on using SeaBIOS as a CSM, to the point where
I've got it successfully booting Linux and Windows. There's plenty more
to do to make it work *right*, and some of what I have done needs
cleaning up, but it's a good start.
The main issue I have on the OVMF side is that it lock
AFAIK the __attribute__((packed)) only allows for unaligned member accesses
but assumes the root of the structure will be aligned. Such as:
typedef struct __attribute__((packed)) {
uint8_t a; // aligned
uint32_t b; // unaligned
uint8_t c;
uint8_t d;
uint8_t e;
uint8_t f;
Hi Andrew,
That's fine, it's ambiguities that lead to problems like this. When I
wrote "must be type (signed) int" I was only referring to enumeration
constants within the enumeration definition. 6.7.2.2 sec 2 states "The
expression that defines the value of an enumeration constant shall be an
in
On Jan 20, 2013, at 12:18 PM, Joe Vernaci wrote:
> Hi Nikolai,
>
> I think your recast as a UINT32 is the correct change. From the UEFI spec
> 6.2 when allocating "MemoryType values in the range 0x8000..0x
> are reserved for use by UEFI OS loaders that are provided by operating s
You are correct if all enums are blindly recasted to UINT32. The purpose
of my example was to show typical compiler behavior and how enums can
correctly be used as signed or unsigned. How ever in this case where the
enum is greater/less than compared against a constant that borders what is
consid
On Sun, 2013-01-20 at 15:41 -0500, Joe Vernaci wrote:
> Could this cause unaligned memory accesses? This is fine for x86/x86_64,
> could cause a fault on Itanium, and will always cause a fault on EBC. It
> would be a pretty remote use case but still could happen.
Potentially, yes. For GCC we cou
Hi,
If we will always cast enum to UINT32 then in your sample we get e_s_neg >
e_s_pos
while without cast e_s_neg < e_s_pos.
It is not a method to work.
EFI_MEMORY_TYPE must be defined as INT32 but not questionable enum.
Sergey
On 21.01.2013, at 0:18, Joe Vernaci wrote:
> Hi Nikolai,
>
> I th
Could this cause unaligned memory accesses? This is fine for x86/x86_64,
could cause a fault on Itanium, and will always cause a fault on EBC. It
would be a pretty remote use case but still could happen.
On Sun, Jan 20, 2013 at 1:41 PM, David Woodhouse wrote:
> The current vgabios images shippe
Hi Nikolai,
I think your recast as a UINT32 is the correct change. From the UEFI spec
6.2 when allocating "MemoryType values in the range 0x8000..0x
are reserved for use by UEFI OS loaders that are provided by operating
system vendors. The only illegal memory type values are those in
The current vgabios images shipped with qemu violate the PCI Firmware
Specification by having a PCIR data structure at offset 0x10f, which is
not DWORD-aligned.
If I relax the check in OVMF, it works fine with SeaBIOS-as-CSM and I
can initialise the VGA ROM then use INT 10h services for display in
On Tue, 2013-01-08 at 22:56 +, David Woodhouse wrote:
> On Tue, 2013-01-08 at 14:41 -0800, Jordan Justen wrote:
> > Could you sign this as documented in OvmfPkg/Contributions.txt?
>
> When it's ready :)
Hm, you applied this (thanks) but it wasn't supposed to be applied until
the corresponding
27 matches
Mail list logo
