First time seeing Resizable BAR on a SLI/Crossfire system.
Can you share some performance comparison benchmarks if possible ?
You can post your modded BIOS in Offers: Already modded special BIOSes - Win-Raid Forum if you want to
Thank you very much for your entitled question.
You are right - the Forum visitors expect the main information about the related topic within the first post of a thread and not within the second or any later one.
The reason for this misleading post order was a system related mistake, which happens by merging 2 different threads about the same topic. The other thread had obviously been started 1 year earlier with a question, but your contribution contains the answer and covers much better the title of this thread.
As a consequence I have solved the problem by moving the complete thread (except the former start post) and deleting the old thread thereafter. “Your” new thread has now gotten a slightly different title (otherwise it would not been possible to move the thread within the same Forum Category), but you can easily change it at any time by editing the start post.
Thanks for your understanding!
Dieter
1 Like
Just ran into first problem, I was gonna do some benchmarks for you, so went into bios to disable rbar and my pc would no longer boot, it just hung on asus bios code d4, which it says is pci resources?
@Dudette you need to do CMOS reset
you probably disabled 4G decoding.
use the NvStrapsRebar configuration app you showed to disable rebar
So never disable it ?
Just wanted to make sure rbar was off for comparison.
Completely forgot you can disable rbar, without disabling 4g decode.
I’m sure I never saw an option in app to disable, only enable?
Hi there again 
.
First, great job on keep supporting and maintaining this project. It has helped many people to gain free performance thanks to your effort! And also for everyone else who has finding fixes. Many thanks!..
Since the last added patch for X79 systems I decided to redo the BIOS with ReBAR for my P9X79-Pro, and I ran again into the padding corruption problem.
Upon patching Runtime module, padding would get corrupted and no workaround helps.
Recently, @ZOX found a solution for those who get a padding corruption from patching IvtQpiandMrcInit. Sadly, just following his solution isn’t enough so I tried to investigate a little more and these are my foundings:
-
Patching PciBus and IvtQpiandMrcInit (together / separately) without patching Runtime does not corrupt the paddings
-
Patching Runtime (alone / altogether / separately) corrupts padding and no workaround helps (extracting patched Runtime module using UEFITool and replacing it in the unpatched BIOS using MMTool4.50 or UEFITool)
-
Runtime patch deletes the first Pad-file, replacing it with FFs. To find the differences between BIOS with the patched Runtime module and the unpatched one, I patched only the Runtime module and compared it using Guiffy (since it is a free option that finds changed in the file and does not simply compare each offset like HxD) trying to mimic @ZOX’s solution.
Apart from the changes of the Runtime patch itself, you can see it deletes the Pad-file too and replacing it with FFs as mentioned.
What’s unclear to me is why MMTool4.50 or UEFITool deletes the Pad-file when solely replacing the Runtime module, as the Pad-file is outside the Runtime module and a lot of offsets below! Beats me… -
Replacing unpatched BIOS Runtime module in UEFITool and selecting “Do not rebuild” on the first Pad-file below BootPriority module results in two Pad-files one after another.
Trying to delete either the first or the second Pad-files below BootPriority module would result in padding corruption as shown in the picture in option 2. -
With HxD I searched all Pad-files existing on the unpatched BIOS and compared it with the BIOS from option 4, trying to locate which Pad-file was incorrectly added.
Normally it would return 4 hits (and on the Runtime patched BIOS which also corrupts padding, it would return 3 hits). Deleting one of the two Pad-files to achieve same Pad-files offset location as the unpatched BIOS. Finally, starting to see some results
, but we still have errors to fix.
-
Adding same amount of FFs characters as the Pad-file to the end of volume 3 (the volume with ReBarDxe.ffs) would fix the last two errors.
-
I thought to try patching again after I fixed the Pad-file issue, maybe it would fix the unaligned Raw files (as I previously isolated the PciBus and IvtQpiandMrcInit patches for easier troubleshooting, since Runtime patch is the problematic one).
Patching Runtime alone doesn’t find anything to patch (good, it means Runtime really is patched), so no output BIOS file.
Here where it gets interesting.
Patching IvtQpiandMrcInit alone returns as we would expect (with IvtQpiandMrcInit patched), sadly it did not fix the unaligned Raw file issue.
Patching PciBus alone seems “fix” the unaligned Raw file issue by corrupting again the Pad-files (meaning, deleting the Pad-file and replacing it with FF at the end of volume 3 respectively). What seems to happen here is because PciBus is in volume 3 same as Runtime it rebuilds it, hence gets corrupted again (same would happen if I just would press rebuild in UEFITool).
Simply patching the BIOS with all the patches at once and then add the deleted Pad-file before the Raw (offset 2CB388) and the remove FF characters respectively from the end of volume 3 (where ReBarDxe.ffs is located), and we get again the unaligned Raw file issue, but the Pad-files are now fixed.
If anyone here similar with this error and knows how to approach this I would appreciate your help very much!
Thanks for reading, every if you don’t have a solution to offer.
1 Like
Runtime patch isn’t really required, you can just ignore it.
Yet, I want to try to fix it if possible. Just thought sharing here what I have found, maybe someone else stumbled upon this problem too so it would also save them some effort.
Hello, May I ask if you have perfectly used Resizebar on P8Z77-V?
If available, I hope you can share it, thanks a lot!
The unaligned Raw file issue is due to the requirement of starting at the 8th byte.
Here is how it is supposed to be (injected, pre-patch)
UEFITool’s solution was to delete the Pad-file and replace it with the amount of needed FFs at Volume 3 free space, so the Raw file would start at the 8th byte.
As you can see in my previous post (under option 5), when added two Pad-files one after another aligned the Raw file correctly, hence there was no error about it.
Notice in the pictures how before some of the Pad-files there are FFs (empty data) - it is there for alignment only. You can also find it after some modules (you’ll find 00 at the buttom of the module, marking that the module has ended) and it comes in order to align correctly the next module.
Perhaps there is a limitation of the maximum number of FFs that can be inserted for alignment before it is being recognized as part of the BIOS, or maybe the data / header checksum needs to be adjusted after adding more FFs (if so I didn’t manage to succeed doing it).
Here is my try of aligning the Raw file
You can see pre-existed FFs that UEFITool added for alignement (after it deleted the Pad-file) compared to the previous picture. In here I added the deleted Pad-file again and inserted FFs so the Raw file would start at the 8th byte. Sadnly it was not enough.
If anyone here knows how to deal with this error or how to approach this I would appreciate your help a lot!
Thanks for reading, every if you don’t have a solution to offer.
1 Like
Asus P9X79-Pro?
Yeah. I am aware the bug Kuri0 mentioned, I am trying to fix it.
ReBar modded bios with Runtime module patches. Paddings are preserved.
I used a method from 2014. It was proposed for phoenix legacy bios mods to deal with insufficent space to manipulate modules.
The problem with paddings occurs when one or another module changes in size. UEFI compression can be compared to the way .png images are compressed. A sequence of FF FF FF FF is much easier to compress than 01 02 03 04. If we can’t grow or duplicate paddings in order to achieve proper alignment, why not to edit the module?
3 Likes
I am attempting to enable Resizable BAR on my Dell Optiplex 7060 with the latest BIOS version (v1.28.0) running Ubuntu 22.04 in order to improve driver performance on my Intel Arc A380 GPU. Following a guide to enable hidden 4G decoding, I identified the VarOffset values in Setup for “CSM Support” and “Above 4GB MMIO BIOS assignment”:
0x55A2C One Of: CSM Support, VarStoreInfo (VarOffset/VarName): 0x11AD, VarStore: 0x1, QuestionId: 0x2805, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 91 BE 17 BF 17 05 28 01 00 AD 11 14 10 00 01 00}
0x55A3D Default: DefaultId: 0x0, Value (8 bit): 0x1 {5B 06 00 00 00 01}
0x55A43 One Of Option: Disabled, Value (8 bit): 0x0 {09 07 04 00 00 00 00}
0x55A4A One Of Option: Enabled, Value (8 bit): 0x1 (default MFG) {09 07 03 00 20 00 01}
0x55A51 End One Of {29 02}
0x566F3 One Of: Above 4GB MMIO BIOS assignment, VarStoreInfo (VarOffset/VarName): 0x8E1, VarStore: 0x1, QuestionId: 0x5A4, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 91 A4 08 A5 08 A4 05 01 00 E1 08 10 10 00 01 00}
0x56704 Default: DefaultId: 0x0, Value (8 bit): 0x1 {5B 06 00 00 00 01}
0x5670A One Of Option: Enabled, Value (8 bit): 0x1 {09 07 95 00 00 00 01}
0x56711 One Of Option: Disabled, Value (8 bit): 0x0 {09 07 96 00 00 00 00}
0x56718 End One Of {29 02}
I then disabled Secure Boot, booted into modGrubShell.efi from a flash drive, and ran the following commands:
setup_var 0x11ad 0x0
setup_var 0x8e1 0x1
exit
Resizable BAR was not enabled upon reboot so I tried again using setup_var_3 but it still did not work. After reading around this forum some more I found some Dell users had also set “Legacy Option ROMs” to enabled before running setup_var. When I did this, I noticed that reading CSM Support offset 0x11ad prior to making any changes now returned “1” (Enabled) instead of “0” (Disabled), but frustratingly I still see messages that indicate my modifications have not taken effect: "[drm] Using a reduced BAR size of 256MiB. Consider enabling 'Resizable BAR' or similar, if available in the BIOS."
It seems like none of the variables I set persists upon reboot. If I make a change with setup_var, exit, then boot back into modGrubShell.efi, the values read from offsets 0x11ad and 0x8e1 have been reset to their original values. This is my first time messing around with UEFI variables and I may be missing something obvious here…any guidance would be greatly appreciated. Thanks!
For reference, here are the extracted BIOS files and UEFITool / Universal IFR Extractor output I am working with: 22.83 MB file on MEGA
Did you insert ReBar module?
What do you mean? I’m on kernel version 6.5.0-25-generic with the i915 driver:
sudo lspci -vvvs 04:00.0
04:00.0 VGA compatible controller: Intel Corporation Device 56a5 (rev 05) (prog-if 00 [VGA controller])
Subsystem: ASRock Incorporation Device 6006
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin ? routed to IRQ 135
Region 0: Memory at a2000000 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M]
Expansion ROM at a3000000 [disabled] [size=2M]
Capabilities: [40] Vendor Specific Information: Len=0c <?>
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+
10BitTagComp+ 10BitTagReq+ OBFF Not Supported, ExtFmt+ EETLPPrefix-
EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
FRS- TPHComp- ExtTPHComp-
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled,
AtomicOpsCtl: ReqEn-
LnkCap2: Supported Link Speeds: 2.5GT/s, Crosslink- Retimer- 2Retimers- DRS-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
Retimer- 2Retimers- CrosslinkRes: unsupported
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+
Address: 00000000fee003f8 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [420 v1] Physical Resizable BAR
BAR 2: current size: 256MB, supported: 256MB 512MB 1GB 2GB 4GB 8GB
Capabilities: [400 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Kernel driver in use: i915
Kernel modules: i915
First of all, THANKS A TON!
I’m going to need some time to understand what you did there exactly, still got a lot to learn.
Thanks you for your time and effort!! Appreciate your help .
1 Like
I mean the bios must support Resizable BAR in order to enable it. Is it in there?
There’s no option explicitly called “Resizable BAR” in my Universal IFR Extractor dump but I was under the impression that the presence of “Above 4GB MMIO BIOS assignment” means it is supported. I also compiled the latest Rust version of the IFR Extractor and it produced a description that the other did not: "Enable/Disable above 4GB MemoryMappedIO BIOS assignment This is enabled automatically when Aperture Size is set to 2048MB."
So you skipped the main step.