On 10.03.16 17:23, Ard Biesheuvel wrote:

(+ Laszlo)

On 10 March 2016 at 23:12, Mark Langsdorf [off-list ref] wrote:

quoted

On 03/09/2016 11:40 PM, Ard Biesheuvel wrote:

quoted

This series adds support to ARM and arm64 for using the kernel's EFI
framebuffer driver to drive EFI Graphics Output Protocol (GOP) based
framebuffers.

This involves refactoring some of the existing x86 code so it can be
reused
by ARM and arm64, and wiring it up both in the UEFI stub and in the core
kernel into the existing UEFI infrastructure for ARM and arm64.

Given that I have access to a variety of different ARM64 UEFI
implementations, how would I go about testing this code? Do I
need a specific UEFI implementation and are there any special
command line arguments I should pass to the kernel?

I have tested this myself on QEMU and FVP Base, which are both
software models. On bare metal, it would involve a system with a
graphics card that the firmware knows how to drive, and I am honestly
not sure if any such combinations currently exist, other than the ARM
development platforms such as Juno which have an embedded-style (i.e.,
non-PCI) graphics controller that the firmware knows how to drive out
of the box.

The code itself is smart enough to figure which (if any) of the
available handles carrying the GOP protocol is the one that is
attached to ConOut, and so there is nothing required to enable this
other than building it into the kernel and running it on a system with
a firmware supported screen attached.

How does this deal with caches? Does the GOP driver access the frame
buffer as cached or as uncached memory? I suppose it's always uncached?

I'm mostly curious because I'd like to implement support for GOP in
U-Boot soon.


Alex