DIY eGPU experiences

Vostro 1320

Intel Core 2 duo T6670
Intel 4500mhd
4gb Ram
windows 7 64 bits

Woot | Flickr - Photo Sharing!

 

Yea I had that same confusion as well. I was under the assumption that the 2.1a products you guys got was the full product. I was very close to ordering it on Mar 6, but I guess its better that I waited to see all of your results.

I really don't know how they delineate between engineering samples and official product versions. The funny thing is, he mentioned that the first batch of 2.1 samples had sold out, and that the official product versions were on pre order now. However, in a later email he said "If you think about ordering now, please wait for a few more day just in case." As if I would get another engineering sample if i pre ordered that day.

Either way, i completely agree that engineering sample or not, the product should at the very least work!

 

So, I just registered, and maybe someone can help me with a problem I am having.

This may sound a bit strange and maybe off-topic, but I assure you it is not off-topic, so please bear with me. Anyway, I recently decided to build a low-power desktop system. I chose an Intel miniITX motherboard called the D525MW, which is based around the Intel Atom D525. Regrettably, the board does not have a PCI express slot for adding a desktop graphics adapter (because I want to use the system for light gaming, and the GMA 3150 integrated graphics is just aweful), but it does have a mPCIe slot. Prior to finding this site, I stumbled upon the PM3N mPCIe adapter and the PE4L v1.5 breakout device, so I ordered them.

After messing around with the adapter and encountering the Error 12 issue, I purchased a copy of DIY eGPU setup 1.x, and after a bunch of adjusting, I figured out how to make the system boot and work the way I want it to... mostly, which brings me to the reason for my post.

While I am able to get the system to work with the external GPU (in this case, a Zotac GeForce GT 520 PCIe 1x Edition), I have a problem with the system. When I boot the machine up with the graphics adapter attached (both with and without running DIY eGPU setup 1.x), it boots REALLY slowly. As in, it takes nearly an hour to make it from the POST screen to the Windows 7 log in screen (normal boot time is about 15 seconds), and it persists in being really slow even after booting. However, if I put the computer into standby (not hibernation) and bring it back, the problem goes away entirely. From that point, if I previously ran DIY eGPU setup 1.x, I can play games, high-definition video, or anything else I'd normally do with the machine with no problems whatsoever. I've seen posts by people who seemed to be having the same problem with their NVidia external GPU, but no mention of any real solutions. Does anyone know what the problem might be, and how I might be able to fix it instead of having to wait an hour for Windows to be ready to allow me to put it into standby?

Again, my hardware configuration:

Intel D525MW motherboard
Zotac GeForce GT 520 PCIe 1x Edition
4 GB of RAM
PM3N + PE4L v1.5

Also, as a side note, this is probably very obvious and I expected it, but when my setup works, man, is that Atom processor ever a bottleneck... It is soooooo close to being playable with games like Fallout New Vegas and Valve's Source Engine games, but it just isn't quite there. I'm considering overclocking, but it looks like it might be difficult for this board...

 

Please refer to Pre-Purchase FAQ > "2. How can I check if my notebook is compatible with an eGPU?". Please read from "Identify this by looking for the first PCI bus entry with a 8 digit memory address...". (TIP: The "8 digit" is referring to the hexadecimal number on the left of "PCI bus".)

Can you boot with eGPU power ON:-
1. run Setup 1.x
2. before Chainload power OFF eGPU
3. Chainload
4. In windows, put computer to sleep/standby
5. Power ON eGPU
6. Resume

 

I must be retarded Because i didnt Understand.

 

no more 4GB+ issues: use a DSDT override to extend the root bridge into 36-bit space (Windows only - MacOS/Linux are unaffected)

36-bit DSDT override user contribution repository>>>

Below are the contributed DSDT overrides created using the details of this post. Linked here to easily find them.

Dell: Latitude E4300, E4310 (nando4), E6400 (dummyaccount), Studio 1557 (kizwan)
Samsung: 400B2B (xxlukexx)

Introduction>>>

This problem and solution is only relevant to Windows operating systems. MacOS ignores the root bridge and can allocate in 64-bit space as kizwan found here. Linux has a "noCRS" kernel parameter to ignore the root bridge boundaries so the OS can also also allocate in full 64-bit pci-e space.

A small number of problematic systems like the Dell Latitude Ex410 series, Samsung Series-4, Sony F-Series and MSI CRx20 have insufficient free 32-bit PCI space to accomodate a eGPU if have 4GB or more of RAM installed. They can't use Setup 1.x's PCI compaction to create sufficient space because they either have TOLUD=3.5GB, or a lower TOLUD like 3.25GB but with an unmovable systemboard device occupying candidate free pci space making it unusable.

Need a 36-bit root bridge DSDT override

I happened to run into one of these problematic systems - a Dell E4310 with TOLUD=3.5G, which can be maxxed out at 16GB of RAM. It's too nice an ultraportable to be need to resort to 3GB of RAM to use an eGPU. So I set of in pursuit of how to add a DIY eGPU to it which is documented below. The same solution can be applied to any 3-gens old PM965 chipsets (2007) or newer system. They have a 64-bit CPU and chipset so are fully PAE/64-bit compatible. This fix may mean not requiring Setup 1.x at all so is really quite a nice way of fixing this problem.

The solution requires the eGPU to be hosted in 36-bit PCI space. However, just using Setup 1.x's 36-bit PCI compaction on the eGPU to relocate it in such space will see the eGPU still give an error 12 in Device Manager. Why is that?

Avlan confirmed that the 32-bit root bridge definition limited allocation only to 32-bit space. The fix being a modified DSDT loaded as a registry override that extends the root bridge (ACPI PNP0A08 or PNP0A03 device) into 36-bit space. Avlan's fix was cryptic so wasn't attempted on other systems.

After a bit of digging I found the QWORDMemory DSDT static resource entry can be used to easily extend root bridge entry into 36-bit space.

Ref: [Qemu-devel] [PATCH 6/6] 64bit PCI range in _CRS table plus two examples at virtualbox and Coreboot.

Example 36-bit root bridge DSDT override>>>

We can do extend the E4310's root bridge into 36-bit space with the following steps. The iasl and asl tools used plus the modified E4310 DSDT table are in DELL-36b-root-bridge.rar.

NOTE: kizwan expands steps 1-3 here. Useful if you need more assistance with these steps. Kizwan also provides a video tutorial here.

1. Identify the resources used by the PNP0A08 or PNP0A03 devices in Windows. This can be found by perusing Device Manager->Resources by connection->Memory. Then check the last PCI BUS entry. Eg:

Spoiler

2. Capture the DSDT table using:

Code:

iasl -g

3. Open the resultant [].dsl file and look for the PNP0A08/PNP0A03 'DWordMemory' resource entries. Under the last DWordMemory entry in that area, add a 'QWordMemory' (64-bit) entry such as the one in RED below. I ensure that I stay in the 36-bit range (< 64GB) so the location is compatible with the PAE-capable Win7 32-bit. I also chose a location above 48GB so we won't have issues with maxxed out memory. The range chosen was 48.5GB to 56.25GB.

Code:

DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
   0x00000000,         // Granularity
   0x000A0000,         // Range Minimum
   0x000BFFFF,         // Range Maximum
   0x00000000,         // Translation Offset
   0x00020000,         // Length
   ,, , AddressRangeMemory, TypeStatic)

[COLOR="Red"][B]QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
   0x0000000000000000, // Granularity
   0x0000000C20000000, // Range Minimum,  set it to 48.5GB
   0x0000000E0FFFFFFF, // Range Maximum,  set it to 56.25GB
   0x0000000000000000, // Translation Offset
   0x00000001F0000000, // Length calculated by Range Max - Range Min.
   ,, , AddressRangeMemory, TypeStatic)[/COLOR][/B]

4. Create a [].aml file with the 'iasl [].dsl' compiler directive. It may fail to compile because of of some minor syntax errors in the dsl file. Those will need to be corrected with common fixes explained in How to fixed DSDT errors? (kizwan). It may help to try a newer IASL version 5.0 iasl-win-20120320.zip and ask for guidance at tonymacx86.com DSDT forums. DSDT editting alone could have it's own forum. Then try compiling your DSDT again.

Code:

iasl E4310.dsl

5. Loading the [].aml file into into the registry as a DSDT override using 'asl /loadtable [].aml'. You must be an admin user for this to be successful.

Code:

asl /loadtable E4310.aml

6. Check you now have a 36-bit PCI BUS (> 0x100000000) entry in Device Manager->Resources by Connection->Memory as shown below:

Spoiler

7. While my PE4L 2.1 isn't working atm, so I can't confirm it on the E4310, I can say the same fix was done on a Dell E4300 and Win7 did automatically allocate the eGPU into the 36-bit space. If you still see error 12 then there are two options to pursue:

i) Re plug'n'play the devices. Go into Device Manager -> Video cards, delete the eGPU. Also go into Device Manager -> System devices and delete the PCI Express Root Port x entries.

Upon restarting the system, halt Win7 startup with F8, attach and power on your eGPU and then proceed to load Win7. Win7 should now be clever enough to re-allocate the eGPU into 36-bit space upon realizing there is insufficient 32-bit space to host it.

Can go one step further and delete your eGPU NVidia/ATiAMD driver, restart the system and reload it. That may help as well.

(ii) Hard allocate the eGPU into 36-bit PCI space before booting Win7 using Setup 1.x. The next Setup 1.11a has integrated the DSDT override details so will give the user a list of endpoints that bound the PCI compaction, eg: '36-bit (56.25GB)'.

With the current Setup 1.10b5 need to do this manually. At the DOS prompt create a new pci.bat relocating the eGPU to 56.00GB:

Code:

cd %DRV%:\config
compact pciend E10000000 useonly [eGPU PCI ID] makebatch pci.bat import devcon.txt
call pci
:: Chainload the MBR
call grub4dos mbr

The result will be similar to that shown in the spoiler in step 6 above, but with the eGPU rather then the Intel HD iGPU being in 36-bit PCI space. Can then proceed to automate this by editting your %DRV%:\config\startup.bat (or V:\config\startup.bat in windows) so can just select the Automated startup via startup.bat Setup 1.x bootitem and have it do everything for you:

Code:

call speedup lbacache
call vidwait 60 [eGPU PCIID]
call vidinit -d [eGPU PCIID]
call pci
call grub4dos mbr

Testing results>>>

* Dell E4310 (nando4): SUCCESS! I relocated the Intel HD iGPU into 36-bit space using Setup 1.x as shown in step 6 above freeing 256MB of contiguous 32-bit space to host an eGPU, so it will definitely work. Plus there is plenty of 36-bit space for the eGPU too. Unfortunately my PE4L 2.1 isn't working so I can't show the iGPU+eGPU both being active but it will work

* Dell Studio 1557 (Kizwan): SUCCESS! His HD5870 successfully relocated to 36-bit pci-e space.

FAQ>>>

1. When do I need to hotplug my eGPU to overcome the error12 with a DSDT override?(kizwan)

2. How to clean the DSDT override properly? (kizwan)

(*We will need to delete DSDT key in registry)

Code:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet[B][COLOR="Red"]XXX[/COLOR][/B]\services\ACPI\Parameters\DSDT

* where [B][COLOR="Red"]XXX[/COLOR][/B] are 001, 002, 003 & so on.

and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ACPI\Parameters\DSDT

I didn't really tested whether deleting "DSDT" key in ControlSetXXX (XXX are 001, 002, 003 & so on) really necessary but I will test this when I test your latest Setup 1.x. For sure deleting "DSDT" key in CurrentControlSet is necessary. You can access registry via command line. So, you can put it in .bat file.

 

Before originally posting here, I had tried this a few times already, and it still drastically slows down during Windows boot, even if I disconnect the eGPU before continuing to boot Windows.

To be more specific, these are the conditions under which the system will majorly slow down during Windows booting:

1) Powering on with the display card connected and booting Windows.
2) Powering on with the display card connected, disconnecting the display card before booting, and booting Windows.
3) Powering on with the display card connected, running Setup 1.x, and chainloading to Windows.
4) Powering on with the display card connected, running Setup 1.x, disconnecting the display card, and chainloading to Windows.

I have tried a few different configurations that all result in a working system that has the same start up slow down, including compacting everything to 32 bit space, putting the eGPU in 32 bit space and the GMA 3150 into 36-bit space, as well as just disabling the iGPU entirely.

Also, an unrelated issue that someone has probably mentioned before:

Something else that I would like to mention is that I have noticed that, if you hibernate the system, that Windows Hibernation somehow seems to take precedence over the normal Bootloader, preventing me from running setup 1.x before it attempts to come out of hibernation. It will, however, warn me that the PCI devices are not on the same addresses as they were in the hibernation file, and it will give me the option to boot anyway (obviously doesn't work) or clear the hibernation data and proceed to the normal bootloader. Is there a work-around for this that would allow me to force Setup 1.x to run before this check? (Kind of important to me, as I normally use Windows Hibernation a lot, though I could live without it if I had to)

 

I don't know what you had tried before since you didn't mention about it in your first post. I'm going to assume you already tried everything. I think you also already tried boot with eGPU OFF, sleep/standby, turn ON eGPU & resume.

When wake up from hibernate, it will resume straight to windows. That is how it works. The only way you can enter Setup 1.x before resuming from hibernate, IF Setup 1.x have it own bootloader.

 

ASUS K/A42JV + ATI Radeon HD 5870 eGPU @x1

Asus K/A42JV have dynamic TOLUD which BIOS/UEFI will lower the TOLUD automatically to accommodate the eGPU. This allow all three GPUs; Intel HD Graphics (iGPU) + Nvidia GT335M (dGPU) + ATI Radeon HD 5870 (eGPU); active at the same time.

Default TOLUD 0xB0000000 = 2.75GB (when boot without eGPU connected)


TOLUD 0x90000000 = 2.25GB




Another interesting fact, at least on this notebook, I can't use Optimus with dGPU when eGPU is active. So, most likely I don't have to disabled dGPU if I implement Optimus setup (x1.Opt) with Nvidia Fermi desktop graphic card later.

 

@Nando

what do you with you PE4L is not working? Becasuse in the moment some other guys and I are having the problem that our new Pe4l 2.1 a is not detecting anything.

I the moment I just want to make sure that i am not too stupid to use an egpu before I annoye Bplus with my problems.