Trials and tribulations installing a 1070 in a M6800

I posted some info about a partial success/progress here: http://forum.notebookreview.com/threads/graphics-card-upgrade-for-m6800.806352/page-22#post-10859638 getting a 1070 working with my m6800,
but thought I'd start a specific thread since I've continued work on it.

Just to recap the current state of things.

• Started with a M6800 and eDP 1080p display, Legacy boot, dual boot Win10 and Linux Mint 19.1
• Updated to 980M GPU. Had to mod the heat sink, but otherwise worked flawlessly, no driver mod needed.
• Installed 1070, black PCB, same layout as 980M. Boots to BIOS just fine
  • Trying to boot into Win 7/8/10 with every possible BIOS configuration leads to ACPI_BIOS_ERROR. (Just like every other pascal based GPU on the m6800, it seems)
  • Linux boots just fine. Further, card appears to be fully functional, both from performance and from ACPI.

Linux really appears to be fully compatible. I was able to install and run Steam/Proton games with very good performance. (Eg, Witcher 3/Ultra @ 60-70fps ). I also was able run a Windows 10 virtual machine with near metal performance in benchmarks and most games.

However, both of those solutions are just not 100%. Games that use Denuvo or other anti-cheat layers tend to not work at all under Linux and to perform poorly in the VM. (Higher CPU usage is a bottleneck). Also, the virtual machine is limited to displaying on an external monitor.

It's back to trying to fix this ACPI_BIOS_ERROR for windows.

Windows 10 gives ZERO details about the error. Further, it doesn't appear to leave any details in either a boot log or the event log. (I verified this by mounting the volume under linux and searching for any modified files). However, booting into Win7 at least displays some error code and parameters for the error.

(0x00000000a5) (0x0000000000000011, 0x0000000000000003,0x0000000000000000, 0x0000000000000000)

Windows documentation says that parameter 1 (0x11) indicates the system couldn't enter ACPI mode. (duh). Parameter 2 (0x3) indicates that the system could not load the RSDT.

RSDT/XSDT are the root tables of a hierarchy of ACPI tables that eventually locate the DSDT tables that control the ACPI functions. It seems weird that it couldn't load it. (It _can_ find it, that would be a different error code)

I booted linux and dumped the DSDT tables. Strange, the FACS table is missing. Linux has a tool 'fwts' that runs a series of tests on the current firmware, including tests on all the ACPI tables. Running that tool also reports the missing table.

That table is pretty small and simple. Basically a signature 'FACS', a version, and a hardware signature that is used to determine the hardware has changed while the computer was sleeping. Also, a global lock. More on this later.

I installed the syslinux boot loader on a USB and wrote a quick extension module to write a valid FACS table at the spot in NVS memory where it is expected. Booted to syslinux, ran the extension, and then chain loaded Win7. Success! Well, no. Baby steps. Just a different error message this time:

(0x00000000a5) (0x0000000000001000, 0x0000000000000000,0x0000000000000000, 0x0000000000018040)

(I did the same again and chain loaded linux, ran the 'fwts' and it reported that the FACS was correct)

This time, I could find *no* documentation on either of the non-zero parameter values. (0x1000 or 0x18040). However, some grepping around in the dumped BIOS and ACPI tables show that the latter value shows up in the DSDT:

OperationRegion (RPCS, SystemMemory, XBAS, 0x00018040)
Field (RPCS, AnyAcc, NoLock, Preserve)
{
Offset (0x18004),
ACMD, 8,
Offset (0x18010),
ABAR, 32,
}

As a quick experiment, I located where the DSDT was loaded into memory and update my syslinux extension to change that value to 0x00018041. Rebooted to syslinux, chainloaded Win7 and saw that it did indeed come from the DSDT:

(0x00000000a5) (0x0000000000001000, 0x0000000000000000,0x0000000000000000, 0x0000000000018041)

It appears that fixing the FACS table does get Windows further along in the boot process, to the point of actually loading and/or executing the DSDTs, but I suspect both failures are related. The FACS table is located at the very end of memory reserved for ACPI NVS. The same is true for this OperationRegion. I suspect there is some disagreement about this memory region between the sBIOS and the vBIOS, causing them to overwrite each other.

 

Wow, you're going pretty deep
As you continue to dig, I do have a working Pascal setup (P5000/M6700); if it would be helpful for me to boot into Linux and dump anything for comparison, let me know...

[Edit]
Oh, I have a 7530 too, that is Pascal-ready; happy to go dump tables or whatever from that too.

 

That would be awesome! If you don't know how to do it already, you can download the tools for Windows here: https://www.acpica.org/downloads/binary-tools

and extract all the tables with iasl -g

That also reminds me, I dumped the tables in my Windows VM as well, but forgot about them. Initially, I was thinking that it was OS specific code in the DSDTs that were causing problems, but it turns out that Linux returns true for all OS queries, so it would execute all the same AML code that Windows does. And Windows doesn't even get to that point. lol.

 

Code:

> iasl -g
-g option is deprecated, use acpidump utility instead

I ran acpidump (with no parameters) and here is the output. Let me know if you want me to try something different.

 

I world be very interested in seeing this succeed so I wish you well and will follow closely (I have a 965m in my M6800 and that seems like about as far as I can go) Isn't the P5000 more or less equivalent to the 1080?

 

P5000 (mobile) is actually more or less equivalent to a 1070. It has the same number of CUDA cores, the clock speed is a little lower, but it has double the vRAM. P5000 works in the M6800 but a vBIOS flash is needed before Windows will boot (you can do this from Linux). Actual 1070 of course is cheaper to acquire, but getting Windows booting on it is another story...

 

Equivalence to the 1070 would keep me in VR on my laptop for a few years to come... I will look into what I'd have to do to get the P 5000 in my M6800 ......

 

Directions here: http://forum.notebookreview.com/threads/graphics-card-upgrade-for-m6800.806352/page-17#post-10748094
The vBIOS that you need is included a few pages back in that same thread.
Hard part is finding a place to buy one without paying $1000. You have to use the "make an offer" feature on eBay and get a little lucky.
I think we should keep P5000-on-M6800 discussion in that thread and leave this one to trying to get the 1070 to work.

 

Well, the good news is that I'm posting this from Win 10 on my m6800 / 1070.

The bad news is that it was a bit of a hack job, it's installed on a HD since I didn't have a spare SSD and there are currently a billion pending Windows updates, not to mention disk scanning, so it took a bit to get drivers installed and a benchmark run, just to proof it out.

The only thing I had installed was Valley benchmark and Windows rebooted for updates right in the middle of the first run, but the second completed successfully:

Spoiler

I was getting 3200-3300 on my Win10 VM, so it's about 5-10% faster running bare metal, even with updates running in the background. (Which I guess is mostly disk anyway)

More details to come....

 

I think this error was a symptom of the same problem that caused the FACS table to be missing.

DSDT tables are little bit dynamic. They tend to contain a number of memory pointers that get updated to actual locations depending on how the BIOS boots everything up. For example, tables dumped when Optimus is enabled will have slightly different memory locations and offsets than tables dumped with Optimus disabled. Likewise when other hardware is added/removed, etc. This also affects the memory map that is provided to the OS. (The memory map determines which areas are NVS, which are reserved, etc)

The DSDT contains a number of OperationRegions that initialize fields to specific spots in memory that are supposed to contain memory addresses for use in the DSDT, but like the FACS, they are simply missing values and initialized to 0x0. The above region had this. XBAS was initialized to 0x0, which is an invalid/reserved memory spot. Several other memory regions had the same thing happen. I haven't been able to verify this for sure yet, I'd need to dump values/memory with a "working" card installed.

I started down the road of trying to relocate those regions into safe spots in memory, but it was pretty slow going. Instead, I figured I would try just removing them and any associated device.

The devices turned out to be mostly HDMI audio related, and I'm not sure they were even relevant. (The DSDT has support for multiple generations of GPUs. And after looking at the DSDTs that @Aaron44126 helpfully provided, it looks like the m6800 just piled more on to the m6700 code.)

I trimmed most those out, but still had a few references to in the GFX0 device (the iGPU). In the end, I just removed that as well and disabled Optimus for the time being.

At that point I was able to boot into Windows successfully.