-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Ability to blocklist/ignore DEV IDs #269
Comments
I'd be willing to test, I can SPI-flash the chip back (I have backups of all boards involved). |
Where is this stated/shown? I am having trouble enabling ReBar on one of my two GPUs, this might be what is causing it. |
Linux system. I can't recall exactly, I think Edit: This was time-consuming but I succeeded. I cloned the repo but the BIOS didn't like the master build so I decided to painstakingly reverse-engineer the ReBarDxe.ffs to byte-patch the Sapphire routine a bit which was more difficult than I thought because the compiler optimized the code and made it difficult to patch the routine as it ran directly into mixed code. Instead, it checks for 0x10DE and 0x1BB1 and specifically jumps to the rest of the external loop correctly (effectively 'skipping' the bar by returning "0", not that it touched any pointers which the compiler-optimized code tried to do). I corrected the checksum, patched that one byte from 0x07 to 0xF8 just like MMTools would try to do and it's working now. :D PNY Nvidia Quadro P4000 (Pascal, no bar support) and Sparkle Intel Arc A310 ECO LP in the same system with Intel getting a bar now. I have a fork if anyone's interested in trying it. See the commit to find out where I patched it (but modern compiles of even untouched binaries don't seem to work, something's changed in the compilation process). (Edit: I forgot to mention I still had to change that one byte in |
You can submit a PR, I don't have any way of testing multi GPU stuff. |
I would but I think it best to get the opinion(s) of someone that regularly works with UEFI modules and knows about any restrictions around how much NVRAM is allowed to be used. "ReBarState" is a small enough variable to store in NVRAM but I'd like to think ReBarState could be expanded upon to be allow/blocklisting based on devices individually with device-specific bars as well, maybe even fail-safe design (as much as possible anyway). (I'm aware of "disabled by default", I'm talking about fail-back-type.) I'll find time to submit a thought in reasonably full-form for input. |
I've found I'd really like to use two different GPUs, one that doesn't support ReBar and the other does. Having both in the system prevents the second one from being able to read the PCIe configuration space.
I don't do UEFI-programming but it looks like
reBarSetupDevice
might be an area where I can skip changing a bar for a specific device? I don't mind compiling it myself. A simple line commented-out saying "if you want to blocklist/ignore a device, uncomment this after filling in vendor ID and device ID" or something?I haven't read all of the code but I'm wondering if
reBarSetupDevice
vid, did
can can be compared (after being set viapciReadConfigWord
) to the device ID I wish to ignore.(Around line 205):
This is of course assuming I got the endianness correct and the correct block of code. I doubt most people need it but having that card in breaks the ability of the other card to read the PCI configuration space, so this was my quickest thought.
It'd be nice if this didn't need hardcoding, such as having ReBarState being able to set another NVRAM var of 4 byte entries (enter vendor ID, enter device ID, stored as 2B2B per entry) so we could do things on the fly without needing to recompile or hard-code but I'll take hard-coding if it gets it into ReBarUEFI.
Edit: Would
pciRebarGetPossibleSizes
be a better place to put it, similar to the ATI quirk?The text was updated successfully, but these errors were encountered: