Clover Problems and Solutions

[bronxteck]

the sbus might be saved as an SSDT

[joevt]

the sbus might be saved as an SSDT

There may be 30 or 40 files to look at. You can use the following command to find which files (binary or text) contain a string

grep SBUS -r /yourefimountpoint/EFI/CLOVER/ACPI/origin

[cecekpawon]

same for DSDT please?

 

You could easily fake DSDT name to something that doesnt exist (GUI menu -> "DSDT fix mask" -> name)

[Slice]

You could easily fake DSDT name to something that doesnt exist (GUI menu -> "DSDT fix mask" -> name)

No, DSDT loaded and attached other way then other tables. Don't fake it!

One can have several DSDT files with names like

DSDT-1.aml, DSDT-2.aml and so on in the patched folder. As they have "DSDT" string in their name they will not be loaded automatic.

Only one file with a name from config.plist or from GUI menu will be loaded as new DSDT table and attached into FACS.

[dgsga]

The spd looks good. All the DDR4 information is there.

 

The SBUS Device in dsdt seems lacking. Aren't there any Method or Field or OperationRegion statements? Mine has methods for reading and writing to the SMBus. Did you check for differences between the dsdt saved by Clover (using F4) and the system dsdt?

 

 

A full dsdt from Clover and the ioreg might be useful. You can attach a zip file.

Attached is the DSDT from Clover. I can confirm there are no further instances of SBUS in any other ACPI tables. This DSDT has been stripped of all useless code, I tested with the full system DSDT (also attached) but still get no spd read 

[Dr. Hurt]

I noticed that clover recently takes longer to start. The delay happens while scanning NTFS partitions.

 

It seems to take about 1 second for every NTFS partition it finds.

 

2:911  1:084   6: 'Legacy HD5' no file system

[Needy]

Recent changes caused memory detection to malfunction. In other words, DDR2 is detected as DDR3, below is information from system report and memory detection section from boot log.

DIMM1:

  Size:	2 GB
  Type:	DDR3
  Speed:	800 MHz
  Status:	OK
  Manufacturer:	Unknown
  Part Number:	Unknown
  Serial Number:	Unknown

DIMM2:

  Size:	2 GB
  Type:	DDR3
  Speed:	800 MHz
  Status:	OK
  Manufacturer:	Unknown
  Part Number:	Unknown
  Serial Number:	Unknown

1:138  0:000  Total Memory Slots Count = 4
1:138  0:000  Type 17 Index = 0
1:138  0:000  SmbiosTable.Type17->Speed = 800MHz
1:138  0:000  SmbiosTable.Type17->Size = 2048MB
1:138  0:000  SmbiosTable.Type17->Bank/Device = Bank0/1 A0
1:138  0:000  SmbiosTable.Type17->Vendor =  
1:138  0:000  SmbiosTable.Type17->SerialNumber =  
1:138  0:000  SmbiosTable.Type17->PartNumber =  
1:138  0:000  Type 17 Index = 1
1:138  0:000  Ignoring insane frequency value 0MHz
1:138  0:000  SmbiosTable.Type17->Speed = 0MHz
1:138  0:000  SmbiosTable.Type17->Size = 0MB
1:138  0:000  SmbiosTable.Type17->Bank/Device = Bank2/3 A1
1:138  0:000  SmbiosTable.Type17->Vendor = <null string>
1:138  0:000  SmbiosTable.Type17->SerialNumber = <null string>
1:138  0:000  SmbiosTable.Type17->PartNumber = <null string>
1:138  0:000  Type 17 Index = 2
1:138  0:000  SmbiosTable.Type17->Speed = 800MHz
1:138  0:000  SmbiosTable.Type17->Size = 2048MB
1:138  0:000  SmbiosTable.Type17->Bank/Device = Bank4/5 A2
1:138  0:000  SmbiosTable.Type17->Vendor =  
1:138  0:000  SmbiosTable.Type17->SerialNumber =  
1:138  0:000  SmbiosTable.Type17->PartNumber =  
1:138  0:000  Type 17 Index = 3
1:138  0:000  Ignoring insane frequency value 0MHz
1:138  0:000  SmbiosTable.Type17->Speed = 0MHz
1:138  0:000  SmbiosTable.Type17->Size = 0MB
1:138  0:000  SmbiosTable.Type17->Bank/Device = Bank6/7 A3
1:138  0:000  SmbiosTable.Type17->Vendor = <null string>
1:138  0:000  SmbiosTable.Type17->SerialNumber = <null string>
1:138  0:000  SmbiosTable.Type17->PartNumber = <null string>
1:138  0:000  Boot status=0

I'm using revision 3526. If any further information is needed let me know.

In addition, this matter is quite different, up to revision 3368 while booting into windows using clover there was lack of ram information, for example memory frequency, system reserved and some other. Now, with revision 3526, all that information is detected and filled where needed, however the memory type is detected as unknown, 4GB Unknown.

@Slice, It turns out that clover affects somehow the ram information displayed in windows.

Best regards.

[joevt]

Attached is the DSDT from Clover. I can confirm there are no further instances of SBUS in any other ACPI tables. This DSDT has been stripped of all useless code, I tested with the full system DSDT (also attached) but still get no spd read 

Those attached dsl files are text files created by different versions of the aml disassembler so it's difficult to compare them. Also, both of them do not include the SBUS device that you said was in there. Actually, I found the device listed as SMBS. There's also an SMBS named value but that's not used anywhere. I don't know if that's a problem. I can't be sure the stripped code is useless unless I saw the unstripped code.

 

1)

To send the unpatched dsdt that the system has built in, do the following:

 

Zip the entire /EFI/CLOVER/ACPI/origin folder which has all the aml binary files when you press F4 in Clover (check the modification dates to make sure they're all current / have the same date as when you pressed F4).

 

Note that the contents of the aml can change depending on BIOS settings. For example, disabling the serial port will affect the IOST value.

 

2)

To send the dsdt that Clover makes after patching the built in dsdt, do the following:

 

In MaciASL, use the "Export tableset..." option to create an .acpi file. The .acpi file is a plist containing the binary version of all the tables (after they've been patched by Clover). MaciASL.app can disassemble any of the aml tables directly from the .acpi file. A simple shell script can convert the plist into multiple binary aml files which can also be disassembled and can also be searched using grep. 

 

3)

If you disassembled the aml and modified the resulting dsl, then you would send that dsl so people can see any comments which would not be included in the aml (if you bother to comment your code).

 

Please include the SBUS or SMBS part of the ioreg output.

[joevt]

below is information from system report and memory detection section from boot log.

That is the SMBIOS table type 17 extract section from boot log. The type 17 table does not contain information about the RAM type (actually, it does, but Clover doesn't use it for some reason). You need to include the spd scanning section (from "ScanSPD() start" to "ScanSPD() end")

 

If Clover can't read the spd, then it assumes DDR3.

 

In addition, this matter is quite different, up to revision 3368 while booting into windows using clover there was lack of ram information, for example memory frequency, system reserved and some other. Now, with revision 3526, all that information is detected and filled where needed, however the memory type is detected as unknown, 4GB Unknown.

 

@Slice, It turns out that clover affects somehow the ram information displayed in windows.

Maybe Windows can't read the spd either? Try booting Windows without Clover, start with cold boot (power off), press F12 or whatever key is used to select the startup drive, and select Windows. Also, try the Thaiphoon Burner app in Windows to see if it can read the spd.

[Needy]

That is the SMBIOS table type 17 extract section from boot log. The type 17 table does not contain information about the RAM type (actually, it does, but Clover doesn't use it for some reason). You need to include the spd scanning section (from "ScanSPD() start" to "ScanSPD() end")

 

If Clover can't read the spd, then it assumes DDR3.

 

 

Maybe Windows can't read the spd either? Try booting Windows without Clover, start with cold boot (power off), press F12 or whatever key is used to select the startup drive, and select Windows. Also, try the Thaiphoon Burner app in Windows to see if it can read the spd.

The SPD section was empty and that's why I included that information.

 

Here's SPD section with revision 3526.

1:641  0:000  ScanSPD() start
1:641  0:000  ScanSPD() end

SPD from prior clover revision, 3346.

4:071  0:000  ScanSPD() start
4:072  0:000  SMBus CmdReg: 0x1
4:072  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
4:072  0:000  Slots to scan [8]...
4:188  0:116  SPD[0]: Type 8 @0x50 
4:275  0:087  DDR speed 800MHz 
4:275  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=A-DATA Technology PartNo= SerialNo=blah blah 
4:400  0:125  SPD[2]: Type 8 @0x52 
4:476  0:076  DDR speed 800MHz 
4:476  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=blah blah 
4:521  0:045  ScanSPD() end

SPD information from windows using AIDA Engineer.

--------[ SPD ]---------------------------------------------------------------------------------------------------------

  [ DIMM1: A-Data (2 GB DDR2-800 DDR2 SDRAM) ]

    Memory Module Properties:
      Module Name                                       A-Data
      Serial Number                                     ...
      Manufacture Date                                  Week 24 / 2010
      Module Size                                       2 GB (2 ranks, 8 banks)
      Module Type                                       Unbuffered DIMM
      Memory Type                                       DDR2 SDRAM
      Memory Speed                                      DDR2-800 (400 MHz)
      Module Width                                      64 bit
      Module Voltage                                    SSTL 1.8
      Error Detection Method                            None
      Refresh Rate                                      Reduced (7.8 us), Self-Refresh

  [ DIMM3: Kingston (2 GB DDR2-800 DDR2 SDRAM) ]

    Memory Module Properties:
      Module Name                                       Kingston
      Serial Number                                     ...
      Manufacture Date                                  Week 12 / 2011
      Module Size                                       2 GB (2 ranks, 8 banks)
      Module Type                                       Unbuffered DIMM
      Memory Type                                       DDR2 SDRAM
      Memory Speed                                      DDR2-800 (400 MHz)
      Module Width                                      64 bit
      Module Voltage                                    SSTL 1.8
      Error Detection Method                            None
      Refresh Rate                                      Reduced (7.8 us), Self-Refresh

As you can see SPD is read successfully in windows, same in prior clover revisions. 

 

Botting windows in legacy mode, so to speak, aka from MBR partition displays all the information correctly. I mentioned earlier that windows wasn't showing any information at all with previous revisions of clover, now it just lacks the memory type.

 

Best regards.

[joevt]

Here's SPD section with revision 3526.

1:641  0:000  ScanSPD() start
1:641  0:000  ScanSPD() end

SPD from prior clover revision, 3346.

4:071  0:000  ScanSPD() start
4:072  0:000  SMBus CmdReg: 0x1
...

 

Nothing in the code has changed between the "ScanSPD() start" message and the "SMBus CmdReg: 0x1" message. I think you need to add some debug messages to ScanSPD to see where it fails, because it doesn't seem to be getting to the read_smb function. What pci devices does ScanSPD see, and what are their class codes? It should be the same set of devices that you see listed in the log later on like this:

PCI (00:00:00.00) : 8086 191F class=060000
...

 

Botting windows in legacy mode, so to speak, aka from MBR partition displays all the information correctly. I mentioned earlier that windows wasn't showing any information at all with previous revisions of clover, now it just lacks the memory type.

Maybe you're EFI is getting corrupted, causing ScanSPD to not find PCI devices... I dunno.

[Micky1979]

Here found some usefull info:http://www.simmtester.com/page/news/showpubnews.asp?num=184 also a code example, maybe navigating the site we can find more..

EDIT

https://gitlab.com/turtle-solutions/u-boot/blob/master/common/ddr_spd.c

http://ftp.tku.edu.tw/NetBSD/NetBSD-current/src/sys/dev/ic/spdmem.c

[dgsga]

Those attached dsl files are text files created by different versions of the aml disassembler so it's difficult to compare them. Also, both of them do not include the SBUS device that you said was in there. Actually, I found the device listed as SMBS. There's also an SMBS named value but that's not used anywhere. I don't know if that's a problem. I can't be sure the stripped code is useless unless I saw the unstripped code.

 

1)

To send the unpatched dsdt that the system has built in, do the following:

 

Zip the entire /EFI/CLOVER/ACPI/origin folder which has all the aml binary files when you press F4 in Clover (check the modification dates to make sure they're all current / have the same date as when you pressed F4).

 

Note that the contents of the aml can change depending on BIOS settings. For example, disabling the serial port will affect the IOST value.

 

2)

To send the dsdt that Clover makes after patching the built in dsdt, do the following:

 

In MaciASL, use the "Export tableset..." option to create an .acpi file. The .acpi file is a plist containing the binary version of all the tables (after they've been patched by Clover). MaciASL.app can disassemble any of the aml tables directly from the .acpi file. A simple shell script can convert the plist into multiple binary aml files which can also be disassembled and can also be searched using grep. 

 

3)

If you disassembled the aml and modified the resulting dsl, then you would send that dsl so people can see any comments which would not be included in the aml (if you bother to comment your code).

 

Please include the SBUS or SMBS part of the ioreg output.

@joevt

As requested! Thanks for your help with this...

ioreg.tiff

origin.zip

Tableset.acpi.zip

[Needy]

My issue is getting stranger and stranger. Building clover, r. 3526, manually fixes the problem.

Here's some more information.
Clover r. 3368

1:576  0:000  ScanSPD() start
1:576  0:000  SMBus CmdReg: 0x1
1:576  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
1:576  0:000  Slots to scan [8]...
1:692  0:116  SPD[0]: Type 8 @0x50 
1:779  0:087  DDR speed 800MHz 
1:779  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=A-DATA Technology PartNo= SerialNo=... 
1:904  0:125  SPD[2]: Type 8 @0x52 
1:981  0:076  DDR speed 800MHz 
1:981  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=... 
2:026  0:045  ScanSPD() end

Clover r. 3489

1:592  0:000  ScanSPD() start
1:593  0:000  SMBus CmdReg: 0x1
1:593  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
1:593  0:000  Slots to scan [8]...
1:596  0:003  SPD[0]: Type 8 @0x50 
1:720  0:123  DDR speed 800MHz 
1:720  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=A-DATA Technology PartNo= SerialNo=... 
1:725  0:004  SPD[2]: Type 8 @0x52 
1:837  0:112  DDR speed 800MHz 
1:837  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=...
1:842  0:005  ScanSPD() end

Clover r. 3504

1:823  0:000  ScanSPD() start
1:823  0:000  SMBus CmdReg: 0x1
1:823  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
1:823  0:000  Slots to scan [8]...
1:827  0:003  SPD[0]: Type 8 @0x50 
1:951  0:124  DDR speed 800MHz 
1:951  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=A-DATA Technology PartNo= SerialNo=... 
1:956  0:004  SPD[2]: Type 8 @0x52 
2:068  0:112  DDR speed 800MHz 
2:068  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=...
2:074  0:005  ScanSPD() end

Clover r. 3526, installed with package installer from source forge.

1:570  0:000  ScanSPD() start
1:570  0:000  ScanSPD() end

Even though, the revision 3526 shows wrong memory type in Mac OS, it fixes the lack of information in windows. I'm pleased with results in windows but I have no clue why the installed package from source forge shows incorrect information, however compiling the same version manually displays the correct ram type. In addition, if I use the manually compiled r. 3526, the windows problem appears again.

Best regards.

[Slice]

Anyone confirm the problem with Clover r. 3526, installed with package installer from source forge?

[joevt]

@joevt

As requested! Thanks for your help with this...

Thanks for the info. From your later post, the solution is obviously not to be found in your DSDT or ioreg. But here's my observations on those anyway. The patched version has a lot of patches for your old motherboard compared to my newer Skylake motherboard. I see that one of the patches is to rename SMBS to SBUS so now I know where that came from. The binary files have no more information on the SMBS device than you've already provided. It would be better to post the text dump from the ioreg command than to post a screen shot because that way all the information is sure to be included. Your screenshot from IORegistryExplorer is missing the IOInterruptSpecifiers, IODeviceMemory, IOPowerManagement, and IOInterruptControllers. Plus, having the text will allow copy and paste of the text (I had to type all those missing items by hand!). Anyway, we don't need the ioreg anymore. Here's the command I use to convert .acpi to binary files and to search the files:

mkdir ~/Downloads/patched
pushd ~/Downloads/patched
eval $(plutil -p "../Tableset.acpi" | sed -En '/^ *"([^"]+)" => <([^>]+)>/s//echo -n "\2" | xxd -r -p > "\1.aml";/p')
popd

grep SBUS -r ~/Downloads/patched

 

My issue is getting stranger and stranger. Building clover, r. 3526, manually fixes the problem.

 

Here's some more information.

Clover r. 3368

1:576  0:000  ScanSPD() start
1:576  0:000  SMBus CmdReg: 0x1
1:576  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
1:576  0:000  Slots to scan [8]...
1:692  0:116  SPD[0]: Type 8 @0x50 
1:779  0:087  DDR speed 800MHz 
1:779  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=A-DATA Technology PartNo= SerialNo=... 
1:904  0:125  SPD[2]: Type 8 @0x52 
1:981  0:076  DDR speed 800MHz 
1:981  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=... 
2:026  0:045  ScanSPD() end

Clover r. 3489 (same)

Clover r. 3504 (same)

Clover r. 3526, installed with package installer from source forge.

1:570  0:000  ScanSPD() start
1:570  0:000  ScanSPD() end

Even though, the revision 3526 shows wrong memory type in Mac OS, it fixes the lack of information in windows. I'm pleased with results in windows but I have no clue why the installed package from source forge shows incorrect information, however compiling the same version manually displays the correct ram type. In addition, if I use the manually compiled r. 3526, the windows problem appears again.

 

You have two DIMMs from different vendors, is that correct? What are you looking at in Windows? Post a screenshot? Since you were able to fix the problem by recompiling it yourself, then there must be something wrong with the compiler options used to build the package. There are multiple ways to build Clover. What method did you use? When I build it, it looks like this:

Joes-Mac-Pro:Clover joevt$ ./ebuild.sh
TOOLCHAIN_DIR: /Users/joevt/src/edk2/Clover/../../opt/local
Initializing workspace
Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh
WORKSPACE: /Users/joevt/src/edk2
EDK_TOOLS_PATH: /Users/joevt/src/edk2/BaseTools

Running edk2 build for CloverX64 using the command:
build  -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t XCODE5 -n 9 

Build environment: Darwin-15.4.0-x86_64-i386-64bit
Build start time: 16:04:10, May.12 2016

WORKSPACE        = /Users/joevt/src/edk2
ECP_SOURCE       = /Users/joevt/src/edk2/EdkCompatibilityPkg
EDK_SOURCE       = /Users/joevt/src/edk2/EdkCompatibilityPkg
EFI_SOURCE       = /Users/joevt/src/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /Users/joevt/src/edk2/BaseTools


Architecture(s)  = X64
Build target     = RELEASE
Toolchain        = XCODE5

Active Platform          = /Users/joevt/src/edk2/Clover/Clover.dsc
Flash Image Definition   = /Users/joevt/src/edk2/Clover/Clover.fdf

Maybe there is a problem with the calling conventions for one of the following from ScanSPD:

gBS->LocateHandleBuffer

gBS->ProtocolsPerHandle

gBS->OpenProtocol

PciIo->Pci.Read

PciIo->Pci.Write

 

but that would probably cause a crash. Maybe there is a problem with just the function result of one of those?

 

Anyone confirm the problem with Clover r. 3526, installed with package installer from source forge?

I ran 3526 on my EFI partition and found the same problem. I used Pacifist to extract BOOTX64.efi, then copied it manually to my EFI partition. I compared the debug log and found the following differences:

 

3526 shows the Build with arguments. The version I'm using (3469?) does not. What do the build options say on your recompiled version of 3526 in the debug log? The one from the package says:

Now is 16.5.2016,  7:25:15 (GMT)
Starting Clover rev 3526 on American Megatrends EFI
Build with: [Args: ./ebuild.sh | Command: build -D USE_LOW_EBDA -p Clover/Clover.dsc -a X64 -b RELEASE -t XCODE5 -n 3 | OS: 10.7.5 | XCODE: 4.4.1]

3526 says "Found Nvidia model=Unknown family 120". Mine says #x instead of 120.

 

3526 shows nothing between ScanSPD start and end. Mine correctly shows my DDR4 DIMMs.

 

During "Checking EFI partition Volume # for Clover", 3526 only outputs " Found Clover" once. Mine found it twice on two different partitions. Is it searching for matching versions?

 

3526 says "GetEfiBootDeviceFromNvram: efi-boot-device-data not found". Mine says:

GetEfiBootDeviceFromNvram:got eft-boot-next-data size=0
second eft-boot-next-data size=0
 efi-boot-device-data not found

3526 says "DefaultIndex=3 and MainMenu.EntryCount=11". Mine says "DefaultIndex=3 and MainMenu.EntryCount=12"

 

3526 says "Detected alternating SMBIOS channel banks" (that happens if scan spd fails). There's a few other differences related to that for SMBIOS memory stuff.

 

3526 says "Start: Processing Patched AML(s): Unsorted" and "End: ...". Mine does not. Both say "Inserting ssdt.aml from EFI\CLOVER\ACPI\patched ... Success"

 

It appears 3526 can scan the PCI devices correctly: when it finds the Nvidia card and LAN 0 and LAN 1, or when it's looking for pci devices to apply "custom properties" to. So we just need to figure out why ScanSPD can't scan PCI devices. I can't do that because my build method would not reproduce the problem.

[Slice]

I see we are using the same build options but -n3 instead of -n9 correspond to different CPU. My CPU has only two cores (3 = # cores + 1).

And I compiled under 10.7.5 with Xcode 4.4.1. We can expect that the result will be different so why I was asking about problem with my compilation.

 

Other differences looks like different sources. Your source 3469 is really differ from my 3526. You should update before compare.

[Needy]

 You have two DIMMs from different vendors, is that correct? What are you looking at in Windows? Post a screenshot? Since you were able to fix the problem by recompiling it yourself, then there must be something wrong with the compiler options used to build the package. There are multiple ways to build Clover. What method did you use? When I build it, it looks like this:

Joes-Mac-Pro:Clover joevt$ ./ebuild.sh
TOOLCHAIN_DIR: /Users/joevt/src/edk2/Clover/../../opt/local
Initializing workspace
Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh
WORKSPACE: /Users/joevt/src/edk2
EDK_TOOLS_PATH: /Users/joevt/src/edk2/BaseTools

Running edk2 build for CloverX64 using the command:
build  -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t XCODE5 -n 9 

Build environment: Darwin-15.4.0-x86_64-i386-64bit
Build start time: 16:04:10, May.12 2016

WORKSPACE        = /Users/joevt/src/edk2
ECP_SOURCE       = /Users/joevt/src/edk2/EdkCompatibilityPkg
EDK_SOURCE       = /Users/joevt/src/edk2/EdkCompatibilityPkg
EFI_SOURCE       = /Users/joevt/src/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /Users/joevt/src/edk2/BaseTools


Architecture(s)  = X64
Build target     = RELEASE
Toolchain        = XCODE5

Active Platform          = /Users/joevt/src/edk2/Clover/Clover.dsc
Flash Image Definition   = /Users/joevt/src/edk2/Clover/Clover.fdf

Maybe there is a problem with the calling conventions for one of the following from ScanSPD:

gBS->LocateHandleBuffer

gBS->ProtocolsPerHandle

gBS->OpenProtocol

PciIo->Pci.Read

PciIo->Pci.Write

 

but that would probably cause a crash. Maybe there is a problem with just the function result of one of those?

 

 

I ran 3526 on my EFI partition and found the same problem. I used Pacifist to extract BOOTX64.efi, then copied it manually to my EFI partition. I compared the debug log and found the following differences:

 

3526 shows the Build with arguments. The version I'm using (3469?) does not. What do the build options say on your recompiled version of 3526 in the debug log? The one from the package says:

Now is 16.5.2016,  7:25:15 (GMT)
Starting Clover rev 3526 on American Megatrends EFI
Build with: [Args: ./ebuild.sh | Command: build -D USE_LOW_EBDA -p Clover/Clover.dsc -a X64 -b RELEASE -t XCODE5 -n 3 | OS: 10.7.5 | XCODE: 4.4.1]

Yes, the Memory DIMMs are from different vendors.

 

I noticed some changes in my build log as well, but I thought that those are some improvements since I haven't updated clover in a while. 

 

I build clover with ./ebuild.sh.

 

Below is the output.

TOOLCHAIN_DIR: /Users/cristian/src/edk2/clover/../../opt/local
Initializing workspace
Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh
WORKSPACE: /Users/cristian/src/edk2
EDK_TOOLS_PATH: /Users/cristian/src/edk2/BaseTools

Running edk2 build for CloverX64 using the command:
build  -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t XCODE5 -n 5

Build environment: Darwin-15.4.0-x86_64-i386-64bit
Build start time: 09:48:27, May.16 2016

WORKSPACE        = /Users/cristian/src/edk2
ECP_SOURCE       = /Users/cristian/src/edk2/EdkCompatibilityPkg
EDK_SOURCE       = /Users/cristian/src/edk2/EdkCompatibilityPkg
EFI_SOURCE       = /Users/cristian/src/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /Users/cristian/src/edk2/BaseTools


Architecture(s)  = X64
Build target     = RELEASE
Toolchain        = XCODE5

Active Platform          = /Users/cristian/src/edk2/Clover/Clover.dsc
Flash Image Definition   = /Users/cristian/src/edk2/Clover/Clover.fdf

Processing meta-data .............. done!

...

I'll attach 2 screenshots in 1 min.

 

Below are 2 screenshots of task manager, I suppose you'll understand what those represent by the names.

 

Best regards.

windowstskm.zip

[cecekpawon]

I dont know if its worth to compare with Windows build

 

Working well, both: r3527, last EDK

0:100  0:100  MemLog inited, TSC freq: 3410011876
0:100  0:000  
0:100  0:000  Now is 16.5.2016,  9:44:31 (GMT)
0:100  0:000  Starting Clover rev 3527 on American Megatrends EFI
0:100  0:000  Build with: [Args: ./ebuild.sh -a X64 -t XCODE5 | Command: build -D USE_LOW_EBDA -p Clover/Clover.dsc -a X64 -b RELEASE -t XCODE5 -n 5 | OS: 10.11.5 | XCODE: 6.1.1]
....
0:351  0:000  ScanSPD() start
0:352  0:000  SMBus CmdReg: 0x3
0:352  0:000  Scanning SMBus [8086:1E22], mmio: 0xF7825004, ioport: 0xF040, hostc: 0x1
0:352  0:000  Slots to scan [8]...
0:352  0:000  SPD[1]: Type 11 @0x51
0:371  0:018  XMP Profile1: 10*1/8ns
0:371  0:000  Found module with XMP version 1.3
0:371  0:000  Using XMP Profile1 instead of standard frequency 1600MHz
0:371  0:000  DDR speed 1600MHz
0:371  0:000  Slot: 1 Type 24 8192MB 1600MHz Vendor=Corsair PartNo=x SerialNo=0000000000000000
0:371  0:000  SPD[3]: Type 11 @0x53
0:390  0:018  XMP Profile1: 10*1/8ns
0:390  0:000  Found module with XMP version 1.3
0:390  0:000  Using XMP Profile1 instead of standard frequency 1600MHz
0:390  0:000  DDR speed 1600MHz
0:390  0:000  Slot: 3 Type 24 8192MB 1600MHz Vendor=Corsair PartNo=x SerialNo=0000000000000000
0:390  0:000  SPD[7]: Type 66 @0x57
0:390  0:000  ScanSPD() end

Edited May 16, 2016 by cecekpawon

[Slice]

I confirm the problem on my computer and will debug now.

3:593  0:000  ScanSPD() start
3:594  0:000  ScanSPD() end

[Rodion2010]

Starting Clover rev 3428 on CLOVER EFI:

6:412  0:000  ScanSPD() start
6:412  0:000  SMBus CmdReg: 0x3
6:412  0:000  Scanning SMBus [8086:2930], mmio: 0xF9FFF404, ioport: 0x400, hostc: 0x1
6:412  0:000  Slots to scan [8]...
6:427  0:015  SPD[0]: Type 11 @0x50 
6:436  0:009  Not using XMP because it is not present
6:436  0:000  DDR speed 1600MHz 
6:436  0:000  Slot: 0 Type 24 2048MB 1600MHz Vendor=Samsung PartNo=M378B5773EB0-CK0 SerialNo=090806020A09060A 
6:452  0:015  SPD[1]: Type 11 @0x51 
6:461  0:009  Not using XMP because it is not present
6:461  0:000  DDR speed 1333MHz 
6:461  0:000  Slot: 1 Type 24 2048MB 1333MHz Vendor=Nanya Technology PartNo=M2F2G64CB88B7N-CG SerialNo=0C040D05000C0207 
6:476  0:015  SPD[2]: Type 11 @0x52 
6:485  0:009  Not using XMP because it is not present
6:485  0:000  DDR speed 1600MHz 
6:485  0:000  Slot: 2 Type 24 2048MB 1600MHz Vendor=Samsung PartNo=M378B5773EB0-CK0 SerialNo=090806020A09060D 
6:500  0:015  SPD[3]: Type 11 @0x53 
6:509  0:009  Not using XMP because it is not present
6:509  0:000  DDR speed 1333MHz 
6:509  0:000  Slot: 3 Type 24 2048MB 1333MHz Vendor=Nanya Technology PartNo=M2F2G64CB88B7N-CG SerialNo=02080B020104060F 
6:544  0:034  ScanSPD() end

Starting Clover rev 3526 on CLOVER EFI

4:075  0:000  ScanSPD() start
4:075  0:000  ScanSPD() end

[Fljagd]

Anyone confirm the problem with Clover r. 3526, installed with package installer from source forge?

0:320  0:000  ScanSPD() start
0:320  0:000  SMBus CmdReg: 0x1
0:320  0:000  Scanning SMBus [8086:8D22], mmio: 0xFB235004, ioport: 0x580, hostc: 0x1
0:320  0:000  Slots to scan [8]...
0:321  0:001  ScanSPD() end

[Needy]

 

I confirm the problem on my computer and will debug now.

3:593  0:000  ScanSPD() start
3:594  0:000  ScanSPD() end

Could you inspect the issue that affects windows as well? Once you finish with the ScanSPD "problem" of course.

 

I'll be here to test.   

 

Best of luck.

[Slice]

Strange issue. It seems to be a bug of my compiler (Xcode 4.4.1 - strange that it works at all!). There is impossible to use address of global variables as a parameters of global functions (gBS->xxx).

Now it is OK.

3:564  0:000  ScanSPD() start
3:564  0:000  SMBus device : 8086 27DA class=0C0500 status=Success
3:564  0:000  SMBus CmdReg: 0x1
3:564  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
3:564  0:000  Slots to scan [8]...
3:568  0:003  SPD[0]: Type 8 @0x50
3:681  0:112  DDR speed 800MHz
3:681  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=0501030C0A040503
3:685  0:004  SPD[2]: Type 8 @0x52
3:794  0:108  DDR speed 800MHz
3:794  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Samsung PartNo=M378T5663SH3-CF73S SerialNo=04050709030D0003
3:799  0:005  ScanSPD() end

Committed to 3528.

Could you inspect the issue that affects windows as well? Once you finish with the ScanSPD "problem" of course.

I'll be here to test.   

Best of luck.

What is mean "Windows"? I don't know it!.

[Needy]

Strange issue. It seems to be a bug of my compiler (Xcode 4.4.1 - strange that it works at all!). There is impossible to use address of global variables as a parameters of global functions (gBS->xxx).

Now it is OK.

3:564  0:000  ScanSPD() start
3:564  0:000  SMBus device : 8086 27DA class=0C0500 status=Success
3:564  0:000  SMBus CmdReg: 0x1
3:564  0:000  Scanning SMBus [8086:27DA], mmio: 0x0, ioport: 0x500, hostc: 0x1
3:564  0:000  Slots to scan [8]...
3:568  0:003  SPD[0]: Type 8 @0x50
3:681  0:112  DDR speed 800MHz
3:681  0:000  Slot: 0 Type 19 2048MB 800MHz Vendor=Kingston PartNo= SerialNo=0501030C0A040503
3:685  0:004  SPD[2]: Type 8 @0x52
3:794  0:108  DDR speed 800MHz
3:794  0:000  Slot: 2 Type 19 2048MB 800MHz Vendor=Samsung PartNo=M378T5663SH3-CF73S SerialNo=04050709030D0003
3:799  0:005  ScanSPD() end

Committed to 3528.

What is mean "Windows"? I don't know it!.

Funny, indeed. 

 

However, the fact that it was showing the right information with the bugged build means that the lack of information is caused by clover, well, at least by some of clover's components.

 

Could we investigate this matter any further?

 

Best regards.