On Wed, 2013-02-13 at 16:59 -0800, Andrew Fish wrote:
> I think the best solution may be to to have a PCD feature flag to
> control this feature. If you are constructing code in the edk2 you
> mostly want it to be generic and we can default to turning it on. If
> you are construction code with loos
Is there a list of functions that will be supported in the upcoming
standalone StdLib package. noticed spawn items don't exist.
Looks like most of the stuff is there and similar to gcc environment
(missing the same ones that exist in Windows).
Here's the list of items I've come across (I must al
Tim,
So I've hit this issue too. There was a bug Xcode a while back in regards to
correctly following the alignment rules for EFI. The compiler was placing
16-bit Unicode strings on odd boundaries. I filed a bug and the compiler has
since been fixed.
I think the best solution may be to to hav
Mike -
1) I didn't suggest a different BaseLib for each CPU architecture. Rather,
on those architectures that have alignment issues, the specific functions with
those issues be broken out into the CPU architecture specific directory, as we
do in BaseLib already.
2) Actually, the UEF
That is very helpful.
As far as debugging goes, my source level debugging for Nt32Pkg is messed
up and I haven't fixed it yet. SecMain immediately closes after opening
and debugging stops. Also, my test code from the previous emails crashes
Nt32 (run without debugging) instead of returning Inval
There is a cast to (EFI_HANDLE *) That is not needed in
InternalImageHandleToFvHandle()
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish
Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
EFI_HA
On Feb 13, 2013, at 1:36 PM, Thomas Rognon wrote:
> Thanks for helping me! Tried just L"Load.efi", but still no luck. I'm
> starting to research LoadImage and StartImage to use instead of the ShellLib,
> but Load Image needs the EFI_DEVICE_PATH_PROTOCOL for my efi image and that
> seems har
Thanks for helping me! Tried just L"Load.efi", but still no luck. I'm
starting to research LoadImage and StartImage to use instead of the
ShellLib, but Load Image needs the EFI_DEVICE_PATH_PROTOCOL for my efi
image and that seems hard to figure out how to get.
Here is what my screen looks like:
Try like this (no drive information) - that's how I've used it before.
Status = ShellExecute (
ImageHandle,
L"Load.efi",
FALSE,
NULL,
NULL
);
-Jaben
From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Wednesday,
I'm new to this and using CommandInit because I've seen it used after
ShellInitialize in other files. I removed it and now it doesn't hang, but
ShellExecute returns Invalid Parameter.
My goal is to execute a uefi application from inside another uefi
application. Here is my code:
///
Tim,
Of course we could have different versions of the BaseLib for each CPU
architecture. But that does not address the potential incompatibilities that
may be introduced in the C code that calls the functions in the BaseLib.
Much of the C source code in the EDK II project is intended to be co
An ASSERT is just another word for a hang. Every architecture that does not
have this issue hangs because one architecture does have this issue? In some
conditions, when the alignment fault code hasn't been loaded yet?
That is what APIs are for: to abstract those differences. There are means bui
Tim,
There are CPU architectures supported by the UEFI Specification that will
generate an alignment fault if there is an unaligned access.
Mike
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, February 13, 2013 10:16 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] How
Mike -
Why is the library enforcing this? An ASSERT is used for a critical runtime
error where a function cannot proceed. This condition does not fall into this
category on any platform that I am aware of (although there might be a speed
penalty).
Tim
From: Kinney, Michael D [mailto:michael.
On Feb 13, 2013, at 9:49 AM, Jordan Justen wrote:
> On Tue, Feb 12, 2013 at 8:49 PM, David F. wrote:
>> For visual studio the define for NULL in base.h should be
>>
>> #if defined(__cplusplus)
>> #define NULL 0
>> #else
>> #define NULL ((VOID *) 0)
>> #endif
>
> I was under the impression th
On Tue, Feb 12, 2013 at 8:49 PM, David F. wrote:
> For visual studio the define for NULL in base.h should be
>
> #if defined(__cplusplus)
> #define NULL 0
> #else
> #define NULL ((VOID *) 0)
> #endif
I was under the impression that EDK II was intentionally avoiding C++
support. (That is not to s
On Feb 13, 2013, at 9:34 AM, Tim Lewis wrote:
> Sathya –
>
> This was discussed earlier in this thread. I count it as a bug, since there
> is nothing in the API definition which requires pointers be on even addresses.
>
Tim,
I think the ASSERTs are based on this statement in the UEFI spec:
David --
Just to clarify: the C++ 98 spec requires that NULL evaluate to 0, which is
where I suspect VC++ is having trouble. In C++ 11 it must be 0 or a value of
type nullptr_t. In C is it allowed to also be ((VOID *) 0). See
http://www.cplusplus.com/reference/cstring/NULL/
Having said that: I
Are you using L"" for the strings?
Are the Unicode strings in your static library? If so then maybe the issue is
the compiler flags used to compile the EDK 1.6 static library, but I though
Visual Studio defaults to natural alignment, so L"" should get aligned? I guess
it could also be a stray
Sathya,
Those ASSERT() statements in APIs that operate in Unicode strings with a
character type of CHAR16.
Is your string declared as a CHAR16 array? If it is, then the compiler should
align in 16-bot boundary automatically. The one exception is an CHAR16 array
in a packed structure. If you
Sathya -
This was discussed earlier in this thread. I count it as a bug, since there is
nothing in the API definition which requires pointers be on even addresses.
Tim
From: Prakash, Sathya [mailto:sathya.prak...@lsi.com]
Sent: Wednesday, February 13, 2013 9:19 AM
To: edk2-devel@lists.sourcefor
I am able to compile my code successfully with UDK but when I run my code I see
lot ASSERTS similar to ASSERT (((UINTN) String & BIT0) == 0);
I have used a static library in my code which is compiled in EDK1.6 (I need to
port that to UDK but for now I am keeping this way to do some basic testing
Have you tried removing the CommandInit() call? Why do you need that?
From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Tuesday, February 12, 2013 8:43 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] ShellExecute
Additional info:
It crashes on ShellExecute with a memory violation
Hi Amit,
On Wed, Feb 13, 2013 at 2:59 PM, Amit Mahadik wrote:
> Hello,
> OpenProtocol protocol fails while trying to build a driver for UsbIo
> call if compiled with PandaboardPkg. Please suggest any pointers.
>
> Following is the code
>
> Status = gBS->OpenProtocol (
> C
Hello,
OpenProtocol protocol fails while trying to build a driver for UsbIo call
if compiled with PandaboardPkg. Please suggest any pointers.
Following is the code
Status = gBS->OpenProtocol (
Controller,
&gEfiUsbIoProtocolGuid,
(VOID
25 matches
Mail list logo
