Clover Problems and Solutions

[joevt]

I'm adding a couple other methods for finding/accessing SMBus devices. Maybe one of them will work. I've also added an SMBus scanner to get a list of slaves on an SMBus.

I've attached a new spd.c with the mentioned changes. The other methods are:

1) Find and use EFI SMBus Host Control protocol.

2) Find hidden SMBus PCI devices by scanning PCI config space, then use the standard PCI I/O space method to access them.

 

All three methods can scan the SMBus for all slave addresses.

 

The defines are currently setup to get information from dgsga or anyone else with a computer that Clover can't read spd from. In a release version, I would change the defines to the following:

 

#define DEBUGSPD 0
#define TIMEOUTONERR 0
#define DOSMBSCAN 0

#define STOPAFTERFIRSTSMBUS 1

#define DOSCANPCIPROTOCOLS 1
#define DOSCANSMBUSPROTOCOLS 1
#define DOSCANPCICONFIG 1
#define DOSCANOTHERDEVICES 0

spd.c.zip

[Slice]

May be you will upload debug version of CloverX64.efi with output interesting for you?

[joevt]

I've attached a new spd.c with the mentioned changes. The other methods are:

 

 

May be you will upload debug version of CloverX64.efi with output interesting for you?

Here it is. Boot time might take an extra 30 seconds depending on your system.

 

For me, every DBG statement in the debug.log takes at least 16 ms after "Custom boot CUSTOM_BOOT_DISABLED (0x0)". That must be a bug. It might be caused by one of the settings in my config.plist. I'll have to check how the DBG works.

BOOTX64.efi.zip

[Slice]

DBG(if set to 2) open file debug.log, add new line and then save the file back. Yes, it is slow, but it needed to save last line before hang.

if set to 1 then the log will be accumulated into memory and saved into device-tree where system can extract it by script or by bdmesg utility.

[droples]

 

 

 

Here it is. Boot time might take an extra 30 seconds depending on your system.

 

For me, every DBG statement in the debug.log takes at least 16 ms after "Custom boot CUSTOM_BOOT_DISABLED (0x0)". That must be a bug. It might be caused by one of the settings in my config.plist. I'll have to check how the DBG works.

 

If this is what you need

Legacy mode (CloverX64.efi)

 

 

1:150  0:000  ScanSPD() start
1:150  0:000  [ scan handles for Host Bridge / DRAM Controller start
1:150  0:000  PCI 0 (00 00 00) : 8086 0100 class=060000
1:150  0:000  PCIEXBAR=F8000005
1:151  0:000  ] scan handles for Host Bridge / DRAM Controller end
1:151  0:000  [ scan handles for PCI protocol SMBus device start
1:151  0:000  PCI F80FB000 (00 1F 03) : 8086 1E22 class=0C0500
1:151  0:000  SMBus config (efi):        :1E228086028000030C05000400000000F7F110040000000000000000000000000000F00100000000000000005001145800000000000000000000000000000303
1:151  0:000  SMBus config (mem):F80FB000:1E228086028000030C05000400000000F7F110040000000000000000000000000000F0010000000000000000500114580000000000000000000000000000030300000001
1:151  0:000  SMBus PCICmdReg: 0x3
1:151  0:000  Scanning SMBus [8086:1E22], mmio: 0x0.F7F11004, ioport: 0xF000, hostc: 0x1
1:151  0:000  [ smb_scan_bus() start
1:192  0:041  found device 0x10: word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:227  0:034  found device 0x15: word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:248  0:021  found device 0x30: receive:FF byte:FF word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:257  0:008  found device 0x32: receive:FF byte:FF word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:273  0:016  found device 0x44: receive:FF byte:00 word:FF00 block:00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:282  0:009  found device 0x50: receive:00 byte:92 word:1192 block:92110B0204210009031101080A00FC00697869
1:286  0:004  found device 0x52: receive:00 byte:92 word:1192 block:92110B0204210009031101080A00FC00697869
1:309  0:022  ] smb_scan_bus() end
1:309  0:000  [ Scanning 8 slots start
1:310  0:000  SPD[0]: Type 11 @0x50
1:328  0:018  DDR speed 1600MHz
1:328  0:000  Slot: 0 Type 24 8192MB 1600MHz Vendor=Kingston PartNo=99U5471-037.A00LF SerialNo=070A03050E0D0409
1:329  0:000  SPD[2]: Type 11 @0x52
1:347  0:018  DDR speed 1600MHz
1:347  0:000  Slot: 2 Type 24 8192MB 1600MHz Vendor=Kingston PartNo=99U5471-037.A00LF SerialNo=070403050F060409
1:348  0:000  ] Scanning 8 slots end; found 2 modules.
1:348  0:000  ] scan handles for PCI protocol SMBus device end
1:348  0:000  [ scan handles for SMBus protocol start
1:348  0:000  ] scan handles for SMBus protocol end
1:348  0:000  [ scan handles for SPSR device start
1:348  0:000  ] scan handles for SPSR device end
1:348  0:000  [ scan PCI config space F8000005 for SMBus devices (64 possible PCI buses) start
1:350  0:002  PCI F80FB000 (00 1F 03) : 8086 1E22 class=0C0500
1:350  0:000  SMBus config (mem):F80FB000:1E228086028000030C05000400000000F7F110040000000000000000000000000000F0010000000000000000500114580000000000000000000000000000030300000001
1:350  0:000  SMBus PCICmdReg: 0x3
1:350  0:000  Scanning SMBus [8086:1E22], mmio: 0x0.F7F11004, ioport: 0xF000, hostc: 0x1
1:350  0:000  [ smb_scan_bus() start
1:391  0:041  found device 0x10: word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:428  0:036  found device 0x15: word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:449  0:021  found device 0x30: receive:FF byte:FF word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:458  0:008  found device 0x32: receive:FF byte:FF word:FFFF block:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:475  0:016  found device 0x44: receive:FF byte:00 word:FF00 block:00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1:484  0:009  found device 0x50: receive:00 byte:92 word:1192 block:92110B0204210009031101080A00FC00697869
1:488  0:004  found device 0x52: receive:00 byte:92 word:1192 block:92110B0204210009031101080A00FC00697869
1:511  0:022  ] smb_scan_bus() end
1:511  0:000  [ Scanning 8 slots start
1:511  0:000  SPD[0]: Type 11 @0x50
1:529  0:018  DDR speed 1600MHz
1:529  0:000  Slot: 0 Type 24 8192MB 1600MHz Vendor=Kingston PartNo=99U5471-037.A00LF SerialNo=070A03050E0D0409
1:530  0:000  SPD[2]: Type 11 @0x52
1:548  0:018  DDR speed 1600MHz
1:548  0:000  Slot: 2 Type 24 8192MB 1600MHz Vendor=Kingston PartNo=99U5471-037.A00LF SerialNo=070403050F060409
1:549  0:000  ] Scanning 8 slots end; found 2 modules.
1:709  0:159  ] scan PCI config space for SMBus devices end
1:709  0:000  ScanSPD() end 

 

 

 

UEFI mode BOOTX64.efi (OsxAptioFixDrv.efi or OsxAptioFix2Drv.efi)

 

After 15 minutes of waiting, nothing changes.

[dgsga]

@joevt Still no joy. The modules do not want to be found  . I compiled the latest rev using your new spd.c posted above. The SMBus config (mem): output looks dodgy...

0:262  0:000  ScanSPD() start
0:262  0:000  [ scan handles for Host Bridge / DRAM Controller start
0:262  0:000  PCI 0 (00 00 00) : 8086 2F00 class=060000
0:262  0:000  PCIEXBAR=1029005
0:262  0:000  ] scan handles for Host Bridge / DRAM Controller end
0:262  0:000  [ scan handles for PCI protocol SMBus device start
0:262  0:000  PCI FB000 (00 1F 03) : 8086 8D22 class=0C0500
0:262  0:000  SMBus config (efi):        :8D228086028000030C05000500000000FB13500400000000000000000000000000000581000000000000000086001043000000000000000000000000000003FF
0:262  0:000  SMBus config (mem):FB000:A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5
0:262  0:000  SMBus PCICmdReg: 0x3
0:262  0:000  Scanning SMBus [8086:8D22], mmio: 0x0.FB135004, ioport: 0x580, hostc: 0x1
0:262  0:000  [ Scanning 8 slots start
0:263  0:001  ] Scanning 8 slots end; found 0 modules.
0:263  0:000  ] scan handles for PCI protocol SMBus device end
0:263  0:000  [ scan handles for SMBus protocol start
0:263  0:000  Scanning SMBus [0000:0000], mmio: 0x0.00000000, ioport: 0x0, hostc: 0x0
0:263  0:000  [ Scanning 8 slots start
0:265  0:001  ] Scanning 8 slots end; found 0 modules.
0:265  0:000  ] scan handles for SMBus protocol end
0:265  0:000  [ scan PCI config space 1029005 for SMBus devices (64 possible PCI buses) start
0:266  0:001  ] scan PCI config space for SMBus devices end
0:266  0:000  ScanSPD() end

[joevt]

If this is what you need

Legacy mode (CloverX64.efi)

 

 

1:150  0:000  ScanSPD() start
...
1:709  0:000  ScanSPD() end 

 

That is the expected output except for not having an SMBus protocol, but your DDR is detected so you don't need the SMBus protocol.

 

UEFI mode BOOTX64.efi (OsxAptioFixDrv.efi or OsxAptioFix2Drv.efi)

After 15 minutes of waiting, nothing changes.

I've tested UEFI with no problem so this is strange. There should be a log up to the point where it fails?

 

 

@joevt Still no joy. The modules do not want to be found  . I compiled the latest rev using your new spd.c posted above. The SMBus config men output looks dodgy...

0:262  0:000  ScanSPD() start
0:262  0:000  [ scan handles for Host Bridge / DRAM Controller start
0:262  0:000  PCI 0 (00 00 00) : 8086 2F00 class=060000
0:262  0:000  PCIEXBAR=1029005
0:262  0:000  ] scan handles for Host Bridge / DRAM Controller end
0:262  0:000  [ scan handles for PCI protocol SMBus device start
0:262  0:000  PCI FB000 (00 1F 03) : 8086 8D22 class=0C0500
0:262  0:000  SMBus config (efi):        :8D228086028000030C05000500000000FB13500400000000000000000000000000000581000000000000000086001043000000000000000000000000000003FF
0:262  0:000  SMBus config (mem):FB000:A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5
0:262  0:000  SMBus PCICmdReg: 0x3
0:262  0:000  Scanning SMBus [8086:8D22], mmio: 0x0.FB135004, ioport: 0x580, hostc: 0x1

 

PCIEXBAR is wrong. I'm reading it from the wrong device or location. You haven't sent a full ioreg or clover log, so I don't know what device to look at. I'll replace it all by using PCILib anyway. You're output is missing "smb_scan_bus() start ... end". Did you change the defines? For testing, they should be at least:

#define DEBUGSPD 0 // show status changes
#define TIMEOUTONERR 0 // related to DEBUGSPD; disable this to eliminate extraneous waits.
#define DOSMBSCAN 1 // show all slave addresses on each SMBus

#define STOPAFTERFIRSTSMBUS 0 // Stop scanning after finding the first SMBus that has RAM modules. Disable this to test all methods.

#define DOSCANPCIPROTOCOLS 1 // Use PCI protocol to control SMBus type devices.
#define DOSCANSMBUSPROTOCOLS 1 // Use built in EFI SMBus protocol to read SMBus slaves.
#define DOSCANPCICONFIG 1 // Scan PCI config space for SMBus devices. Disable this if scanning PCI config space is scary.
#define DOSCANOTHERDEVICES 1 // Use PCI protocol to get information about other devices of interest for debugging purposes.

[dgsga]

That is the expected output except for not having an SMBus protocol, but your DDR is detected so you don't need the SMBus protocol.

 

I've tested UEFI with no problem so this is strange. There should be a log up to the point where it fails?

 

 

PCIEXBAR is wrong. I'm reading it from the wrong device or location. You haven't sent a full ioreg or clover log, so I don't know what device to look at. I'll replace it all by using PCILib anyway. You're output is missing "smb_scan_bus() start ... end". Did you change the defines? For testing, they should be at least:

#define DEBUGSPD 0 // show status changes
#define TIMEOUTONERR 0 // related to DEBUGSPD; disable this to eliminate extraneous waits.
#define DOSMBSCAN 1 // show all slave addresses on each SMBus

#define STOPAFTERFIRSTSMBUS 0 // Stop scanning after finding the first SMBus that has RAM modules. Disable this to test all methods.

#define DOSCANPCIPROTOCOLS 1 // Use PCI protocol to control SMBus type devices.
#define DOSCANSMBUSPROTOCOLS 1 // Use built in EFI SMBus protocol to read SMBus slaves.
#define DOSCANPCICONFIG 1 // Scan PCI config space for SMBus devices. Disable this if scanning PCI config space is scary.
#define DOSCANOTHERDEVICES 1 // Use PCI protocol to get information about other devices of interest for debugging purposes.

Defines untouched, attached is full clover log and ioreg  

bdmesg.txt.zip

ioreg.txt.zip

[joevt]

That is the expected output except for not having an SMBus protocol, but your DDR is detected so you don't need the SMBus protocol.

Actually, since it's Legacy, I wouldn't expect there to be an SMBus protocol since in that case there is no UEFI with built-in protocols and any protocols that do exist are installed by Clover which doesn't have an SMBus protocol. There is code (.h and .c) in the source that could be turned into an SMBus protocol with some extra work but I don't think that would add anything to Clover.

 

So then in your UEFI case, maybe the SMBus protocol is causing the problem. You could try "#define DOSCANSMBUSPROTOCOLS 0" or "#define STOPAFTERFIRSTSMBUS 1" to skip that. I could try making that part more robust (maybe the protocol is clobbering the stack - but only if it was poorly written...).

 

Or maybe the protocol has a long timeout, and the scan bus routine which tries all 128 slave addresses is taking a long time. In that case, you could try "#define DOSMBSCAN 0". I will add a test of the timeout, and abort the scan if it takes longer than a second per slave.

[joevt]

PCIEXBAR is wrong. ... I'll replace it all by using PCILib anyway.

 

So then in your UEFI case, maybe the SMBus protocol is causing the problem. ... I could try making that part more robust (maybe the protocol is clobbering the stack - but only if it was poorly written...).

 

Or maybe the protocol has a long timeout, and the scan bus routine which tries all 128 slave addresses is taking a long time. ... I will add a test of the timeout, and abort the scan if it takes longer than a second per slave.

Here are the changes.

BOOTX64.efi.zip

spd.c.zip

[dgsga]

 

 

Here are the changes.

 

Thanks joevt. I tried the new spd.c, it gives the attached output. The smbus scan finds the 'empty' smbus#0 device at 44h but not the SPD EEPROMS at 50h-57h. Some progress though as SMBus config (mem): output now appears good. It's certainly putting up a fight!

bdmesg.txt.zip

[joevt]

Thanks joevt. I tried the new spd.c, it gives the attached output. The smbus scan finds the 'empty' smbus#0 device at 44h but not the SPD EEPROMS at 50h-57h. Some progress though as SMBus config (mem): output now appears good. It's certainly putting up a fight!

Everything looks good now, except your output is missing the SPSR information. There should be a line in the log that says "[ scan handles for SPSR device start"

 

Can you make sure "#define DOSCANOTHERDEVICES 1" is in the spd.c file instead of "#define DOSCANOTHERDEVICES 0" and then recompile. I want to know what the current register values are before we try to change them.

[dgsga]

When I set #define DOSCANOTHERDEVICES 1 Clover hangs at a black screen before the GUI appears. I left it for more than 2 minutes but no luck, have to press ctrl alt delete to restart

[joevt]

When I set #define DOSCANOTHERDEVICES = 1 Clover hangs at a black screen before the GUI appears. I left it for more than 2 minutes but no luck, have to press ctrl alt delete to restart

Was there anything in the log that shows when it stopped? I would expect at least the "[ scan handles for SPSR device start" line to be in there. Then after that the config address, bus, device, and function numbers, vendor and device IDs, and class code "PCI 000F8000 (1F 00 00) : 8086 8D22 class=FF0000". Then after that a dump of the SPSR config registers using PciIo (efi) and then using PCILib (mem).

 

Try commenting out the following lines:

    dump_device("MS SMBus 0", &gPci, PCI_LIB_ADDRESS(Bus, Device, 1, 0), 0x44);
    dump_device("MS SMBus 1", &gPci, PCI_LIB_ADDRESS(Bus, Device, 2, 0), 0x44);
    dump_device("MS SMBus 2", &gPci, PCI_LIB_ADDRESS(Bus, Device, 3, 0), 0x44);

Actually, "&gPci" should be changed to "NULL" in those three lines, but that isn't causing the crash.

 

If that doesn't work then also change 0x184 to a smaller number such as 0xEA or 0xD8. I want to know the register value of 0xD4 (MSDEVFUNCHIDE : MS Unit Device Function Hide Register), but if that still causes a crash, then lower it to 0x86 which is the end of the PCI Express capabilities registers for that device. 0x40 is the end of the old PCI registers.

 

If changing 0x184 works, then uncomment the "dump_device("MS SMBus 0" ..." lines to see if they'll work now. If those still don't work, then you can try adding the following line after "dump_device("SPSR..."

PciWrite32(PCIConfig + 0xD4, 0);

If that makes the "dump_device("MS SMBus..." lines work and the dumps look like an SMBus device, then the DoScanPCIConfig routine that gets executed later should be able to scan those SMBuses.

 

 

There is a utility called PCIScope from Apsoft which can also show devices and registers. You can try the trial version. You might need to set "DetectAPIC = 0" in the config.ini file. You can examine device 00:1F:00, register D4-D7. I think the default value is 0000000E. You can set a watch on D4. Then run Thaiphoon Burner and scan the SMBuses, and see if the watch value in PCIScope changes. You can also use PCIScope to look for a hidden device at 00:1F:01 or 00:1F:02 or 00:1F:03.

You could also use PCIScope to change the MSDEVFUNCHIDE register, and see if the hidden devices (function 1,2,3) show up. You can use PCIScope to save a .BPD file so I can examine it.

[Slice]

Looks like Clover bugs.

1. Attempt to boot Windows with ../WINDOWS/SLIC.aml leads to red panic.

2. VBoxISO9660 is not working correctly since some revision. I study now.

[dgsga]

Was there anything in the log that shows when it stopped? I would expect at least the "[ scan handles for SPSR device start" line to be in there. Then after that the config address, bus, device, and function numbers, vendor and device IDs, and class code "PCI 000F8000 (1F 00 00) : 8086 8D22 class=FF0000". Then after that a dump of the SPSR config registers using PciIo (efi) and then using PCILib (mem).

 

Try commenting out the following lines:

    dump_device("MS SMBus 0", &gPci, PCI_LIB_ADDRESS(Bus, Device, 1, 0), 0x44);
    dump_device("MS SMBus 1", &gPci, PCI_LIB_ADDRESS(Bus, Device, 2, 0), 0x44);
    dump_device("MS SMBus 2", &gPci, PCI_LIB_ADDRESS(Bus, Device, 3, 0), 0x44);

Actually, "&gPci" should be changed to "NULL" in those three lines, but that isn't causing the crash.

 

If that doesn't work then also change 0x184 to a smaller number such as 0xEA or 0xD8. I want to know the register value of 0xD4 (MSDEVFUNCHIDE : MS Unit Device Function Hide Register), but if that still causes a crash, then lower it to 0x86 which is the end of the PCI Express capabilities registers for that device. 0x40 is the end of the old PCI registers.

 

If changing 0x184 works, then uncomment the "dump_device("MS SMBus 0" ..." lines to see if they'll work now. If those still don't work, then you can try adding the following line after "dump_device("SPSR..."

PciWrite32(PCIConfig + 0xD4, 0);

If that makes the "dump_device("MS SMBus..." lines work and the dumps look like an SMBus device, then the DoScanPCIConfig routine that gets executed later should be able to scan those SMBuses.

 

 

There is a utility called PCIScope from Apsoft which can also show devices and registers. You can try the trial version. You might need to set "DetectAPIC = 0" in the config.ini file. You can examine device 00:1F:00, register D4-D7. I think the default value is 0000000E. You can set a watch on D4. Then run Thaiphoon Burner and scan the SMBuses, and see if the watch value in PCIScope changes. You can also use PCIScope to look for a hidden device at 00:1F:01 or 00:1F:02 or 00:1F:03.

You could also use PCIScope to change the MSDEVFUNCHIDE register, and see if the hidden devices (function 1,2,3) show up. You can use PCIScope to save a .BPD file so I can examine it.

 

@joevt

In a nutshell commenting out the three lines and using any value for dump_device SPSR causes the hang, no boot log recorded. Unfortunately ACPIScope also causes a hang on my version of Windows 10. Sorry I can't be more helpful... I also found this in the updated x99 spec from Intel. Look at Errata number 26...Its an unfixed bug with the chipset so don't wish to waste your time 

errata.tiff

[joevt]

@joevt

In a nutshell commenting out the three lines and using any value for dump_device SPSR causes the hang, no boot log recorded. Unfortunately ACPIScope also causes a hang on my version of Windows 10. Sorry I can't be more helpful... I also found this in the updated x99 spec from Intel. Look at Errata number 26...Its an unfixed bug with the chipset so don't wish to waste your time 

Well you know what you have to try next. Comment out the "dump_device("SPSR..." line and see if the "dump_device("MS SMBus..." lines work with or without the PciWrite32 line.

 

Also, I said to use PCIScope, not ACPIScope. Before launching PCIScope, change the permissions on CUSTOM.INI file so you can edit it. Find "DetectAPIC = 1" and change it to "DetectAPIC = 0". Without that change I get a BSOD on my computer.

[dgsga]

Oops, I meant PCIScope. This freezes Windows 10 even with DetectAPIC=0.

"dump_device MS SMBus..." lines work in neither case 

[joevt]

Oops, I meant PCIScope. This freezes Windows 10 even with DetectAPIC=0.

"dump_device MS SMBus..." lines work in neither case 

There are other Detect options in the CUSTOM.INI that you can try to disable one at a time until it works (everything except DetectPci, then DetectPci if that also fails...). There's a ExcludeDevices line that you can uncomment, remove their examples, and add 1F:00:00 so the SPSR device isn't scanned to see if that device is a problem. If it is, then the SKIPRNG.INI file can be edited to skip certain registers (I believe the ranges are decimal numbers of the register addresses divided by 4), so to skip 0x40-0xD3, you would enter 16-52 as one range and 54-1023 for 0xD8 to 0xFFF.

 

Does Clover boot with dump_device "SPSR" commented out? If so then send the log. If not, then comment out everything to make sure everything else is still working.

 

dump_device SPSR should work if the length is <= 0x40, otherwise Pci.Read &gPci would not work. Anyway, you could change the line to

dump_device("SPSR", &gPci, NULL, 0);

If that works, then you could add these lines:

{
  UINTN value;
  value = PciRead32(PCIConfig + 0xD4);
  DBG("Value before:%08X\n", value);
  PciWrite32(PCIConfig + 0xD4, 0);
  value = PciRead32(PCIConfig + 0xD4);
  DBG("Value after:%08X\n", value);
}

If the debug lines are not outputting to the log, then you could add "PrintAt(x, y, L"unicode format string", variable arguments)" to draw information to the screen. The following lines can be placed before the DBG lines to draw the before and after value on the first and second line of the screen.

PrintAt(0, 0, L"Value before:%08X\n", value);
...
PrintAt(0, 1, L"Value after:%08X\n", value);

You can add a PrintAt before each dump_device to see which causes a hang.

[dgsga]

@joevt

Clover hangs whenever I enable the doscanotherdevices option, regardless of which lines are commented out.

I have found a piece of software called rweveryhing (http://rweverything.com) that works on my x99 chipset and does the same thing as PCIScope. If you go to:

https://translate.google.co.uk/translate?hl=en&sl=zh-TW&u=http://white5168.blogspot.com/2012/09/rwsmbus-device.html&prev=search

it tells you how to access the smbus devices. If you want to take a look at it and let me know what action I need to take it would be great. On the other hand if life's too short for stuff like this then I completely understand!

[joevt]

@joevt

Clover hangs whenever I enable the doscanotherdevices option, regardless of which lines are commented out.

That is unlikely. There is very little difference between DoOneMysteryDevice and DoOneSMBusProtocol once you comment out all the lines. Try this:

BOOLEAN DoOneMysteryDevice(
  VOID *Interface
  )
{
  EFI_PCI_IO_PROTOCOL    *PciIo = (EFI_PCI_IO_PROTOCOL*)Interface;
  EFI_STATUS             Status;
  UINTN                  Segment;
  UINTN                  Bus;       // 6-8 bits depending on bits 2:1 of PCIEXBAR
  UINTN                  Device;    // 5 bits
  UINTN                  Function;  // 3 bits
  UINTN                  PCIConfig;
  BOOLEAN                result = FALSE;

  PciIo->GetLocation(PciIo, &Segment, &Bus, &Device, &Function);
  PCIConfig = PCI_LIB_ADDRESS(Bus, Device, Function, 0);
  Status = PciIo->Pci.Read(PciIo, EfiPciIoWidthUint32, 0, sizeof (gPci) / sizeof (UINT32), &gPci);

  if (gPci.Hdr.VendorId == 0x8086 && gPci.Hdr.DeviceId == 0x8D7C) {
    DBG("PCI %08X (%02X %02X %02X) : %04X %04X class=%02X%02X%02X\n", PCIConfig, Bus, Device, Function, gPci.Hdr.VendorId, gPci.Hdr.DeviceId, gPci.Hdr.ClassCode[2], gPci.Hdr.ClassCode[1], gPci.Hdr.ClassCode[0]);
    //dump_device("SPSR", &gPci, NULL, 0x40);
    //dump_device("MS SMBus 0", NULL, PCI_LIB_ADDRESS(Bus, Device, 1, 0), 0x44);
    //dump_device("MS SMBus 1", NULL, PCI_LIB_ADDRESS(Bus, Device, 2, 0), 0x44);
    //dump_device("MS SMBus 2", NULL, PCI_LIB_ADDRESS(Bus, Device, 3, 0), 0x44);
    //PciWrite32(PCIConfig + 0xD4, 0);
    //dump_device("MS SMBus 0", NULL, PCI_LIB_ADDRESS(Bus, Device, 1, 0), 0x44);
    //dump_device("MS SMBus 1", NULL, PCI_LIB_ADDRESS(Bus, Device, 2, 0), 0x44);
    //dump_device("MS SMBus 2", NULL, PCI_LIB_ADDRESS(Bus, Device, 3, 0), 0x44);
    return TRUE;
  }
  return result;
}

Also change the defines to

#define DOSCANPCIPROTOCOLS 0
#define DOSCANSMBUSPROTOCOLS 0
#define DOSCANPCICONFIG 0

 

I have found a piece of software called rweveryhing (http://rweverything.com) that works on my x99 chipset and does the same thing as PCIScope. If you go to:

https://translate.google.co.uk/translate?hl=en&sl=zh-TW&u=http://white5168.blogspot.com/2012/09/rwsmbus-device.html&prev=search

it tells you how to access the smbus devices.

Those instructions are for accessing the main SMBus by writing to the host controller registers. We need to access the hidden SMBuses.

 

RW has an easier way to read from the SMBus devices directly. Using it's SMBus Device feature, enter an address A0, A2, A4, A6, A8, AA, AC, AE (those are the spd address 50-57 multiplied by 2 since the lsb is used for setting read/write operation) and click Read. Even more easier than that is the DIMM SPD option which can also read DDR4 spd info. But I don't think either of those will work for the hidden SMBus devices.

 

First, click PCI Devices (or select PCI from the Access menu), and select "Bus 00, Device 11, Function 00". That is the SPSR device. That should cause a crash if my code causes a crash, but whatever. If it doesn't crash, then save the info and send it. Try the Command window and enter these commands and report the result of each:

rpci32 0 17 0 0
rpci32 0 17 1 0
rpci32 0 17 2 0
rpci32 0 17 3 0
rpci32 0 17 0 0xD4
wpci32 0 17 0 0xD4 0
rpci32 0 17 0 0xD4
rpci32 0 17 1 0
rpci32 0 17 2 0
rpci32 0 17 3 0

[dgsga]

That is unlikely. There is very little difference between DoOneMysteryDevice and DoOneSMBusProtocol once you comment out all the lines. Try this:

BOOLEAN DoOneMysteryDevice(
  VOID *Interface
  )
{
  EFI_PCI_IO_PROTOCOL    *PciIo = (EFI_PCI_IO_PROTOCOL*)Interface;
  EFI_STATUS             Status;
  UINTN                  Segment;
  UINTN                  Bus;       // 6-8 bits depending on bits 2:1 of PCIEXBAR
  UINTN                  Device;    // 5 bits
  UINTN                  Function;  // 3 bits
  UINTN                  PCIConfig;
  BOOLEAN                result = FALSE;

  PciIo->GetLocation(PciIo, &Segment, &Bus, &Device, &Function);
  PCIConfig = PCI_LIB_ADDRESS(Bus, Device, Function, 0);
  Status = PciIo->Pci.Read(PciIo, EfiPciIoWidthUint32, 0, sizeof (gPci) / sizeof (UINT32), &gPci);

  if (gPci.Hdr.VendorId == 0x8086 && gPci.Hdr.DeviceId == 0x8D7C) {
    DBG("PCI %08X (%02X %02X %02X) : %04X %04X class=%02X%02X%02X\n", PCIConfig, Bus, Device, Function, gPci.Hdr.VendorId, gPci.Hdr.DeviceId, gPci.Hdr.ClassCode[2], gPci.Hdr.ClassCode[1], gPci.Hdr.ClassCode[0]);
    //dump_device("SPSR", &gPci, NULL, 0x40);
    //dump_device("MS SMBus 0", NULL, PCI_LIB_ADDRESS(Bus, Device, 1, 0), 0x44);
    //dump_device("MS SMBus 1", NULL, PCI_LIB_ADDRESS(Bus, Device, 2, 0), 0x44);
    //dump_device("MS SMBus 2", NULL, PCI_LIB_ADDRESS(Bus, Device, 3, 0), 0x44);
    //PciWrite32(PCIConfig + 0xD4, 0);
    //dump_device("MS SMBus 0", NULL, PCI_LIB_ADDRESS(Bus, Device, 1, 0), 0x44);
    //dump_device("MS SMBus 1", NULL, PCI_LIB_ADDRESS(Bus, Device, 2, 0), 0x44);
    //dump_device("MS SMBus 2", NULL, PCI_LIB_ADDRESS(Bus, Device, 3, 0), 0x44);
    return TRUE;
  }
  return result;
}

Also change the defines to

#define DOSCANPCIPROTOCOLS 0
#define DOSCANSMBUSPROTOCOLS 0
#define DOSCANPCICONFIG 0

Those instructions are for accessing the main SMBus by writing to the host controller registers. We need to access the hidden SMBuses.

 

RW has an easier way to read from the SMBus devices directly. Using it's SMBus Device feature, enter an address A0, A2, A4, A6, A8, AA, AC, AE (those are the spd address 50-57 multiplied by 2 since the lsb is used for setting read/write operation) and click Read. Even more easier than that is the DIMM SPD option which can also read DDR4 spd info. But I don't think either of those will work for the hidden SMBus devices.

 

First, click PCI Devices (or select PCI from the Access menu), and select "Bus 00, Device 11, Function 00". That is the SPSR device. That should cause a crash if my code causes a crash, but whatever. If it doesn't crash, then save the info and send it. Try the Command window and enter these commands and report the result of each:

rpci32 0 17 0 0
rpci32 0 17 1 0
rpci32 0 17 2 0
rpci32 0 17 3 0
rpci32 0 17 0 0xD4
wpci32 0 17 0 0xD4 0
rpci32 0 17 0 0xD4
rpci32 0 17 1 0
rpci32 0 17 2 0
rpci32 0 17 3 0

Tried the new code, still caused the crash! Attached is the output for RWE that you needed.

P001100.rw.zip

[joevt]

Tried the new code, still caused the crash! Attached is the output for RWE that you needed.

Try this:

#define DOSCANOTHERDEVICES 0

 

Your RW output is missing the second "rpci32 0 17 0 0xD4"

[reyder]

My post is gone but I tested new version and now HDMI audio works but I have to use ReuseFFFF because DSM method Is not injected at all without it. In my logs:

  DBG("Creating Method(_DSM) for %04x card\n", DisplayVendor[VCard]);

which is true but the method is not injected:

    if (!DISPLAYFIX) {
      for (j=devadr; j<devadr+devsize; j++) { //search card inside PEGP@0
        if (CmpAdr(dsdt, j, 0xFFFF)) {  //Special case? want to change to 0
          devadr1 = devFind(dsdt, j); //found PEGP
          if (!devadr1) {
            continue;
          }
          devsize1 = get_size(dsdt, devadr1); //13
          if (devsize1) {
            if (gSettings.ReuseFFFF) {
              dsdt[j+10] = 0;
              dsdt[j+11] = 0;
              DBG("Found internal video device FFFF@%x, ReUse as 0\n", devadr1);
            } else {
              NonUsable = TRUE;
              DBG("Found internal video device FFFF@%x, unusable\n", devadr1);
            }
            DISPLAYFIX = TRUE;
            break;
          }
        }
      }
    }

8:696  0:001  Found internal video device FFFF@3BD2, unusable

What's 3BD2 ?

[Micky1979]

Your post is gone due to a server fault.. running from a backup...sorry.