Contribute
Register

Help with understanding a bootlog.....

Status
Not open for further replies.
Morning @Edhawk

reinstalling all the extra bits - EFI now on system drive -now for testing.......

I read on a xcode developer site this that it is possible to ad a debug string to a kext. This could possibly tell me why the driver Ive been having trouble with isn't activating properly. Do you think its worth a fresh post on this forum to see if anyone knows what to add to the kext to achieve a log?
 
Yes, the fresh post regarding the debug information may help.
 
Hi @Edhawk

Hope you don't mind a further message.
Just a couple of questions I wonder if you can answer?....

I currently have the device audio kext being injected via OC in the kexts folder. Should I be able to see this in Library/Extensions?

Also whilst looking in my system folder I came across these efi files in the pic under system/library/coreservices. It is safe to delete these?
 

Attachments

  • systemlibrary-coreservices.png
    systemlibrary-coreservices.png
    157.2 KB · Views: 29
No you should not see it in /Library/Extensions, if it is only being injected via OpenCore. The only time this kext would show in /L/E is if it is also present in the /L/E folder.

No it is not safe to delete the efi files. I have the same efi files on my system, in the /System/Library/CoreServices folder. They are part of the macOS setup, so not anything to worry about or do anything with, not unless you want to mess up your system.
 
for sure I don't want to mess it up - glad i asked

so the kexts are somewhere in ram if injected via OC? Im confused as to how the system reads these when they arent locatable...
 
Last edited:
OC injects the kexts as part of the boot process, not as part of the kextcache. So the third-party kexts in the /OC/Kexts folder appear in the IOReg, not in the System Information > Extensions report.
 
I have been reading the this thread regarding Thunderbolt 3 Modified Firmware and Custom SSDT, I have got to page 15 of 27 and wish I has seen this thread a few weeks ago. As they are dealing with the same TB3 issues we were dealing with. https://www.tonymacx86.com/threads/thunderbolt-3-modified-firmware-custom-ssdt-discussion.293279/

One thing I did see was they said that using the customised TB header cable was not as good as using a wire spanning from pin 3 to pin 5. They seemed to have issues when using the adapted header connection, with both the Alpine and Titan Ridge cards.

What they do seem to have sorted is the Warm and Cold boot issues you were/are facing. They seem to have this sorted, so it might be worth keeping an eye on any developments arising from this Thread.
 
Hi @Edhawk

Are you certain its 3 and 5 - from memory I thought it was 1 and 3?
Two single pin connector sockets presumably connected to a wire?
 
Yes, it is definitely pins 3 & 5 that need to be connected for the card to work. Easiest way would be two single pin connectors at each end of a loop of wire, as shown in this image.

image-jumper-pin3-pin5-alternate-1.jpg

I never asked but assumed you had the USB header cable connected to the TB card and a spare motherboard USB2 Header port.
 
@Edhawk

yes I do have a usb header connected to the MB . We did discuss this back in the early chapters :)

Been reading the thread you linked.....I also had posted on the other main thread re the designaire board. I had some help re my original ssdt for tb on that page. I also tried the later firmware but found it less reliable than the 23.

I notice that the editor of the 23 firmware contributes to the thread you mention (Elias)

Ive ordered a pegboard jumper cable which will arrive tomorrow ready made to replace the tb connector
 
Last edited:
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top