LGA1151 PCI allocation limited to 64GB #163
Comments
|
You're going to need to create a new UEFI patch for this. The hardware (anything Haswell or newer) is capable but for some reason OEMs don't use the full addressing capability of the CPU. It seems like they only use 64GB on LGA1151 which would only be able to support 1x P40 in combination with internal PCIe devices. This screenshot might help you, you need to patch the
|
|
I suggest you go with |
|
Okay. At the moment I am still trying to figure out how to get to the code from what I extracted with UEFITool. I used some of these tools a year or so ago when you helped me with a P40 on another board and I still have the files from all the steps but I don't remember how I got there. |
|
@crashr it's Ghidra disassembler with efiSeek plugin. You need to use it on PCIhostbridge extracted PE32 |
|
Wow, i didn't know about that software. But I have trouble to identify the function call. Tbh I am not sure what actually looking for. I inspected all found functions and labels manually but wasn't able to spot something related. Is this maybe something I am looking for?
At least this function is called very
This is the code clostest to that in your screenshot that I could find.
|
|
@crashr try searching for |
|
Facepalm. So obviosly to search for 0x1000000000. Ok, but now I think I know what to do. Please correct me if I am wrong.
To be on the save side I wait for an answer before doing this. In the mean time I'm going to find out how to make a patch of this. |
|
@crashr yes that's correct. Change all 3 instances to the values I told ( First value is mmio base and second value is size. It should give you 320GB of BAR space. |
|
For patch you just need to compare in hex editor after saving the modified PE32 in Ghidra |
|
Do I actually really need the patch or could I just add the modified EFI module to the UEFI file? 8D6756B9-E55E-4D6A-A3A5-5E4D72DDF772 10 P:040000004823C1483BC2480F47D04C2BC27411:100000004823C1483BC2480F47D04C2BC26690 I read somewhere how the format works but how to know the string "8D6756B9-E55E-4D6A-A3A5-5E4D72DDF772"? |
|
Btw did Ghidra add some text to the file. Looks wrong to me. Have I maybe done something wrong? Should I remove it from the binary? |
|
@crashr you need to export as PE in Ghidra, the file sizes should be exactly the same as original |
|
And yes for now you can just do PE32 replace in UEFITool. Once it's tested and working we can make a UEFIpatch entry |
|
Sounds good. Will try. |
|
Bad luck. Doesn't POST at all. The BIOS file seemed a bit unusual to me but I assumed that has to do with something UEFITool does: So seems I first need to unbrick the board somehow. |
|
Maybe 320GB is too much you could try with smaller size next time. Or maybe it's unrelated to the patch and POST issue is caused by UEFITool messing with pad files. |
|
I was able to flash the original firmware, board is up and running again. Since right now I still have rpi and wires connected for using flashrom I can experiment a little bit. |
|
Seems to be UEFITool. I extracted PciHostBridge and reinserted it unmodified. The resulting Image differs from the original image. |
IMHO most likely.
Check the padded area. If compressed file looks different it may just be a difference in compression algo, as long as it decompresses Okay should be fine. @crashr If using UEFITool then try just operating on the volume with the file to be modded instead of the whole firmware image unless there's 'non-empty' padding there too. |
|
I did not see any differences in the padding sections. Also I tried with fiano with more or less same results. I will try again the next days when I have time. |
|
What is actually the reason for changing the base to 0x2100000000? Why not leaving it at 0x2000000000? |
|
It's not needed yeah |
|
No success so far. I tried 0x2000000000 as size. The diff looks like this: But PC just doesn't POST with a modified module. But it POSTs if I replace the module by the unmodified module so can I assume that what I want is just not possible? |
Strange, if I look at your BIOS with UEFITool I get this. First time hearing of fiano, so some other issue then I guess. Hope you get it resolved. 🤞 |
https://forums.overclockers.ru/viewtopic.php?f=1&t=479847&start=9860 Seems to be this. |
i made this patch for supporting 128G DRAM on Clevo LGA1151 Z170/Z270/Z370 notebooks. |
|
@dsanke this also increases the size from 64GB to 128GB am I correct ? should be good for 3x NVIDIA P40 |
|
@xCuri0 this patch resolve "pci resources error" when installing 128G DRAM. make BIOS allow 128G DRAM is not this patch. |
|
@dsanke I am pretty new to this. Could you please explain why to choose base and size exactly like this? |
|
@crashr |
|
@dsanke I am not sure if I got you right. You modified AddMemorySpace, right? Your modification allows to use 128 GB of system RAM but according to my tests still doesn't allow to allocate more than 64 GB address space to PCI. Since there are no other occurencies of 0x1000000000 or 0x2000000000 as to my understandings it is not possible to achieve that. |
|
@crashr so you still can not work with more than one p40. we need dive deeper. i have no clevo machine handy, so i can not determine the pci resource address changes. i compared the clevo machine, which have large memory 256G to 384G for pcie root complex showing in windows device manager after modification. |
Hi.
I have a MSI H310M PRO-VHD Mainboard with a i5-8500 and 8GB RAM which works fine with a single NVIDIA Tesla P40 under Ubuntu 22.04 but doesn't POST with 2 or 3 P40. There are some forum posts where someone wrote to the MSI support and they said that they never testet P40 on that mainboard. Is there a chance to get more than one GPU running by BIOS patching? Is this actually a BAR issue?
The text was updated successfully, but these errors were encountered: