hwtools for Mavericks and better, DirectHW for macOS Big Sur, superiotool, mptable, osxpmem, iwleeprom, ectool, msrtool, ifdtool, inteltool, nvramtool, pciutils-3.7.0 and Flashrom-1.2

[startergo]

33 minutes ago, Slice said:

Sorry for the stupid question, I didn't understand you.

The problem still exists or it is fixed?

It is fixed now at the @joevt pciutils fork I linked above. Look at the commits. There is a description of the flaw detected. 

Edited January 4, 2023 by startergo

[LockDown]

still not working here with @joevt

Quote

sudo lspci -A darwin     
lspci: darwin_read: kACPIMethodAddressSpaceRead failed: (ipc/send) invalid destination port

 

[startergo]

5 minutes ago, LockDown said:

still not working here with @joevt

 

You need to replace the original files. Find where they are:

where lspci
/usr/local/sbin/lspci

 

git clone https://github.com/joevt/pciutils.git
cd pciutils
make
sudo su
sudo make install
exit
grep -q /usr/local/sbin /etc/paths || sudo sed -e $'1i\\\n/usr/local/sbin\\\n' -i "" /etc/paths

Here is the latest one, which is not yet on GitHub as it includes a new method (darwin2).

lspci.zip

[LockDown]

I did and still the same. thanks for file to test

[LockDown]

Ok, I got it now. I just need to boot with debug=0x144

[joevt]

I don't think the ACPIPlatformExpert method (which I refer to as "darwin" in my pciutils) or the IOPCIBridge method (which I refer to as "darwin2" in my pciutils) check the debug value, so you could use different values such as debug=0100 and it should still work.

 

I can't get either of those two methods to work in 10.11 El Capitan but they do work in earlier macOS versions.

IOPCIBridge method began with 10.10.

I think ACPIPlatformExpert began with 10.6 but I've only tested down to 10.8 recently.

I wonder if the IOPCIBridge method works on Apple Silicon Macs (since they don't have ACPI)? If it does work, it might not work for all devices. In that case, some modification would be required.

 

DirectHW.kext is required for 10.11 and 10.5 and earlier (though I don't think anyone made a build for < 10.9 yet). If the IOPCIBridge method doesn't work for Apple Silicon Macs, then that needs a DirectHW.kext also. PowerPC Macs also require a DirectHW.kext. I think DirectHW.kext should implement a version of the IOPCIBridge method that can work in any macOS version and CPU architecture, since the intel-conf1 method does not allow reading PCIe extended configuration space (registers 0x100 to 0xFFF).

 

[joevt]

On 2/2/2021 at 11:01 AM, Slice said:

Andy, did you see this project?

https://github.com/CloverHackyColor/directhw.git

 

I've noticed a bug in that line of DirectHW forks.

 

Originally, the list of user client methods was this:

kReadIO kWriteIO kPrepareMap kReadMSR kWriteMSR

as seen in these projects/files:

./coreboot-directhw/macosx/DirectHW/DirectHW.c
./coreboot-directhw/macosx/DirectHW/DirectHW.hpp
./dac456-DirectHW/macosx/DirectHW/DirectHW.c
./dac456-DirectHW/macosx/DirectHW/DirectHW.hpp
./flashrom-directhw/macosx/DirectHW/DirectHW.c
./flashrom-directhw/macosx/DirectHW/DirectHW.hpp
./mmalchuk-directhw/macosx/DirectHW/DirectHW.c
./mmalchuk-directhw/macosx/DirectHW/DirectHW.hpp
./mrAlexis-directhw/macosx/DirectHW/DirectHW.c
./mrAlexis-directhw/macosx/DirectHW/DirectHW.hpp
./PureDarwin-DirectHW/DirectHW.c
./PureDarwin-DirectHW/DirectHW.hpp
./startergo-DirectHW-BigSur/DirectHW/DirectHW.c
./startergo-DirectHW-BigSur/DirectHW/DirectHW.hpp
./vampirecat35-DirectHW-BigSur/DirectHW/DirectHW.c
./vampirecat35-DirectHW-BigSur/DirectHW/DirectHW.hpp

Then kReadCpuID and kReadMem were added by Jichao like this:

kReadIO kWriteIO kPrepareMap kReadMSR kWriteMSR kReadCpuID kReadMem

as seen in these projects/files:

./CloverHackyColor-directhw/DirectHW.hpp
./Digits88-directhw/DirectHW.hpp
./Jichao-directhw/macosx/DirectHW/DirectHW.c
./Jichao-directhw/macosx/DirectHW/DirectHW.hpp
./lAbyOne-directhw/DirectHW.hpp
./matatata-directhw/DirectHW.hpp
./mspkg-directhw/DirectHW.hpp
./sigma-1-directhw/DirectHW.hpp
./somestupidgirl-DirectHW-BigSur/DirectHW/DirectHW.c
./somestupidgirl-DirectHW-BigSur/DirectHW/DirectHW.hpp
./warexify-directhw/DirectHW/DirectHW.c
./warexify-directhw/DirectHW/DirectHW.hpp

But notice that that list is missing DirectHW.c for some of those projects. They have the following where kWriteMSR was moved to the end of the list:

kReadIO kWriteIO kPrepareMap kReadMSR kReadCpuID kReadMem kWriteMSR

as seen in these projects/files:

./CloverHackyColor-directhw/DirectHW.c
./Digits88-directhw/DirectHW.c
./lAbyOne-directhw/DirectHW.c
./matatata-directhw/DirectHW.c
./mspkg-directhw/DirectHW.c
./sigma-1-directhw/DirectHW.c

 

so there could be a problem if a framework or library or executable doesn't match the kext and tries to use one of kReadCpuID, kReadMem, kWriteMSR.

 

It probably would have been best for the kext and the framework or library to use a common header for the enumerations and structures used by both.

 

[Slice]

@joevt,

I think the bug should be fixed.

[joevt]

12 hours ago, Slice said:

@joevt,

I think the bug should be fixed.

I'm working on the fork from warexify. It appears to be the fork that was most recently worked on. It has the vampirecat35 fork as upstream. It looks like it might have the best chance to work on ppc and arm64e and i386 and x86_64. To DirectHW I'm adding the IOPCIBridge access method that Apple created in IOPCIFamily for pciutils. This new access method (since macOS 10.10) replaces the ACPIPlatformExpert access method that Apple previously had (since macOS 10.6). Hopefully this access method can be used for ppc (macOS 10.4, 10.5) and arm64e (since macOS 11) by pciutils. My pciutils fork will have all the access methods (darwin for ACPIPlatformExpert; darwin2 for IOPCIBridge; darwin3 for my IOPCIBridge in DirectHW; intel-conf1 which uses the existing DirectHW code). The darwin3 access method will be superior to the intel-conf1 method since it will be able to access all the PCIe config space registers (000-FFF) instead of just the PCI config space registers (00-FF) and it will work with multiple IOPCIHostBridge. Apple Silicon Macs have multiple IOPCIHostBridge. PowerPC Macs also have multiple IOPCIHostBridge. Some Intel Macs may also have multiple IOPCIHostBridge but it seems that in some (all?) cases (such as X299 hackintosh) the PCI bus numbers are divided among them so they the don't have duplicate PCI bus numbers and you can access all the bus numbers from one IOPCIBridge.

[joevt]

I've finished

On 1/11/2023 at 12:55 AM, joevt said:

I'm working on the fork from warexify. It appears to be the fork that was most recently worked on. It has the vampirecat35 fork as upstream. It looks like it might have the best chance to work on ppc and arm64e and i386 and x86_64. To DirectHW I'm adding the IOPCIBridge access method that Apple created in IOPCIFamily for pciutils. This new access method (since macOS 10.10) replaces the ACPIPlatformExpert access method that Apple previously had (since macOS 10.6). Hopefully this access method can be used for ppc (macOS 10.4, 10.5) and arm64e (since macOS 11) by pciutils. My pciutils fork will have all the access methods (darwin for ACPIPlatformExpert; darwin2 for IOPCIBridge; darwin3 for my IOPCIBridge in DirectHW; intel-conf1 which uses the existing DirectHW code). The darwin3 access method will be superior to the intel-conf1 method since it will be able to access all the PCIe config space registers (000-FFF) instead of just the PCI config space registers (00-FF) and it will work with multiple IOPCIHostBridge. Apple Silicon Macs have multiple IOPCIHostBridge. PowerPC Macs also have multiple IOPCIHostBridge. Some Intel Macs may also have multiple IOPCIHostBridge but it seems that in some (all?) cases (such as X299 hackintosh) the PCI bus numbers are divided among them so they the don't have duplicate PCI bus numbers and you can access all the bus numbers from one IOPCIBridge.

I finished the changes:

 https://gist.github.com/joevt/e3cd4ff08aae06279134969c98ca3ab7

 https://github.com/joevt/directhw

 https://github.com/joevt/pciutils

 

[deeveedee]

@joevt  You've been busy lately!  Thank you.