I used the following on the two Dell mobos: “setup_var 0x2 0x1” following the instructions from Xcuri0’s site. On my Gigabyte board, I used “setup_var 0x3 0x0”, rebooted, then “setup_var 0x3 0x1”. I was kinda’ surprised the “0x2” and “0x3” numbers seemed so “low,” but that’s what IFR told me to use.
I’m surprised to see the 9020 supported as coreboot has such a small number of boards listed as supported on its site. Of all the Dell mobos in the world, only the 7010/9010 show as officially supported. I’m going to look at those 9020 instructions as the only coreboot BIOS I have been able to install so far was the Dasharo one, and it’s not UEFI unless you build it.
Thanks, i’ll try that and report on it if it works (fingers crossed )
Edit:
the variables at offset 0x2 and 0x3 are not in the form of 0xX, but 0xXX. I don’t think really matters anyways, as unfortunately no combination seems to activate above 4G decode. Maybe the board simply does not have that option, despite having the ability?
Also for Coreboot, I was going off this code, but to be honest this is quite far from my area of expertise. Then again, resizable bar is not officially supported on sandy/ivy bridges, so i’m willing to take the chance even if it takes some tinkering…
Thanks for the massive help so far though!
Hello, sorry for the delay.
I see that everything happens to you the same as to me.
Yes, as she had said before… when connecting via igpu she could enable maximum rebar capability. I did quick tests, and I found no noticeable differences vs 1gb. So I recommend you use 1gb and don’t worry (I do the same, right now I even upgraded to a rtx 4080, everything still works OK).
NOTE: I was able to verify that in windows 10 everything appears enabled in gpuz, but in windows 11 it appears “above 4g off” (rebar also appears ON for me, like the rest of the options). It’s weird, but I imagine it’s something with the operating system. I went back to windows 10 and everything is perfect (currently using the same equipment as before, just upgraded to an rtx4080).
I have a Supermicro X11DPH-T mainboard, with an Intel Arc A770 LE 16GB graphics card, and this ‘works’; the only caveat is that I have to have my monitors off until I hear the windows sound, at which point I can turn them on and log in and everything works just fine with a setting of ‘32’. I get a 16GB BAR, and the driver reports Resizable BAR as enabled (even if GPU-Z says it’s not enabled (and shows the 16GB BAR; I don’t know what that’s about)). No stuttering, everything is smooth and awesome.
If I don’t have the monitors off, I get a magenta/green garbled screen, and the computer hangs for a while there before it reboots and repeats.
I did try the patches, plus a couple extra that @Kuri0 graciously provided, but none of them would apply. I think that means that they’re not needed? I did try to apply them to a different firmware for a different board I have, and one of them did apply, so I do think I did it correctly.
Yes, I noticed. Or atleast the version number is the same.
The motherboard firmware is… quirky. So if I boot up the computer with ‘silent boot’ enabled (ie show the boot logo), (and I knew this one already, since it also aplies to my vega 64), and no monitors are on, I get no picture after boot. So I’m used to this computer being a little odd.
But I discovered a new odd thing; If I boot with monitor off, I can turn it on after the computer has booted and log in to windows and rebar works. But; that’s with MMIO base at 56TB, and a chunk size of 256GB. I also tried a MMIO base of 1TB and chunk size of 16GB, and with those settings i can’t wake the monitor up. Tried several times. Back to 56TB/256GB, and it “works” again.
@Kuri0 Yeah, that makes sense. I’m going to try 1T/256GB and see what happens.
1T/256GB did work, but it acts the same. @68k-dude Yeah, I don’t know what I can do? Is there some part of the init code for… I don’t understand why the graphics card does not work, and hangs the machine, at boot with a 64bit BAR. Everything works as it should with a 512MB or 1GB BAR, but I think that’s because it then goes below 4GB. I could adjust the MMIO base from 2GB to 1.5GB, and use a 2GB BAR, I suspect, though I haven’t tried it yet. I don’t know if that’s enough for the A770? I’m also very curious as to what exactly fails, so that’s a good reason to investigate, I feel; I wouldn’t have this mb if I didn’t enjoy tinkering.
Oh, and the beep codes… I had to buy a speaker, since this mb doesn’t have one onboard. It always does a little birdsong at boot, but all my Supermicro boards have done that, so I haven’t tried to parse the (very fast!) beeps. If the monitor is off, though, it does 3? 4? additional “sad” beeps. I would have guessed it meant “graphics card failure” or “no console device” or something, but I can’t find this documented anywhere.
Hello @fiskvik ,
From my testing, anything less than 2GB BAR causes the intel driver to complain.
With a 2GB bar the driver is happy and most of the performance benefit is realised.
Intel recently fixed a bug where, if the driver wasn’t happy that Re-BAR was enabled, the system would freeze on startup. I had this a few times because the board would revert to CSM and Above 4GB decode would become disabled too.
@68k-dude Another day; another quirk. If I want to have a rebar of 2GB below 4GB, I’d have to adjust MMIO base down from 2GB, yes? When I do that, to 1.5GB or 1GB, and enable RebarDXE (any value), I have to disconnect power to the graphics card for the machine to post.
I’l having a few issues with this in the nearly there but not quite…
Spec:
intel I7 7700
Gigabyte H170m-DS3H
Intel Arc A750 GPU
Story so far -
I have managed to get the bios extracted - patched and rebar enabled large memory is enabled. so far so good.
but the graphics card does not use the large memory area as an allocation and only will allow 1GB to be used (where GPU-Z and intel Arc control both see it as enabled).
but and this is really annoying - the GPU ports cannot be used, if I use the internal graphics no problem and the machine boots fine, if the graphics card is used - I can boot and post, and get to windows, but often at this point of very shortly therafter (less than 10 seconds) the displays freeze and do not refresh / display what is going on. un plug from the gpu and switch to onboard and all is good again.
if I shift to a higher rebarstate then all I get is a code 12 error on the card saying it cannot allocate resources.
It may be worth noting that I do have the m.2 slot filled with the boot drive and another PCIE riser for a separate m.2 PCIE storage device .
I had to work on DSDT patching to get this this far but there seems to be some diferences in the way Qword assignment is by default with gigabyte seems odd.
Hi thanks for the quick response, i’ve tried different REBAR sizes and with 4GB and above all I get is a code 12 error on the GPU saying resources are not avaliable. Although as you see large memory is enabled the GPU has never been assigned memory in this block.
for 2GB I get purple screen errors.
I updated my patches.txt with your recently released file but all I get is “no patches can be applied to the file”
CSM is off and has been for a while (actually one of the longest parts of the process was re-enabling it to make sure I could flash the Gigabyte bios without the checking process)
I’m trying to enable Above 4G Decoding and rBAR for this oldie but goldie Z87 mainboard, so far no luck. Interestingly Above 4G Decoding string is exist and found via UEFITool but after extract the body via IRFExtractor Above 4G Decoding entry is missing.
)
