AARCH64 gcc error with const qualifiers

aarch64-linux-gnu-gcc on Debian/Sid fails lib compilation with:
lib/aarch64/initplat.c:44:35: error: initialization discards
‘const’ qualifier from pointer ta

AARCH64 gcc error with const qualifiers

aarch64-linux-gnu-gcc on Debian/Sid fails lib compilation with:
lib/aarch64/initplat.c:44:35: error: initialization discards
‘const’ qualifier from pointer target type
[-Werror=discarded-qualifiers]. This patch fixes it.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <noxorc@users.sf.net>

show more ...

Add Debugger protocol support.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

Add EBC (EFI Byte Code) protocol support.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

Add support for PCI Root Bridge I/O protocol.

PCI Root Bridge I/O protocol is used by PCI Bus Driver to perform
PCI Memory, PCI I/O, and PCI Configuration cycles on a
PCI Root Bridge. It also provid

Add support for PCI Root Bridge I/O protocol.

PCI Root Bridge I/O protocol is used by PCI Bus Driver to perform
PCI Memory, PCI I/O, and PCI Configuration cycles on a
PCI Root Bridge. It also provides services to perform different
types of bus mastering DMA.

V2 - Scratch that - there already exists an efipciio.h with most
of these definitions. Let me remove this patch and propose a new
one that will amend what's already there.
OK, here's a better version that adds the required definition in
efipciio.h. Note that EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and
EFI_PCI_IO_PROTOCOL are two different protocols.

V3 - Pete, There are now two defines of EFI_PCI_ADDRESS.
Please repost with your define removed.
Nigel, Sorry about that. Here's v3.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Bridge more gaps between EDK and gnu-efi
This patch adds a few more items to facilitate porting
from EDK to gnu-efi.
It also adds updated PE machine types and fixes a discrepancy
for EVT_EFI_SIGNAL_M

Bridge more gaps between EDK and gnu-efi
This patch adds a few more items to facilitate porting
from EDK to gnu-efi.
It also adds updated PE machine types and fixes a discrepancy
for EVT_EFI_SIGNAL_MAX.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Update global protocol GUIDs definitions to match EDK2

This patch introduces the use of the EDK2 names for the global GUID
variables, to allow for easier code conversion between EDK2 and
gnu-efi. Al

Update global protocol GUIDs definitions to match EDK2

This patch introduces the use of the EDK2 names for the global GUID
variables, to allow for easier code conversion between EDK2 and
gnu-efi. All the existing GUID global variables have also been
aliased for backwards compatibility.

The patch also completes some of the earlier work with regards to
protocol struct definitions to also match the EDK2, with the
following caveat:
Because some of gnu-efi GUID macro definitions were declared with
the name that the EDK2 uses for the protocol struct itself, we have
to immediately deprecate the following GUID data aliases:
EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL
EFI_SIMPLE_NETWORK_PROTOCOL
EFI_PCI_IO_PROTOCOL
EFI_PXE_BASE_CODE_CALLBACK_PROTOCOL
This means that existing code using one of the above will break
on compilation. To mitigate this, explicit warnings have been
placed at the location where a developer will look for breakage,
detailing how they should amend their code.

The KnownGuids short labels in guid.c were also updated/amended
in a manner that should be a bit more consistent (though I have
no idea what the EDK2 does here, since I haven't looked at the
actual EDK2 source).

Finally, besides clean up (typo, whitespaces, duplicate removal),
we introduce the _GNU_EFI macro, in efi.h, to allow for conditional
selection of specific gnu-efi API calls, in code that may be
compiled with either EDK2 or gnu-efi.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Add support for some UEFI 2.0 protocols

* DevicePath[To|From]Text
* BlockIo2
* DiskIo2
* Ex calls for Simple File System

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel

Add support for some UEFI 2.0 protocols

* DevicePath[To|From]Text
* BlockIo2
* DiskIo2
* Ex calls for Simple File System

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

This patch is a follow up to 8118d08727f437caf1fd6096756ec9f73ee36b19
and completes the renaming of structs, defines, and typedefs to match
the naming convention from the latest UEFI specifications.

This patch is a follow up to 8118d08727f437caf1fd6096756ec9f73ee36b19
and completes the renaming of structs, defines, and typedefs to match
the naming convention from the latest UEFI specifications.

This should make it easier for people to switch between EDK2 and
gnu-efi compilation.

The original names are #defined or typedef'd to the new names for
backwards compatibility. Also some whitespace cleanup was applied.

Note 1: From what I could see of the EDK API documentation,
structs are being aliased to their old names using typedef rather
than #define, so that's what I used. I altered some of the #define
from 8118d0 accordingly

Note 2: I also think it might be more helpful for users to keep
the backwards compatibility defs close to their declaration
(e.g. old GUID def right after current GUID declaration), rather
than in a separate section as was done in 8118d0, so that's what
I did in this patch.

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Add GUID for SMBIOS 3 entry point structure.
64 bit entry point structure has a different GUID
from the existing 32 bit version.

Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-o

Add GUID for SMBIOS 3 entry point structure.
64 bit entry point structure has a different GUID
from the existing 32 bit version.

Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

The latest gnu-efi produces the following warning when
compiled with MSVC: lib\print.c(1345): warning C4244:
'initializing': conversion from 'double' to 'float',
possible loss of data

Signed-off-by:

The latest gnu-efi produces the following warning when
compiled with MSVC: lib\print.c(1345): warning C4244:
'initializing': conversion from 'double' to 'float',
possible loss of data

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

This patch adds definitions to efiprot.h for
EFI_EDID_ACTIVE_PROTOCOL
EFI_EDID_DISCOVERED_PROTOCOL
EFI_EDID_OVERRIDE_PROTOCOL
It also adds the matching global variables to libefi.

Sig

This patch adds definitions to efiprot.h for
EFI_EDID_ACTIVE_PROTOCOL
EFI_EDID_DISCOVERED_PROTOCOL
EFI_EDID_OVERRIDE_PROTOCOL
It also adds the matching global variables to libefi.

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

I did not submit the right file on my last submission.
This patch corrects the printing of leading fractional
part 0s in Print("%f").

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed

I did not submit the right file on my last submission.
This patch corrects the printing of leading fractional
part 0s in Print("%f").

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

I did a quick review of the MS x86_64 calling convention for floating
point and as far as I can tell it agrees with the UEFI spec.
The attached patch removes -mno-mmx and -mno-sse for x86_64 and adds

I did a quick review of the MS x86_64 calling convention for floating
point and as far as I can tell it agrees with the UEFI spec.
The attached patch removes -mno-mmx and -mno-sse for x86_64 and adds
a new Print target, "%f", to print float and double types.

It seems to compile for ia32, although I'm not sure why - shouldn't
it be throwing errors because the new function FloatToStr() in print.c
accepts a float, yet I left -no-sse for ARCH=ia32? A better solution
might be to add -msoft-float for targets where the floating point
calling convention doesn't match the UEFI spec. As I'm not familiar
with UEFI on ia32, I didn't make any changes to it.

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Protocol struct/type/define renaming to match spec naming convention.

This patch renames a number of structs, defines, and typedefs to match
the naming convention in the UEFI specification. For exam

Protocol struct/type/define renaming to match spec naming convention.

This patch renames a number of structs, defines, and typedefs to match
the naming convention in the UEFI specification. For example, it renames
DRIVER_BINDING_PROTOCOL (preprocessor GUID define) to
EFI_DRIVER_BINDING_PROTOCOL_GUID, and renames EFI_DRIVER_BINDING (protocol
interface) to EFI_DRIVER_BINDING_PROTOCOL.

The original names are all #defined to the new names for backwards
compatibility, so nothing should be broken.

Included in this patch are renames for all the types/defines for the
following protocols:
EFI_DRIVER_BINDING_PROTOCOL
EFI_COMPONENT_NAME_PROTOCOL
EFI_COMPONENT_NAME2_PROTOCOL
EFI_LOADED_IMAGE_PROTOCOL

If you accept this patch I'll work on adjusting all the other protocols
to match the spec as well, as time allows. Moving to the spec's naming
convention makes the code clearer and improves portability with EDK2.

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

This patch adds protocol definitions (and the corresponding global
EFI_GUID instances) for EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL,
EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and
EFI_BUS_SPECIFIC_DRIVER_OVER

This patch adds protocol definitions (and the corresponding global
EFI_GUID instances) for EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL,
EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and
EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL, used in the driver
binding search procedure to select which driver to connect when
multiple drivers' Supported() functions indicate support for
the same controller.

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

The default __GNUC__ C code cannot be used with MinGW as it inserts
implicit calls to _umoddi3 and _udivdi3, which are unavailable when
compiling without the standard libraries (-nostdlib).

This pat

The default __GNUC__ C code cannot be used with MinGW as it inserts
implicit calls to _umoddi3 and _udivdi3, which are unavailable when
compiling without the standard libraries (-nostdlib).

This patch addresses this by providing an inline assembly definition
that is an exact conversion of the existing MS one, but for GCC's
AT&T syntax.

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

This patch simply duplicates the use of /ENTRY option being passed to
the MSVC ARM linker, to specify the entry point, as is already the case
for ia32 and x86_64.

Required to enable the compilation

This patch simply duplicates the use of /ENTRY option being passed to
the MSVC ARM linker, to specify the entry point, as is already the case
for ia32 and x86_64.

Required to enable the compilation of ARM drivers with MSVC, without
having to manually specify the entry point.

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

When copying structs, some compilers (e.g. MSVC for ARM) will use an
implicit call to memcpy(), which can result in an undefined reference.
Use CopyMem() to duplicate struct data instead.
NB: This pa

When copying structs, some compilers (e.g. MSVC for ARM) will use an
implicit call to memcpy(), which can result in an undefined reference.
Use CopyMem() to duplicate struct data instead.
NB: This patch also removes trailing whitespaces in event.c

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

When compiling in x86_32|Debug mode and choosing not to link with standard
Windows libraries, the MSVC compiler will throw the error:
gnu-efi.lib(print.obj) : error LNK2019: unresolved external symbo

When compiling in x86_32|Debug mode and choosing not to link with standard
Windows libraries, the MSVC compiler will throw the error:
gnu-efi.lib(print.obj) : error LNK2019: unresolved external symbol __allmul referenced in function _ValueToHex

Adding an explicit cast on the array index, to ensure that is not larger
than 32 bits, appears to fix the problem.

NB: This patch also removes trailing whitespaces, but the only real change
is on line 1253.

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

-fpic is not needed for MinGW, and MinGW32 issues a warning as a
result, which breaks gnu-efi compilation due to -Werror:
gnu-efi/lib/boxdraw.c:1:0: error: -fpic ignored for target
(all code is posit

-fpic is not needed for MinGW, and MinGW32 issues a warning as a
result, which breaks gnu-efi compilation due to -Werror:
gnu-efi/lib/boxdraw.c:1:0: error: -fpic ignored for target
(all code is position independent) [-Werror]

This patch ensures that -fpic is disabled when MinGW is used.

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

The following fixes a couple GCC specifics for the ARM platform,
that MSVC compilers will complain about (such as Visual Studio
2015 with ARM target).

Signed-off-by: Pete Batard <pbatard@users.sf.ne

The following fixes a couple GCC specifics for the ARM platform,
that MSVC compilers will complain about (such as Visual Studio
2015 with ARM target).

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

I also found an issue when compiling setjmp.S using MinGW for both
x86_32 and x86_64, due to the use of ELF specific assembler
extensions (.type setjmp, @function is not comptaible with PE-COFF).

Th

I also found an issue when compiling setjmp.S using MinGW for both
x86_32 and x86_64, due to the use of ELF specific assembler
extensions (.type setjmp, @function is not comptaible with PE-COFF).

This patch addresses that, by making sure that we use the equivalent
.type definition for MinGW. Note that I only addressed x86_32 and
x86_64 as I'm not aware of MinGW developments for any other archs.

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Commit 3dd05c and subsequent ones introduced the use of the GNU
specific __attribute__((__unused__)), which breaks MSVC compilation...

I'll use this as a reminder that gnu-efi is compiled with more

Commit 3dd05c and subsequent ones introduced the use of the GNU
specific __attribute__((__unused__)), which breaks MSVC compilation...

I'll use this as a reminder that gnu-efi is compiled with more than
GNU toolchains, and that contributors might want to be careful about
adding GNU-specific extensions...

This patch does the following:
Create a new eficompiler.h header that sets all compiler-specific
options and extensions
Create a new EFI_UNUSED macro to be used in lieu of
__attribute__((__unused__)) and applies it to the relevant sources
Move the ALIGN(x) macro, previously defined in efisetjmp.h to the new header

Oh, and it also fixes a bunch of trailing whitespaces (because my code
editor is set to do just that by default).

Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

%d now represents signed decimal, %u represents unsigned decimal.

This patch changes the behavior of Print() slightly. %d is now signed decimal,
and %u (new) is unsigned decimal. Previously, althoug

%d now represents signed decimal, %u represents unsigned decimal.

This patch changes the behavior of Print() slightly. %d is now signed decimal,
and %u (new) is unsigned decimal. Previously, although ValueToString supports
signed decimal printing, %d always read args as UINTxx.

Old behavior:
Print(L"%d\n", -4) -> "4294967292"

New behavior:
Print(L"%d\n, -4) -> "-4"
Print(L"%u\n", -4) -> "4294967292"

If you want to keep complete backwards compatibility you could leave %d alone
and make something else (probably shouldn't be %u to avoid confusion) be
signed decimal. But this way it agrees with the usual use of %d and %u.

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

Add support for EFI_RNG_PROTOCOL to the library.

Signed-off-by: Daniel Roy <danielbroy@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>