Hi Ard,
To support UEFI GOP frame buffer, is it enough to provide UEFI GOP protocol and valid FrameBufferBase and FrameBufferSize via GOP mode?
I still have some question. As we are using a PCIe VGA device, the frame buffer might probably be certain PCIe memory resource BAR of VGA device. Then is it possible for OS to re-enumerate PCIe bus and re-allocate memory BAR resources? If so, who will be responsible to update frame buffer base?
Thanks and regards,
Heyi Guo (Gary)
On 15 March 2017 at 02:51, Heyi Guo heyi.guo@linaro.org wrote:
Hi Ard,
To support UEFI GOP frame buffer, is it enough to provide UEFI GOP protocol and valid FrameBufferBase and FrameBufferSize via GOP mode?
You need to expose the pixel mode and color depth etc, as well, and you can use the existing framebufferbltlib to implement blitting in software if you don't want to wire up the hardware support.
I still have some question. As we are using a PCIe VGA device, the frame buffer might probably be certain PCIe memory resource BAR of VGA device. Then is it possible for OS to re-enumerate PCIe bus and re-allocate memory BAR resources? If so, who will be responsible to update frame buffer base?
That is a good question, and an unsolved problem. I know Lorenzo is aware of this, and there has been discussion in the past about preserving the PCI configuration performed by the firmware when booting in ACPI mode.
In any case, the EFI GOP driver in the kernel should probably double check that the [base, size) exposed by the GOP protocol is covered entirely by a single PCI bar if the protocol was exposed by a PCI device to begin with. I could add some code to the stub for that.
Sorry for the delay in replying.
On Wed, Mar 15, 2017 at 11:18:00AM +0000, Ard Biesheuvel wrote:
On 15 March 2017 at 02:51, Heyi Guo heyi.guo@linaro.org wrote:
Hi Ard,
To support UEFI GOP frame buffer, is it enough to provide UEFI GOP protocol and valid FrameBufferBase and FrameBufferSize via GOP mode?
You need to expose the pixel mode and color depth etc, as well, and you can use the existing framebufferbltlib to implement blitting in software if you don't want to wire up the hardware support.
I still have some question. As we are using a PCIe VGA device, the frame buffer might probably be certain PCIe memory resource BAR of VGA device. Then is it possible for OS to re-enumerate PCIe bus and re-allocate memory BAR resources? If so, who will be responsible to update frame buffer base?
That is a good question, and an unsolved problem. I know Lorenzo is aware of this, and there has been discussion in the past about preserving the PCI configuration performed by the firmware when booting in ACPI mode.
Yes, it is still an unsolved problem. At the moment in the ARM64 Linux kernel the ACPI PCI core code reassign all resources which means that the BAR mapping the frame buffer can be moved behind firmware's back.
The kernel can be taught not to move certain resources, the question is how to do that at FW->OS handover. We could eg declare all resources (ie BAR values) for a given PCI vendor/device ID "fixed" (think about them as immutable) through a PCI quirk but I am not sure it would cover what you really need here (and it would be Linux specific).
In x86 world I suspect it is sorted out through arch/ platform quirks (and an insane amount of kernel command line parameters) but I am not willing to go that way for ARM64, it would become impossible to handle.
Lorenzo
In any case, the EFI GOP driver in the kernel should probably double check that the [base, size) exposed by the GOP protocol is covered entirely by a single PCI bar if the protocol was exposed by a PCI device to begin with. I could add some code to the stub for that.
On 20 March 2017 at 15:11, Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
Sorry for the delay in replying.
On Wed, Mar 15, 2017 at 11:18:00AM +0000, Ard Biesheuvel wrote:
On 15 March 2017 at 02:51, Heyi Guo heyi.guo@linaro.org wrote:
Hi Ard,
To support UEFI GOP frame buffer, is it enough to provide UEFI GOP protocol and valid FrameBufferBase and FrameBufferSize via GOP mode?
You need to expose the pixel mode and color depth etc, as well, and you can use the existing framebufferbltlib to implement blitting in software if you don't want to wire up the hardware support.
I still have some question. As we are using a PCIe VGA device, the frame buffer might probably be certain PCIe memory resource BAR of VGA device. Then is it possible for OS to re-enumerate PCIe bus and re-allocate memory BAR resources? If so, who will be responsible to update frame buffer base?
That is a good question, and an unsolved problem. I know Lorenzo is aware of this, and there has been discussion in the past about preserving the PCI configuration performed by the firmware when booting in ACPI mode.
Yes, it is still an unsolved problem. At the moment in the ARM64 Linux kernel the ACPI PCI core code reassign all resources which means that the BAR mapping the frame buffer can be moved behind firmware's back.
The kernel can be taught not to move certain resources, the question is how to do that at FW->OS handover. We could eg declare all resources (ie BAR values) for a given PCI vendor/device ID "fixed" (think about them as immutable) through a PCI quirk but I am not sure it would cover what you really need here (and it would be Linux specific).
In x86 world I suspect it is sorted out through arch/ platform quirks (and an insane amount of kernel command line parameters) but I am not willing to go that way for ARM64, it would become impossible to handle.
Well, the EFI framebuffer driver only attaches to a single framebuffer, and so we could introduce a quirk that marks the BAR that covers that address as fixed, regardless of which vendor or device exposes it.
I will take a look at the code to see if this is feasible ...
-
Ard Biesheuvel -
Heyi Guo -
Lorenzo Pieralisi