-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add ResizeUsePciRbIo to workaround broken PciIo on some UEFI firmwares #418
Conversation
For use on UEFI firmwares with buggy PciIo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I only have general remarks, because PCIe is not my strong suit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good to me. Added a few comments to @mhaeuser's.
Applied the requested changes and confirmed it works (atleast for my hardware configuration). Do I need to squash the commits before they can be merged ? And maybe build documentation too |
We can squash the commits at merge time, thankfully GH has a button for this. Looks good on my side, @mhaeuser could you merge? |
Requested changes all done, lmk if I missed something. I also compiled with |
Any updates on this ? |
We have CI issues at the moment (GH Actions fail to start all over the org), and need to wait till GitHub support fixes it for us. We will merge this soon ^__^ |
Squashed and merged in d928b90 -- thank you |
I found another bug relating to this,
I traced it to this line https://github.com/acidanthera/OpenCorePkg/blob/master/Staging/AudioDxe/HdaController/HdaController.c#L300 My I could just make it possible for AudioDxe to use PciRootBridgeIo too but it does seem like Is there a better way we can implement a workaround for this ? Maybe a universal option for using PciRootBridgeIo ? |
I think we could replace Or could even replace PciIo completely with our own that uses PciRootBridgeIo if requested ? These are the 2 bugs I'm aware of in these Aptio 4 firmware PciIo. There's probably more which I could do additional testing for. |
I've decided to go with replacing the faulty Mem.Read/Write functions with custom ones. Will provide an update Probably will leave the IO functions as is for now |
Yeah, that makes good sense to me. Please provide a PR on that ^_^ |
@vit9696 Finally managed to get it working (haven't implemented write yet)
It turns out both PciRootBridgeIo and CpuIo2 have the invalid MMIO limitation. Using IoLib MMIO got it working So CpuIo2, PciRootBridgeIo and PciIo all need overrides which I'll submit in a PR. PciIo additionally needs fix for IO space 256 byte limit worked around in this PR |
I created this patch because I would get
Capability I/O Error
when using ResizeGpuBars or ResizeAppleGpuBars. It turns out my system had a buggy PciIo implementation that would not allow access to the PCIe extended configuration space (above 256 bytes). So I created this patch to add an option to use PciRootBridgeIo instead which works without any issues on my system. OpenCore has no issues resizing my RX 580's BAR from 8GB to 256MB and booting macOS after this patch.Before
After (using patch with ResizeUsePciRbIo enabled)
Newer UEFI firmwares supporting Resizable BAR officially likely don't need this workaround. My motherboard is a Gigabyte B75M-D3H running BIOS F16 (December 2018) with ReBarUEFI module/patches I developed.
There is one issue which is Windows giving Code 43 on the GPU when using ResizeGpuBars however Linux works without any issues even when using
pci=nocrs
to stop the AMDGPU driver from resizing BAR to 8GB. ResizeUsePciRbIo should be tested on other systems where PciIo ResizeGpuBars works in Windows to see if using PciRootBridgeIo is causing that (IMO it's not, it's probably PCI Bridge or something related?).