Skip to content
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

Open
OdinVex opened this issue Jan 30, 2025 · 5 comments
Open

[Feature Request] Ability to blocklist/ignore DEV IDs #269

OdinVex opened this issue Jan 30, 2025 · 5 comments

Comments

@OdinVex
Copy link

OdinVex commented Jan 30, 2025

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 via pciReadConfigWord) to the device ID I wish to ignore.

(Around line 205):

/*
 * If you need to ignore certain devices you can blocklist
 * vendor ids and device ids such as Nvidia PNY Quadro 4000,
 * which as a vendor ID of 10DE and device id of 1BB1.
 */
/*
 * if (vid == 0x10DE && did == 0x1BB1)
 * {
 *      DEBUG((DEBUG_INFO, "ReBarDXE: Blocklisted device vid:%x did:%x\n", vid, did));
 *      return;
 * }
 */

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?

@OdinVex
Copy link
Author

OdinVex commented Jan 30, 2025

I'd be willing to test, I can SPI-flash the chip back (I have backups of all boards involved).

@starrycat2015
Copy link

Having both in the system prevents the second one from being able to read the PCIe configuration space.

Where is this stated/shown? I am having trouble enabling ReBar on one of my two GPUs, this might be what is causing it.

@OdinVex
Copy link
Author

OdinVex commented Jan 30, 2025

Having both in the system prevents the second one from being able to read the PCIe configuration space.

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 dmesg. In short I have an (PNY) Nvidia Quadro P4000 and while it supports UEFI (found a legit UEFI BIOS for it, flashed) it doesn't support ReBar but the Sparkle Intel Arc A310 ECO LP does. I was so sure I had successfully modified my BIOS (manually patched the DXE in, I did not use UEFITool) but every time I booted neither showed working. Eventually discovered that the Intel was trying to work but couldn't read the PCI configuration space because it was being borked because of the other card's presence alone.

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 ReBarDxe.ffs at offset 0x17 from 0x07 to 0xF8. That I have to do no matter what for it to work on this board. It's the "EFI_FFS_FILE_HEADER->State" byte?)

@xCuri0
Copy link
Owner

xCuri0 commented Feb 1, 2025

You can submit a PR, I don't have any way of testing multi GPU stuff.

@OdinVex
Copy link
Author

OdinVex commented Feb 1, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants