ReBarUEFI as chainloader or standalone EFI executable #118
Replies: 9 comments 33 replies
-
|
This has already been answered before, ReBarUEFI works by hooking functions that get called while the UEFI firmware initializes the PCI devices. However resizing BARs as a chainloader isn't impossible, I actually did that for the first version using hardcoded values but there was an issue where the GPU-Z didn't recognize resizable bar while AMD driver did, this seems to be the exact issue you're facing. I think @Xelafic has done this successfully too It seems like on your system the GPU is allocated in a way it doesn't overlap when resized but this isn't the case on most systems where you need to move it like mine I think we're missing some step needed for GPU-Z to show enabled. Unfortunately it's not public knowledge how GPU-Z probes it so you can only get an answer by asking the GPU-Z dev |
Beta Was this translation helpful? Give feedback.
-
Yeah, I read that in another thread, and I think this is the right thing to do if it's possible to add the DXE to the firmware volume.
It would be nice if there were a version of this available for those of us who can't use the DXE but otherwise have a firmware that does 99% of what is required to support ReBAR, but I'm not sure what this would entail since I'm unfamiliar with the EDK.
Yeah, it's very annoying that they basically just need to recompile the BIOS with something like Since this is a professional workstation that needs to support PCIe cards that ship with a BAR that starts off large, it pre-allocates each slot so that it can use the entire large segment, and reserves the legacy segment for cards which don't use the large BARs. In my experience, all server/workstation class machines do this, but consumer class machines seem to universally not. OTOH, consumer class machines typically don't ship with support for several TBs of RAM, so it's unlikely the system would need to address tens of TBs of address space and thus it would be impossible to allocate a very wide BAR for each slot.
Yeah, I don't actually care if GPU-Z shows it or not because it actually is working just fine. Perhaps I should make a bug report to TPU but 🤷 . |
Beta Was this translation helpful? Give feedback.
-
|
@ziggythehamster Like 99% of systems won't work like yours and require the BAR to be moved for resize to work. For that reason I had to make ReBarUEFI work at firmware level. You can just continue using OpenCore, the only issue with it is GPU-Z. Try asking the GPU-Z devs about how their resizeable bar enabled detection works. I don't really see any reason to develop a separate version that works as a chainloader when only a few systems can work with it. Though technically the chainloader could add a configuration file for BAR/bridge movement making it work on other systems. You can look at the code of first commit if you want to see what a chainloader which moves BAR/bridge and then resizes it looks like. It also has the same issue with GPU-Z. |
Beta Was this translation helpful? Give feedback.
-
Just to confirm, you're still seeing BAR as "disabled" in the latest version of GPU-Z ? |
Beta Was this translation helpful? Give feedback.
-
|
@ziggythehamster this is the same issue I had when I resized after boot, I can't think of any explanation for it showing disabled when it's at full size. @W1zzardTPU I don't think GPU-Z is the problem here, we need to know what's causing this tho so that OpenCore can be updated to do it correctly. It's not related to BAR overlaps atleast for me. |
Beta Was this translation helpful? Give feedback.
-
W1zzard shared a debug build with me that does detect it correctly, but I'm not sure what the detection logic is or what was changed to make it detect correctly. I think OpenCore is doing it correctly, at least for my system.
My BARs don't overlap either, but I can imagine that someone using OpenCore with a system that didn't intend on you using the large BARs (i.e., not like mine) would end up with overlapping BARs, since OpenCore doesn't reallocate the BARs. |
Beta Was this translation helpful? Give feedback.
-
As per NVIDIA's guidance, Turing was hardcoded as "not supported". Now it's assumed that the hardware does support ReBAR and the detection is working accordingly. Thanks for testing by the way. |
Beta Was this translation helpful? Give feedback.
-
I have an RDNA3 RX 7900XTX, though :D |
Beta Was this translation helpful? Give feedback.
-
Yeah it probably mostly is but I'm more interested in why the regular GPU-Z version behaves like this. So that this issue can be fixed correctly at UEFI level. Maybe it could also be the solution to the Code 43 error when using OpenCore to downsize BAR for Windows (other OS is fine). I was hoping I could help my friend with a 4GB Polaris card get rebar (the driver has a bug requiring usage is 2GB BAR) on it without BIOS modding using it but Code 43. @ziggythehamster Idk if I mentioned this before but on the regular GPU-Z build toggling resizable bar in AMD software would make it show enabled. You'd have to do this every reboot tho. |
Beta Was this translation helpful? Give feedback.
-
Yes, hope to get back to this soon. Seemed to work okay for Win/Linux if above 4G enabled but was hoping to run without above 4G and while seems to work in Linux, Win reboots early with no indication/log of error. DSDT on my system has an empty qword that can be filled when not enabled by BIOS, checksum can be corrected, bridge and vga reallocated and MTTR modified. Also as a quick and dirty fix the GPU device is disconnected by UEFI shell, changes/reallocation done, reconnected, console too to give display output at new settings before OS loading. Have to look into doing it all programatically. I think it might be a great way for people to try before deciding on BIOS mod. It would have implications with resume, hibernation and maybe fast boot though. For Turing perhaps a PEI mod to set strap and then BIOS or ReBarUEFI as required to set actual BAR to avoid those issues.
From the author
However in that case bar was shown enabled with just 1GB enabled of the 2GB and doesn't have actual rb capability. A help bubble with definition was suggested but AFAIK not used. I guess we all have are own definitions, mine would be if rb capability exists even if it's set at 256MB. AFAIK it cannot be disabled and therefore must always be enabled if present, just a question of size. |
Beta Was this translation helpful? Give feedback.
-
|
@Xelafic you're sure you can do PCI stuff in PEI modules ? I thought they run before the memory controller is initialized let alone PCI express. The current method of a DXE driver for straps is working fine besides resume from sleep being broken but we know how to fix it and the cause |
Beta Was this translation helpful? Give feedback.
-
|
Probably have to enumerate, setup and parse bridges to look for GPU. I have PEI on my X99 that uses PCI space on the CPU (BUS 0xFF), PEI on here runs in 32-bit. Apparently it is frowned upon to spend time in PEI but my module is close to 1MB mainly due to different microcode versions for testing v3 all core turbo. |
Beta Was this translation helpful? Give feedback.
-
|
I kinda doubt PCIe will work at PEI level, PCIe links have to be trained and stuff for it to work tho I may be wrong |
Beta Was this translation helpful? Give feedback.
-
|
@Xelafic I don't think that's the case with the GPU-Z, it shows enabled for me even with 2GB BAR but if I use an 8GB BAR that was configured after POST it will show disabled. In both cases AMD driver detects if enabled The other user who resized BAR after POST had same behavior. |
Beta Was this translation helpful? Give feedback.
-
|
Also another problem I found was that when downsizing BAR from 8GB to 2GB or 256mb (using both OpenCore or my own EFI) Windows will report Code 43 on the GPU. But the weird thing is that it will work fine on macOS (256mb because OS doesn't support 2GB BAR) |
Beta Was this translation helpful? Give feedback.
-
I can run whatever EFI program after OpenCore if someone wants to collect some data, but unfortunately because the GOP breaks, whatever it logs has to be to a file on the ESP :). |
Beta Was this translation helpful? Give feedback.
-
|
@ziggythehamster you have to dump capability bits using lspci on Linux. There's a software to do it on Windows too |
Beta Was this translation helpful? Give feedback.
-
I probably haven't explained it well because I'm sure you would find it a 'walk in the park' while for me it's more like a walk through molasses. Will try to put something together with more detail. |
Beta Was this translation helpful? Give feedback.
-
|
Using UEFI Shell 1.Find GPU, I've cheated and used 'devices' command. Some extra info using 'dh' command A UEFI script (.nsh) to do the deed |
Beta Was this translation helpful? Give feedback.
-
|
ooooh Turing is hardcoded in GPU-Z to show "Unsupported GPU" Could you email me at w1zzard@techpowerup.com for a test build that removes this limitation? |
Beta Was this translation helpful? Give feedback.
-
|
@W1zzardTPU if you want a better way to check if the graphics driver supports rebar you can if the device-local host-visible memory pool covers the VRAM https://github.com/xCuri0/ReBarUEFI/wiki/Flashing-modified-UEFI#verifying-resizable-bar-is-enabled Same issue on RX 580, it shows unsupported GPU even after doing the registry edit to enable it which increases the pool from 256mb to 8192mb and makes games see a performance boost. |
Beta Was this translation helpful? Give feedback.
-
|
This particular check is "does the underlying hardware support the feature", not "is it enabled", or "does the driver support it", which is two additional, separate checks
Correct, I'm using "Navi 1x or newer" for AMD. Will update the test logic. Any idea what the actual cutoff is for ReBAR, in terms of GPU generation? |
Beta Was this translation helpful? Give feedback.
-
|
@W1zzardTPU I'm unsure about what AMD generations support resizable BAR I just know Polaris 8GB does with a registry edit |
Beta Was this translation helpful? Give feedback.
-
|
That still helps a lot, because it means Vega, too. |
Beta Was this translation helpful? Give feedback.
-
Looking good, send me an email to w1zzard@techpowerup.com, so I can send you a test build that fixes "Unsupported GPU"
I think you mean disabled? |
Beta Was this translation helpful? Give feedback.
-
No, CSM enabled, not because it was required but because I could. GPU-Z screenshot reports this correctly 'CSM disabled - No'. Also technically above 4G wasn't enabled in BIOS but after POST but I think it doesn't matter really. |
Beta Was this translation helpful? Give feedback.
-
|
I would be interested to know how exactly can I do the memory allocation for a new BAR size, after POST, like in a GRUB module for example. So do you know more about using OpenCore for this ? What API does it use ? I think I also need to disable GOP, but hopefully after GRUB chooses to boot the OS. And I would like to find out if the same style of hook used by @xCuri0, replacing the function pointers in the UEFI protocol structure, would work here to completely hook all the GOP functions and replace them with a mock-up, that does nothing and leaves the screen black or with a proper message displayed... |
Beta Was this translation helpful? Give feedback.
-
|
OpenCore rebar only works for systems like @ziggythehamster which don't have BAR overlap because they keep distance between each PCI port BARs so hotplug can work (if I'm explaining it correctly) Using OpenCore rebar on a regular desktop system will result in BAR overlap and crash as a result of that |
Beta Was this translation helpful? Give feedback.
-
I think that this would be the case most of the time, but I'm sure there are some boards out there which similarly implement everything except actually resizing the BARs like I have. But also, such systems would most likely still POST if your UEFI is modified, whereas mine refuses to. I think this is called "measured boot" and consumer systems tend to either have Secure Boot fully on or fully off, not the middle-ground that I seem to have and cannot disable |
Beta Was this translation helpful? Give feedback.
-
|
@terminatorul the first commit of ReBarUEFI does it using hardcoded values But don't use it because it has some severe issues like only working with CSM on. Ask @Xelafic to send his code because it seems to fix this and also some other issues |
Beta Was this translation helpful? Give feedback.
-
I have a Lenovo ThinkStation P920 (type 30BC) and was unsuccessful getting the DXE added to the firmware - the system rejected the BIOS image due to BIOS Guard (refused to POST when SPI flashed, front panel readout and beep codes indicated BIOS Guard rejected it).
This system is peculiar because it has an Intel C621 chipset - which supports ReBAR - but Lenovo will not add the BIOS option to enable it. With the options they do provide, the PCI bus entries show up in Large Memory and are properly allocated, which means that Linux is perfectly capable of enabling ReBAR on boot, but Windows lacks this and does not.
Doing some research, I saw that OpenCore is able to resize BARs (and not reallocate them, but that is perfectly acceptable because the system has already allocated the large BARs), and after dealing with OpenCore's Hackintosh-specific documentation, I was able to get it to work. There is an annoying issue, however: my GPU's GOP driver stops working after BARs are resized, and OpenCore resizes BARs before displaying the boot menu. So I effectively can only use OpenCore to boot one hard-coded OS. This is no big issue, but OpenCore does a whole lot of stuff that is not necessary simply to reprogram the BARs, and I figured that there is probably a way to make a version of ReBarUEFI that incorporates the working resize code from either ReBarUEFI or OpenCore and the minimal amount of code needed to then execute another .efi loader after reprogramming the BARs.
I know this was talked about in other discussions and an idea was to use
safeboot-loader, but I looked around at it unless a whole lot of the Linux PCI init routine is disabled, I don't think that enabling PCI support insafeboot-loaderand passingpci=reallocwould result in Windows booting correctly.The BAR resize code in both ReBarUEFI and OpenCore (linked above) appears to be pretty self-contained, and I could probably cobble together an EFI executable that does the BAR resize and exits, and then run a UEFI Shell script that runs it and then runs the Windows Boot Manager, but I don't think I know enough about UEFI/EDK to make one executable that does both things. So I figured I'd document how I got it working "in user space" and see if anyone here has thoughts on how to make it better :).
One thing I will add - GPU-Z shows all of the things as "Yes" but still shows ReBAR as "Disabled", even though the AMD drivers show ReBAR is enabled, the GPU shows up under Large Memory, and I see a 10-15fps performance gain. I assume it's a bug or it's reading some BIOS-related setting that is irrelevant here.
BIOS configuration options
These options are under Common RefCode Configuration in whatever screen that is:
OpenCore configuration
Beta Was this translation helpful? Give feedback.
All reactions