HP Elitebook Folio 1020 and DW1820a

[livacore]

Use diff to compare, then read (PCI specification) about the various offsets that are different.

I planed a blind test without understanding the PCI specification, just patch the data.

FakePCIID can be used as a base (eg. mods required depending on what data you want to spoof) to manipulate/spoof values coming out of PCI_config.

If you determine specifically what needs changing in PCI_config, you can modify FakePCIID to spoof the patched values you want.

After reading `OS-X-Fake-PCI-ID' source code, I learned the trick. But if I wanna patch the whole PCI_config (0xFFF bytes), or even 0xFF bytes, is there a rude way, like hex patch to achieve this? Because I found creating `OS-X-Fake-PCI-Config' is a too huge work only for a blind test. I want confirm the test result effectiveness, then plan to create `OS-X-Fake-PCI-Config.kext'. Thanks.

PS: I think ACPI/DSDT way may easy than creating kext?

 

[RehabMan]

I'm new to PCI specification. Could you point out the PDF url of the specification I need read if you know... Thanks

Google much?

 

[RehabMan]

I planed a blind test without understanding the PCI specification, just patch the data.

Sounds like a mistake.

 

[livacore]

Sounds like a mistake.

I am interesting is there a way other than `OS-X-PCI-Config.kext'...

 

[RehabMan]

I am interesting is there a way other than `OS-X-PCI-Config.kext'...

Modify FakePCIID as necessary for the PCI config data you want to spoof.
Obviously, you will need to understand the PCI spec.

 

[livacore]

Modify FakePCIID as necessary for the PCI config data you want to spoof.
Obviously, you will need to understand the PCI spec.

What do you mean modify? If I only modify the code logic (change PCI-ID operation to PCI_Config), but new kext also name FakePCIID, does this will conflict with existing FakePCIID.kext?
Or I'm going to create a new kext referencing FakePCIID?

 

[RehabMan]

What do you mean modify? If I only modify the code logic (change PCI-ID operation to PCI_Config), but new kext also name FakePCIID, does this will conflict with existing FakePCIID.kext?
Or I'm going to create a new kext referencing FakePCIID?

First you need to determine the PCI config data item (and its offset) you want to spoof.
Then modify the FakePCIID code to allow that.

 

[livacore]

Use diff to compare, then read (PCI specification) about the various offsets that are different.

Found an interesting/strange thing, I install debug version of FakePCIID:

FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00102c30
...
FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0x80) result: 0x18003000

0xb4 offset in pci_config was 3f 2c 10 00, but print 0x00102c30.
0x80 offset in pci_config was 80: 00 10 00 18, but print 0x18003000.
Why change....

Keep at 0xb4 offset, why get 4 different value...

FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00102c30
FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00102c3f
FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00103c3f
FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x01010000, 0xb4) result: 0x10031003

HP EliteBook 1030 G1 PCI_config:

ARPT: 8.826268: saveDeviceState: device[0x5e42ab6e2bc4d665], override[0]
ARPT: 8.837902: saveDeviceState: dump of cached config-space
ARPT: 8.848651:
    00: e4 14 a3 43 06 04 10 00 08 00 80 02 00 00 00 00
    10: 04 00 40 e1 00 00 00 00 04 00 00 e1 00 00 00 00
    20: 00 00 00 00 00 00 00 00 00 00 00 00 6b 10 34 01
    30: 00 00 00 00 48 00 00 00 00 00 00 00 10 01 00 00
    40: 00 00 00 00 00 00 00 00 01 58 03 fe 08 40 00 00
    50: 00 00 00 00 00 00 00 00 05 68 89 00 00 00 e0 fe
    60: 00 00 00 00 79 40 00 00 09 ac 44 00 0b 01 00 00
    70: 00 10 10 18 00 00 00 00 00 e0 10 18 00 00 00 00
    80: 00 10 00 18 00 00 00 00 80 00 00 00 00 00 00 00
    90: 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00
    A0: 00 00 00 00 00 00 00 00 40 00 01 00 10 00 02 00
    B0: 81 8f 90 05 3f 2c 10 00 11 dc 46 00 42 01 11 10
    C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    D0: 1f 08 08 00 00 04 00 00 00 00 00 00 01 00 01 00
    E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ARPT: 9.018821: kIOMessageDeviceWillPowerOff
ARPT: 9.027668: kIOMessageDeviceHasPoweredOff
ARPT: 9.036146: wl0: Broadcom BCM43a3, vendorID[0x14e4] BAR0[0xe1400004]

 

[RehabMan]

Found an interesting/strange thing, I install debug version of FakePCIID:

FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00102c30
...
FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0x80) result: 0x18003000

0xb4 offset in pci_config was 3f 2c 10 00, but print 0x00102c30.
0x80 offset in pci_config was 80: 00 10 00 18, but print 0x18003000.
Why change....

What do you mean by "was"? When did you see the other values? How?

Keep at 0xb4 offset, why get 4 different value...

FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00102c30
FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00102c3f
FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x00010000, 0xb4) result: 0x00103c3f
FakePCIID.txt:FakePCIID: [14e4:43a3] configRead32 address space(0x01010000, 0xb4) result: 0x10031003

It means the value is changing.

 

[livacore]

What do you mean by "was"? When did you see the other values? How?

It means the value is changing.

Sorry, non English primary people, wrong tense usage.

Please the last quote of #98 (the original PCI_config dump).