.EFI vs .FFS

[r8bit99]

I don't understand specifics of EFI / DXE drivers, but seems they are closly linked. Just thinking.....can the ReBarDxe be loaded with an EFI shell, kind of like this:

echo step1
connect -r
set -v efishellmode 1.1.2
map -u
echo step 2
load fs0:\EFI\Drivers\Nvm.efi
echo step2
map -u
echo step3
fs[YOUR-IDENTIFIED-NUMBER-HERE]:\EFI\boot\bootx64.efi

Found this online, where loading of NVME drivers was using this method. Thought this could be a possibility for OEM BIOSes where modifications was difficult?

[xCuri0]

@r8bit99 it won't work because ReBarDxe works by hooking PreprocessController which gets executed for every PCI device when the UEFI firmware initializes PCI devices.

This has been discussed before #6

There are still ways to get Resizable BAR without modifying BIOS, Using Linux with 4G decoding on or DSDT edit is the easiest.

[zoulztealer]

@r8bit99 it won't work because ReBarDxe works by hooking PreprocessController which gets executed for every PCI device when the UEFI firmware initializes PCI devices.

This has been discussed before #6

There are still ways to get Resizable BAR without modifying BIOS, Using Linux with 4G decoding on or DSDT edit is the easiest.

hello curio, im currently investigating a similar issue with the dxe driver module from nvstrabsrebar.

i was trying to find a way to side- / chainload the preconfigured NvStrapsReBar.ffs with a grub 2 / linux based live usb prior to windows 10 to have the gpu driver inside win 10 access to the driver module and enable full or partial rebar (anything higher than the default resized bar of 214/256mb).

ive created a question about the possibility on stackoverflow:

https://stackoverflow.com/questions/78533307/possibility-to-side-chainload-ffs-dxe-uefi-bios-rebar-driver-module-with

to me it seems theoretically possible but i have no clue about any of this stuff.

you said there would be an issue to trigger pci enumeration.

would it be possible to load the dxe driver as runtime persistently and then have the machine rebooted with the driver loaded and injected into pci enumeration? or would it be possible to run pci enum seperately beforehand and mold that over into a preconfigured NvStrapsReBar.ffs?

8.8 DXE Runtime Driver

A DXE runtime driver executes in both boot services and runtime services environments. This means the services that these modules produce are available before and after ExitBootServices() is called, including the time that an operating system is running. If SetVirtualAddressMap() is called, then modules of this type are relocated according to virtual address map provided by the operating system.

please also have a look at my issue here and the points ive made:

terminatorul#34

since (re)bar is a pcie 2.0, pcie 2.1 feature im not sure if it really needs an extra driver or if everything could already be handled already natively by default from the chipset? this is due to the fact that rebar seems to always on and always present with any d3d capable gpu: bar is active and has been resized (rebar is active). see the screenshots in my issue thread and excerpts from the pcie spec pdf.

some of these native (re)bar functions could already be included in the uefi specs:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

This means that the PCI BARs (Base Address Registers) and the configuration of any PCI to PCI bridge controllers must
not be modified by a PCI Device Driver. A PCI Bus Driver will leave a PCI Device in a disabled safe initial
state. A PCI Device Driver should save the original Attributes() state. It is a PCI Device Driver's
responsibility to call Attributes() to enable the I/O, Memory, and Bus Master decodes if they are not
already enabled by the PCI bus driver.

14.4 EFI PCI I/O Protocol

The interfaces provided in the EFI_PCI_IO_PROTOCOL are for performing basic operations to memory,
I/O, and PCI configuration space. The system provides abstracted access to basic system resources to
allow a driver to have a programmatic method to access these basic system resources. The main goal of
this protocol is to provide an abstraction that simplifies the writing of device drivers for PCI devices. This
goal is accomplished by providing the following features:
• A driver model that does not require the driver to search the PCI busses for devices to manage.
Instead, drivers are provided the location of the device to manage or have the capability to be
notified when a PCI controller is discovered.
• A device driver model that abstracts the I/O addresses, Memory addresses, and PCI
Configuration addresses from the PCI device driver. Instead, BAR (Base Address Register)
relative addressing is used for I/O and Memory accesses, and device relative addressing is used
for PCI Configuration accesses. The BAR relative addressing is specified in the PCI I/O services
as a BAR index. A PCI controller may contain a combination of 32-bit and 64-bit BARs. The BAR
index represents the logical BAR number in the standard PCI configuration header starting from the first BAR.
The BAR index does not represent an offset into the standard PCI Configuration Header because those offsets will vary depending on the combination and order of 32-bit and 64-bit BARs.

Mem.Read Allows BAR relative reads to PCI memory space. See the
Mem.Read() function description.
Mem.Write Allows BAR relative writes to PCI memory space. See the
Mem.Write() function description.
Io.Read Allows BAR relative reads to PCI I/O space. See the Io.Read()
function description.
Io.Write Allows BAR relative write

EFI_PCI_IO_PASS_THROUGH_BAR

BarIndex The BAR index of the standard PCI Configuration header to use as
the base address for the memory operation to perform. This allows
all drivers to use BAR relative addressing. The legal range for this
field is 0..5. However, the value EFI_PCI_IO_PASS_THROUGH_BAR
can be used to bypass the BAR relative addressing and pass Offset to
the PCI Root Bridge I/O Protocol unchanged. Type
EFI_PCI_IO_PASS_THROUGH_BAR is defined in Section 14.4.

[xCuri0]

i don't think it's possible for uefi to do pci re-enumeration.

it is very much technically possible to resize BARs after PCI initialization though. linux does it, the first commit of this project did it, xelafics first version of nvstrapsrebar also did it. however it's kinda complicated to write an efi application which can do all this without any hardcoding

[zoulztealer]

i don't think it's possible for uefi to do pci re-enumeration.

it is very much technically possible to resize BARs after PCI initialization though. linux does it, the first commit of this project did it, xelafics first version of nvstrapsrebar also did it. however it's kinda complicated to write an efi application which can do all this without any hardcoding

thanks for your quick answering. thats very interesting. according to my theory resizing the bar(s) could be everything that needs to be done because all the rest of the mechanisms seem to be in place working already by default natively (bar always present, always on with d3d9+ capable gpu, bar is active and has been resized, but size is statically limited to 214mb vulkan, 256mb hw, yet full rebar across the whole gpu vram is always available in d3d according to capframex but its unclear as to why this is).

if someone wanted to only change the bar size could that be done from grub2, uefi shell or similar?

do you have any idea why capframex is reporting full rebar in d3d for gtx1080 and 2080ti (as well as probably any other d3d gpu) even when rebar is "physically disabled" (which it never is imo and is just a marketing scam)?

why are there different sizes reported for hw and vulkan? doesnt this mean its possible to achieve different rebar sizes with different graphic apis? like vulkan could probably support full memory as well like d3d. what would be the difference between d3d and vulkan in regards to this and why is this being done by the industry?

ive tried to investigate this with the capframex support but i received no answer.

could it be that d3d somehow can do a full software rebar via the a4g setting? and is this the reason why the performance gain for nvidia cards may be relatively low in the 1-3% range (because full rebar is done anyway in d3d)?

another idea would be to merely trick windows 10 into believing rebar is "on" by only setting the environment / uefi variables that the machine receives in the case of actually fully configured rebar:

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setfirmwareenvironmentvariablea

if the right environment variables - or whatever is needed and passed on to the os / gpu - are detected by the os / gpu maybe its already enough to have rebar going on natively.

[xCuri0]

even when rebar is "physically disabled" (which it never is imo and is just a marketing scam)?

2080ti and all turing 16/20 series cards can do rebar using nvstrapsrebar
1080ti also could but nvidias driver does not support it

do you have any idea why capframex is reporting full rebar in d3d for gtx1080 and 2080ti (as well as probably any other d3d gpu) even when rebar is "physically disabled" (which it never is imo and is just a marketing scam)?

probably just an error

why are there different sizes reported for hw and vulkan? doesnt this mean its possible to achieve different rebar sizes with different graphic apis? like vulkan could probably support full memory as well like d3d. what would be the difference between d3d and vulkan in regards to this and why is this being done by the industry?

on stuff like amd polaris (my gpu) the driver disables rebar by default because it's experimental and needs a registry edit to enable it.

another idea would be to merely trick windows 10 into believing rebar is "on" by only setting the environment / uefi variables that the machine receives in the case of actually fully configured rebar:

no such thing

[zoulztealer]

Rakesh P N: Hi, my name is Rakesh P N. How may I help you?
. .: hello
Rakesh P N: hello!
. .: i have a question regarding rebar availability for rtx 2000 and gtx 1600 series
Rakesh P N: Rebar?
Rakesh P N: May I know what it is?
. .: https://www.nvidia.com/en-us/geforce/news/geforce-rtx-30-series-resizable-bar-support/
Rakesh P N: Oh, resizable bar!
. .: yes exactly
Rakesh P N: GTX series doesn't have resizable bar
Rakesh P N: RTX 2000 is it a quadro card?
. .: generally rtx 2000 series
. .: more exactly rtx2080ti in this case
Rakesh P N: Then its supported
. .: so on this screenshot rebar is officially supported by nvidia
. .: https://i.redd.it/favc5wjhhxw91.jpg
. .: bar and rebar were introduced with the pcie 2.0 and updated with pcie 2.1 specifications
Rakesh P N: Its not supported on your PC?
. .: yes the issue its not supported but it should be
Rakesh P N: May I know the name of card manufacturer of your RTX 2080ti?
. .: yes its zotac amp rtx2080ti
File attachment upload has started.
The file gpuz4.gif (24.26KB) was received.
File attachment upload has started.
The file gpuz4rebar.gif (14.16KB) was received.
Rakesh P N: The motherboard you're using is?
. .: gigabyte x570 ud rev. 1.0
. .: the thing is rebar is always on but the user is prohibited from changing the bar size
Rakesh P N: I suggest you contact Zotac and check with them for the Resizable bar update.
https://www.zotac.com/news/get-resizable-bar
. .: basically every d3d9+ capable gpu can do partial or full rebar
. .: in capframex full rebar is reported for gtx1080 and rtx2080ti even when rebar is disabled
File attachment upload has started.
The file capframex.png (248.91KB) was received.
Rakesh P N: Sorry, not sure about Capramex
Rakesh P N: You need to check with ZOtac once
. .: ok i will try thanks
. .: can you confirm that nvidia officially supports full rebar for rtx2080ti?
Rakesh P N: Yes it doesn
Rakesh P N: But
Rakesh P N: Its not the chipset
Rakesh P N: Its the card
Rakesh P N: Zotac needs to support
. .: ok very interesting thank you

a few hours later ...

This is not available. Only updates done were for the 30 series cards and none for 20 series unfortunately.

Cheers,

ZOTAC Technical Support

Department: Technical Support
Type: Issue
Status: Closed

END OF STORY