Jump to content
8755 posts in this topic

Recommended Posts

On 10/16/2020 at 2:40 PM, Download-Fritz said:

1) You can try tightening optimisation step-by-step (i.e. O1, O2, ...) and once it breaks, try to find the offending module and bin-diff

 

EDITED

It seems both debug and release are built with -Os, so it seems it's not an optimization issue.

 

Invalid info :(

 

All I can say is that files work properly with clang 9.0.0 and 12.0.0 and do not work properly with clang 7.0.0

 

Personal note: the world needs more Download-Fritz and vit9696! it should be a better world!!It's clearly seen in opencore, not only "it just works" as most users are finding, order and precision are all over the code and I appreciate it a lot.

Edited by ghost8282

Something is wrong with this description I am afraid. You should not be able to build any binary at all without running make -C BaseTools. Maybe you had some older tools compiled in some other directory out of the tree (i.e. outside of edk2 directory), and they were used instead of the ones you checked out?

  • Like 2
2 hours ago, vit9696 said:

Something is wrong with this description I am afraid. You should not be able to build any binary at all without running make -C BaseTools. Maybe you had some older tools compiled in some other directory out of the tree (i.e. outside of edk2 directory), and they were used instead of the ones you checked out?

 

I think no, if I look at the log made with clang 7.0.0, it seems basetools are automatically compiled from edk2 directory when I run "nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)", but maybe I'm not reading the log correctly.

This doesn't happen with other toolchains.

Moreover, if I had already installed BaseTools somewhere why only clang 7.0.0 has problem?

I mean, I used clang 9.0.0 before clang 7.0.0 and clang 9.0.0 threw error about compiling BaseTools first.

For me it's a mistery :)

 

log-macOs.txt.zip

Edited by ghost8282
  • Like 1
11 minutes ago, ghost8282 said:

This doesn't happen with other toolchains.

What do you mean by "doesn't happen"? The command does nothing when executed? Nothing logged either? What happens when you do not include "-j $(getconf _NPROCESSORS_ONLN)"? Does $EDK_TOOLS_PATH evaluate properly?

 

I wonder whether multithreaded BaseTools building is broken, but vit uses it...

Edited by Download-Fritz
  • Like 2
2 hours ago, Download-Fritz said:

What do you mean by "doesn't happen"?

 

Sorry, I mean that with clang 9 and 12 I must run "make -C BaseTools" before "source edksetup.sh" / "nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)".

 

With clang 7: no errors about BaseTools (no command "make -C BaseTools" needed), so at the beginning I was not running "make -C BaseTools" and from what I can understand BaseTools are compiled with "nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)".

 

I'm starting from the beginning again saving all the logs now.

 

Update: I modify my post above with correct informations and I'm going to upload the logs in a next post.

 

Edited by ghost8282

Tried 3 tests with more calm and step by step instructions:

all I can say is that clang 7.0.0 is not generating properly the files, so my post above was totally wrong with invalid steps (I edited it).

 

Test 1: clang 12.0.0 - Files OK

Test 2: clang 7.0.0 - Files NOT ok

Test 3: clang 7.0.0 - Files NOT ok

 

Everytime I deleted edk2 folder and started new.

 

By "files NOT ok" I mean I cannot boot without hdmi plugged in (I can't boot only with dvi, I can only boot with hdmi or hdmi+dvi)

 

Commands for tests 1 and 2:

$ git clone https://github.com/tianocore/edk2.git
$ cd edk2
$ git clean -ffdx
$ git reset --hard
$ git submodule deinit --force --all
$ git checkout edk2-stable202008
$ git submodule update --init --force
$ source edksetup.sh
$ nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)
$ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t XCODE5

Commands for test 3:

$ git clone https://github.com/tianocore/edk2.git
$ cd edk2
$ git clean -ffdx
$ git reset --hard
$ git submodule deinit --force --all
$ git checkout edk2-stable202008
$ git submodule update --init --force
$ make -C BaseTools/
$ source edksetup.sh
$ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t XCODE5

Logs attached.

So, nothing new, need to go with Download-Fritz step 2 or vit9696 suggestions dho! :D

 

Sorry, maybe I didn't restart libvirtd to use the files generated by clang 7.0.0.

I will make more tests in the next days.

Clang7-test3-log.txt.zip

Clang7-test2-log.txt.zip

Clang12-test1-log.txt.zip

1 hour ago, mifjpn said:

I am grateful to the development team for their daily efforts.

There are the following problems.

Start Windows, then restart.

When I hold down the DEL key and reboot, the BIOS screen does not appear.

Black screen only.

The only way to get this back back is to flash the BIOS again.

This issue occurs on the ASUS PRIME H370-A (i7 8700). (BIOS is up to date)

Is there anyone with the same problem?

Thank you.

Try setting Misc->Security->BootProtect to None (likely is Bootstrap right now). Haven't seen this issue occur in H370 before though - usually just Z87/Z97

Edit: https://github.com/acidanthera/bugtracker/issues/1222

I think that's the relevant issue on the bugtracker.

Edited by 1Revenger1
  • Like 1
  • Thanks 2
11 hours ago, Download-Fritz said:

@ghost8282 Interesting, but what if you run make with 7 and build with 12?

 

Files are OK!

 

Test4: make with clang 7.0.0, build with clang 12.0.0

 

With clang 7.0.0:

$ git clone https://github.com/tianocore/edk2.git
$ cd edk2
$ git clean -ffdx
$ git reset --hard
$ git submodule deinit --force --all
$ git checkout edk2-stable202008
$ git submodule update --init --force
$ make -C BaseTools/

Switch to clang 12.0.0:

$ source edksetup.sh
$ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t XCODE5

 

NO gpu issue, tianocore logo not appearing but this was expected.

 

So this means it's the build command having issues with clang 7.0.0

Test4-make-clang7-build-clang12.txt.zip

Edited by ghost8282
  • Like 1

Hi @vit9696 @Download-Fritz

 

I've this message when I compile commit. Can you explain to me, what I'm doing wrong. Please.

From https://github.com/openssl/openssl
   b40498c6e7..6c8149df1f  master     -> origin/master
Could not access submodule 'boringssl'Could not access submodule 'krb5'Could not access submodule 'pyca-cryptography'Fetching submodule MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
Could not access submodule 'research/esaxx'Could not access submodule 'research/libdivsufsort'Fetching submodule MdeModulePkg/Universal/RegularExpressionDxe/oniguruma

 

On 10/16/2020 at 1:07 PM, ghost8282 said:

Because it boots from the snapshot, and it is not sometimes, but always (I think from beta 7-8).

 

and this issue can't be fixed by OpenCore ?

 

@vit9696 can you explain the issue in more detail ?

  • Confused 1

@Download-Fritz @vit9696 i need your help

Device name

Dell XPS 13 7390
Processor : Intel Core i7 10710U

the problem is always stuck at ExitBSStart:xxx

I have tried using combination
AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
RebuildAppleMemoryMap = Yes
SyncRuntimePermissions = Yes

and 


AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
SetupVirtualMap = Yes
SyncRuntimePermissions = Yes

 

I have tried to use "ForceExitBootServices=Yes" for both combination above with no result, still can't bypass the error.
i have installed Commetlake platform for HP and Asus and never see this problem,,
image.thumb.png.841a1c3f5a73ab0c87b834f017ff87e0.png
I attach debug output
 

 

opencore-2020-10-06-235644.txt

config.plist

Edited by Andres ZeroCross
1 hour ago, Andres ZeroCross said:

@Download-Fritz @vit9696 i need your help

Device name

Dell XPS 13 7390
Processor : Intel Core i7 10710U

the problem is always stuck at ExitBSStart:xxx

I have tried using combination
AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
RebuildAppleMemoryMap = Yes
SyncRuntimePermissions = Yes

and 


AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
SetupVirtualMap = Yes
SyncRuntimePermissions = Yes


10000 series laptops/devices can have issues with SetupVirtualMap - I'd try both combos with it disabled.

Hello!
Currently running 0.63 nightly with a Mald0n DSDT.
Been using OpenCore since 0.58

I have Window10 on a separate NVMe drive that is bootable thanks to bootstrap.efi

Has OpenCore reached the state of development where we can make Windows ignore the DSDT?
The reason I ask:
When I avoid the OpenCore boot entry and boot to the Windows Boot Manager directly, everything works as expected in Windows
When I boot to windows via OpenCore, the only thing that does not work is my onboard audio and Device Manager in Windows states there are not enough resources to load that driver correctly.

Edited by Musicalchairs
8 minutes ago, Musicalchairs said:

Has OpenCore reached the state of development where we can make Windows ignore the DSDT?

This has nothing to do with "stage of development", infact such a quirk existed before and was deprecated after the documentations were refined enough to not need it anymore.

9 minutes ago, Musicalchairs said:

When I boot to windows via OpenCore, the only thing that does not work is my onboard audio and Device Manager in Windows states there are not enough resources to load that driver correctly.

You probably have some weird patch you do not even really need. OC really is made for the "minimal SSDT" approach where you leave DSDT alone and add a minimal amount of conditional SSDTs.

2 minutes ago, Download-Fritz said:

This has nothing to do with "stage of development", infact such a quirk existed before and was deprecated after the documentations were refined enough to not need it anymore.

You probably have some weird patch you do not even really need. OC really is made for the "minimal SSDT" approach where you leave DSDT alone and add a minimal amount of conditional SSDTs.

Good info, Thank you!
Suspected it was something in my DSDT that did not need to be there (or the DSDT itself should be removed and I should attempt to reach zero ACPI errors with SSDT only.
 

  • Like 1

670341648_ScreenShot2020-10-24at04_13_43.thumb.png.d97b4d712fb8c80dbfc065d10ab6d51d.png

On 10/22/2020 at 11:16 PM, Download-Fritz said:

This has nothing to do with "stage of development", infact such a quirk existed before and was deprecated after the documentations were refined enough to not need it anymore.

You probably have some weird patch you do not even really need. OC really is made for the "minimal SSDT" approach where you leave DSDT alone and add a minimal amount of conditional SSDTs.


Challenge accepted:
DSDT free now after challenging myself to read the https://dortania.github.io/OpenCore-Post-Install/
opencore-2020-10-24-v0.63-Debug-SSDT's_Only+USBMap.kext&SATA-unsupported.kext for System Information cosmetic reasons only.
Windows 10 now acts as though it isn't living alongside macOS.
*Removed all personal info from PlatformInfo

 

1447426960_ScreenShot2020-10-24at10_19_50.thumb.png.f313b06b8f59b85d09026d0947ef83c4.png 1054718989_ScreenShot2020-10-24at10_27_53.thumb.png.6ed5b4bddcf6584df6a2a21e0e873b57.png

EFI.zip

Edited by Musicalchairs
Cleaned it up a bit more by separating SSDT-EXT.aml into what was actually needed if I am not concerned about the cosmetic appearance of System Profiler
  • Like 1
1 hour ago, Stefanalmare said:

Hi all! Does anybody have empty grey screen on recovery BS beta 10? It happen on my HP Probook 4540s. Just on beta 10.

 

6 minutes ago, eSaF said:

Did you fill in the Language Section in the config.plist? If left blank will sometimes hang and cause a grey screen.

 

It's a Apple "Bug": all the forums talk about this. Beta 10 comes with US English only for recovery mode, for a clean installation. So you have to choose only this language.

Edited by Matgen84
  • Like 2

And remember to clean in the config.plist the prev-lang:kbd field.

 

Oh sorry just read better esaf comment: in my case if language is forced in the config.plist (other than english) grey screen; if left empty all is ok (and choosing english in the language selector).

Edited by ghost8282
  • Like 2
4 hours ago, Matgen84 said:

 

 

It's a Apple "Bug": all the forums talk about this. Beta 10 comes with US English only for recovery mode, for a clean installation. So you have to choose only this language.

Nope! I changed to 656E5F55 533A30 - en_US:0, and the same. Recovery = gray screen. I do something wrong?

×
×
  • Create New...