Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30960 posts in this topic

Recommended Posts

RehabMan
RehabMan
Posted
Posted

Sure, here you go. Keep me posted.

attachicon.gifCLOVER.zip

The problem is caused by the NULL entry at the end of your XSDT.

It should be fixed by the changes in my new AcpiPatcher.c (not committed to github yet).

  • Like 2
apianti
apianti
Posted
Posted

Yes, plz show where that is specified in the EFI 1.10 spec ;)

Lol, yeah, it's in there. Just like in UEFI.

 

From section 2.3:

Unless otherwise stated, all functions defined in the EFI specification are called through pointers in common, architecturally defined, calling conventions found in C compilers.

From section 2.3.2:

All functions are called with the C language calling convention.

From section 2.3.3:

EFI procedures are invoked using the P64 C calling conventions defined for Itanium-based applications.

EDIT: Forgot about MSABI. From section 2.1.1:

EFI uses a subset of the PE32+ image format with a modified header signature.

EDIT2: Make it clear I meant those excerpts came from sections of the EFI 1.10 spec.

apianti
apianti
Posted
Posted

Itanium is not AMD64 and UEFI 2.3 is not EFI 1.10.

 

Not UEFI 2.3... Those are the section numbers from the EFI 1.10 spec, which also does not support AMD64 because it did not exist yet. Both EFI 1.02 and 1.10 were released in 2000 and 2002, respectively. AMD64 wasn't introduced until the Opteron in 2003.

 

For the current UEFI 2.7 spec, X64 calling convention, from section 2.3.4:

All functions are called with the C language calling convention.
mhaeuser
mhaeuser
Posted
Posted

 

Not UEFI 2.3... Those are the section numbers from the EFI 1.10 spec, which also does not support AMD64 because it did not exist yet. Both EFI 1.02 and 1.10 were released in 2000 and 2002, respectively. AMD64 wasn't introduced until the Opteron in 2003.

 

Misunderstood the 2.3 then... If we both agree that 1.10 does not support AMD64, what are we arguing about? lol

apianti
apianti
Posted
Posted

Misunderstood the 2.3 then... If we both agree that 1.10 does not support AMD64, what are we arguing about? lol

 

The specification does not provide any information about it. But that doesn't mean it can't support it, Apple firmware is EFI 1.10 and supports it (granted now it's more like one of the lower UEFI versions without some stuff). But the spec gives ways to implement on platforms it does not include.

 

EDIT: I'm not arguing, I was just answering your questions/statements.

EDIT2: Also, those firmwares are 32bit UEFI 2.31, the only PC I've ever seen with just EFI was an Itanium2 server machine, and that's it. I wasn't even allowed to touch it because it was so expensive.

mhaeuser
mhaeuser
Posted
Posted

The specification does not provide any information about it.

 

It provides a whole lot of information about it, check 2.3.4 of UEFI 2.7... detailed system state, stack information and the role of the registers.

 

But that doesn't mean it can't support it, Apple firmware is EFI 1.10 and supports it

 

It's not strictly EFI then as it doesn't follow the spec.

 

But the spec gives ways to implement on platforms it does not include.

 

Yeah, maybe it's not illegal to support it on different arches, but it's not covered by the standard, which means it's not strictly EFI (what's the use of a standardized interface when not even the calling convention is?)

 

EDIT2: Also, those firmwares are 32bit UEFI 2.31

 

That obsoletes the entire discussion :D

apianti
apianti
Posted
Posted

It provides a whole lot of information about it, check 2.3.4 of UEFI 2.7... detailed system state, stack information and the role of the registers.

 

The EFI 1.10 spec. Of course the UEFI spec does.

 

It's not strictly EFI then as it doesn't follow the spec.

 

It implements all the components of EFI 1.10, so it does. Just has some extra stuff too, I'm guessing for boot camp.

 

Yeah, maybe it's not illegal to support it on different arches, but it's not covered by the standard, which means it's not strictly EFI (what's the use of a standardized interface when not even the calling convention is?)

That obsoletes the entire discussion :D

 

I have been saying this whole time that the spec says that it must be a PE32+ image and use C calling convention, making it MSABI C calling convention for ALL architectures. Even ones that it doesn't explicitly mention. So you could create some new chip and then create UEFI-compliant firmware for it by implementing the standard for your chip's design. Notice how there's no architecture dependent protocols in the required components? And yes, you don't have to implement all of the spec to be compliant.

mhaeuser
mhaeuser
Posted
Posted

 

 

I have been saying this whole time that the spec says that it must be a PE32+ image and use C calling convention, making it MSABI C calling convention for ALL architectures.

Where does it say it shall be MS(!)ABI for all 'implicite' CCs (PE32 is just a file format and can support any CC)? I interpret it as that diff arches are not prohibited, but their CC is undefined (except for that it must be "common")

 

Sry for the misunderstanding before, should not comment when I have no time to properly think it through ;p

apianti
apianti
Posted
Posted

Where does it say it shall be MS(!)ABI for all 'implicite' CCs (PE32 is just a file format and can support any CC)? I interpret it as that diff arches are not prohibited, but their CC is undefined (except for that it must be "common")

 

Because PE is owned by microsoft, they had massive influence on UEFI design, and why would they allow the standardized abi to be anything else? They didn't want to change their compiler and it would be hard for the technology to be adopted if microsoft wasn't involved/using it for windows. But yeah, if you just invented a new architecture then you could use whatever convention you like but every EFI module has to use that convention. All the architectures in the spec use MSABI.

Slice
Slice
Posted
Posted

I am sorry but MS ABI (Windows, EFI) vs AMD ABI (Linux, Apple) is related only X86_64 architecture.

EFI32 has only ABI. For ARM there is no sense to speak about.

 

apianti,

I am thinking about SVG and I want to create vectors graphics library. What functions needed?

MoveTo(x,y)

LineTo(x,y,color)

FillArea(x,y,color) - restricted by a kontur line

CreateRectangle(x,y,x1,y1,color)

Ellipse(x,y,r1,r2,color)

Else?

  • Like 3
apianti
apianti
Posted
Posted

I am sorry but MS ABI (Windows, EFI) vs AMD ABI (Linux, Apple) is related only X86_64 architecture.

EFI32 has only ABI. For ARM there is no sense to speak about.

 

ARM only has one calling convention so there's no need to distinguish, that's the c calling convention. But the others all use MSABI C calling convention:

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/X64/ProcessorBind.h#L291

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Ia32/ProcessorBind.h#L277

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Ia32/ProcessorBind.h#L282

 

apianti,

I am thinking about SVG and I want to create vectors graphics library. What functions needed?

MoveTo(x,y)

LineTo(x,y,color)

FillArea(x,y,color) - restricted by a kontur line

CreateRectangle(x,y,x1,y1,color)

Ellipse(x,y,r1,r2,color)

Else?

 

I'm not sure, I'm not there yet. Need to cover every type of graphics in the svg spec, possibly much more than that....

Zenith432
Zenith432
Posted
Posted

UEFI specification section 2.3 defines EFI ABI for x86, x86_64, Intel Itanium, ARM 32-bit, ARM 64-bit.  The only connection to Microsoft is that Intel is heavily connected to Microsoft, so they sometimes copy their technology.  In fact, EFI as whole feels a lot like a modern re-incarnation of DOS.  I think Intel's C/C++ compiler also generates Microsoft ABI for x86_64.

Anyway, GCC and clang both allow to build cross-ABI binaries in x86_64, using both ms_abi and sysv_abi.  So only EFIAPI functions in x86_64 need to have ms_abi.

  • Like 1
apianti
apianti
Posted
Posted

UEFI specification section 2.3 defines EFI ABI for x86, x86_64, Intel Itanium, ARM 32-bit, ARM 64-bit.  The only connection to Microsoft is that Intel is heavily connected to Microsoft, so they sometimes copy their technology.  In fact, EFI as whole feels a lot like a modern re-incarnation of DOS.  I think Intel's C/C++ compiler also generates Microsoft ABI for x86_64.

Anyway, GCC and clang both allow to build cross-ABI binaries in x86_64, using both ms_abi and sysv_abi.  So only EFIAPI functions in x86_64 need to have ms_abi.

 

Yeah, only talking about EFIAPI functions. Visual studio also has the ability to build cross-ABI binaries. VS2017 can even create linux apps and supposedly will be able to create macOS apps eventually (already android and iOS though). There are actually no descriptions of calling conventions in the spec beyond c convention besides x64. The description for x64 calling convention in the document is microsoft __fastcall, exactly. The document is heavily influenced by microsoft, they created the 1.02 spec with Intel.... If they withdrew support for UEFI for their own spec, they would probably win because windows dominates the market and people wouldn't stop using it. Linux couldn't even get keys to be included in firmware by default, they had to agree to get a signed shim because microsoft didn't want secure boot to be able to easily boot any other OS. Search for microsoft UEFI documents from between 2000 and 2007, especially power points, they are very telling.

mhaeuser
mhaeuser
Posted
Posted

Guess that was the issue all along... I was arguing from strictly the spec and you were arguing from 'common sense'. Yes, it was obvious they would go with MS' CC for X64 when they added it to the spec, but it was not clear from the 1.10 spec self-containing and neither is it now for any future arches (remember that there are arches that MSFT does not support... RISC-V? ;) )

RehabMan
RehabMan
Posted
Posted

Sure, here you go. Keep me posted.

attachicon.gifCLOVER.zip

This problem (NULL in XSDT causing add-on SSDTs to be patched by ACPI/Patches) should be fixed by the Clover I just uploaded to bitbucket:

https://bitbucket.org/RehabMan/clover/downloads/

 

Will work on submitting the change to mainline Clover.

  • Like 1
zxv
zxv
Posted
Posted

This problem (NULL in XSDT causing add-on SSDTs to be patched by ACPI/Patches) should be fixed by the Clover I just uploaded to bitbucket:

https://bitbucket.org/RehabMan/clover/downloads/

 

Will work on submitting the change to mainline Clover.

Good to know. Thank you for your work.

 

While it was easy enough in my case to route around the issue by renaming add-on SSDT devices to their pre-patch names, one could easily see this sort of thing inducing headaches for users down the road.

chris1111
chris1111
Posted
Posted

I do not know which revision was broken, but I just tested r4330

boot ESP CloverEFI 64-bits SATA Boot0af

The boot still hang on   6_

r4324 all good  ^_^
Slice
Slice
Posted
Posted

 

I do not know which revision was broken, but I just tested r4330

boot ESP CloverEFI 64-bits SATA Boot0af

The boot still hang on   6_

r4324 all good  ^_^

 

It depends on EDK2 revision and on chosen toolset. New EDK2 with XCODE5 tooset leads to this hang.

Looks like 25687 is first wrong revision.

chris1111
chris1111
Posted
Posted

It depends on EDK2 revision and on chosen toolset. New EDK2 with XCODE5 tooset leads to this hang.

I Compile EDK2 25764 Xcode Version 9.1 (9B55)

No issue before 4324

nms
nms
Posted
Posted

It depends on EDK2 revision and on chosen toolset. New EDK2 with XCODE5 tooset leads to this hang.

Looks like 25687 is first wrong revision.

This short patch

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/BaseLib.inf
index 320ac457..b772f82b 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -755,7 +755,6 @@
   X86DisablePaging32.c
   X86RdRand.c
   X64/GccInline.c | GCC
-  X64/Thunk16.S | XCODE
   X64/SwitchStack.nasm| GCC
   X64/SwitchStack.S | GCC
   X64/SetJump.nasm| GCC

will switch XCODE5 compilation from Thunk16.S to Thunk16.nasm in edk2 BaseLib and solve the hang at '6'. I have no idea what wrong with Thunk16.S (and/or xcode9.1) yet )-;

  • Like 3
 Share
Go to topic listing
×
×
  • Create New...