Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

apianti
apianti
Posted
Posted

It will be very good. Just hard to do.

 

Well the hardest part will be calculating the vectors and such when actually rendering. I have pretty much already written an xml parser (which svg are just xml like plist), but I just need to finish the schema document type definitions part so that the files can be validated, ie, letting the user know there is a parse error or unknown element. I did this before but then my computer was stolen by some evil person who I hope really enjoys it and makes them happy so that they know the happiness they took from me...... Haha. Anyway, should be easy to grab the plist and svg dtd schemas and use those to parse plist and svg as xml validated by the schemas. Then it would be just converting that xml to the correct format for usage, the configuration for plist and some internal vector image for svg.

 

Agree. As well as no 32bit support.

 

Well, maybe not support 32bit builds or anything like we currently do now, but try to keep it able to be built if wanted. I have a few random computers with 64bit atoms and operating systems but they have 32bit EFI for some reason... It's really weird but I know others who have such firmwares, it may be that the firmware size is limited and can be smaller if all the ints are half the size....?

 

EDIT: I meant to mention that I used to have a first gen Intel ComputeStick and it had both 32bit and 64bit EFI, you could switch it in the firmware menu...

 

I also may propose exclude huge list of videocards names. Let it be common name or user defined.

 

There's many huge databases in the code that don't need to be there. If people really wanted any of these databases a better idea would be to create an xml file with identifiers and either embed it in a driver or have the driver load it from some location, or both. That way it doesn't take huge amounts of space in the code, updating it doesn't require rebuilding (except the first case, but the last is probably best), and you can just not use the driver if you don't want a bunch of useless stuff you don't need. And yes, having ability to just set name for _DSM injection by user would be good idea too.

  • Like 1
Link to comment
Share on other sites
Ramalama
Ramalama
Posted
Posted

Guys, I have 2 Systems to Compare...:

 

1. System:

i7-6700 on H170 (Aptio 4 + ModBios (SMI/CSM etc disabled))

Intel 600p NVME (With APFS+Trim)

Boot Time: Really Fast

 

2. System:

i9-7900x on X299 (R6E, Aptio 5 + BiosMod not possible, no tools available)

960 Pro NVME (With APFS+Trim)

Boot Time: Fu..ing Slow

 

 

I made a preboot.log of both, on the x299 there is an entry (that takes up all the time...)

4:511  0:365  GUI ready

44:568  40:056  Found BIOS RSDP at F0010

But I don't get any information, what exactly takes that long... I don't believe that have something todo with ACPI Tables...

 

On the fast loading System (1), I have:

1:911  0:112  GUI ready

17:172  15:261  BootVariable of the entry is empty
 
So that makes Clear, that something doesn't get logged after "GUI ready"
 
Ive Attached the whole preboot logs of Both Systems...
 
 
EDIT:........
IM SO STUPID...
Ive answered my question myself, after I readed my post to correct typos... I need to activate Debug Log in config, to see what exactly happens....
Im really tired and stupid :-(
 
Cheers :-)
 

Skylake_H170.log.zip

SkylakeX_X299.log.zip

  • Like 1
Link to comment
Share on other sites
zxv
zxv
Posted
Posted

Please attach your EFI/Clover (as ZIP, don't forget to press F4 to generate ACPI/origin), without themes and Clover bootlog.

I'd like to see your setup and what is in your XSDT.

If your XSDT has NULL values in it, I can see where the current Clover will give you some unexpected results.

I am working on a significant cleanup to AcpiPatcher.c that will restore the old behavior for NULL entries (and fix some bugs in it), but it would be great to see an ACPI set that actually contains this NULL data.

 

Unless you have AutoMerge=true, any SSDTs you have in ACPI/patched should not be subject to config.plist/ACPI/DSDT/Patches.

But with a mergeable file in ACPI/patched, and AutoMerge=true, the game changes quite a bit (by design).

Sure, here you go. Keep me posted.

CLOVER.zip

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Well, maybe not support 32bit builds or anything like we currently do now, but try to keep it able to be built if wanted. I have a few random computers with 64bit atoms and operating systems but they have 32bit EFI for some reason... It's really weird but I know others who have such firmwares, it may be that the firmware size is limited and can be smaller if all the ints are half the size....?

 

Yeah, most 32-bit support can be preserved by just writing UEFI C-compliant code. :)

For your 32-bit fw on 64-bit CPU: Remember EFI did not have AMD64 CC, that came with UEFI... could be a lazy vendor.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Yeah, most 32-bit support can be preserved by just writing UEFI C-compliant code. :)

For your 32-bit fw on 64-bit CPU: Remember EFI did not have AMD64 CC, that came with UEFI... could be a lazy vendor.

 

I don't know what you mean. EFI has UINTN, it can be 64bit, it was created for Itaniums in 2000.... I'm pretty sure it's to reduce the size of the ROM. Even some 64bit UEFI uses 32bit PEI... Also very interesting fact, UEFI 2.0 was released in 2005. Apple starting using EFI 1.10 in 2006...... Which was created for Itanium2s in 2002...

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

I don't know what you mean. EFI has UINTN, it can be 64bit, it was created for Itaniums in 2000.... I'm pretty sure it's to reduce the size of the ROM. Even some 64bit UEFI uses 32bit PEI... Also very interesting fact, UEFI 2.0 was released in 2005. Apple starting using EFI 1.10 in 2006...... Which was created for Itanium2s in 2002...

A datatype does not make a CC (= calling convention)
Link to comment
Share on other sites
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.

Link to comment
Share on other sites
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.
Link to comment
Share on other sites
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

Link to comment
Share on other sites
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.

Link to comment
Share on other sites
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

Link to comment
Share on other sites
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.

Link to comment
Share on other sites
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

Link to comment
Share on other sites
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.

Link to comment
Share on other sites
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
Link to comment
Share on other sites
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....

Link to comment
Share on other sites
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
Link to comment
Share on other sites
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.

Link to comment
Share on other sites
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? ;) )

Link to comment
Share on other sites
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
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...