[PATCH] OpenFirmware frame buffer support

[andreasf]

The following patch adds initial frame buffer support, i.e. graphics, for ppc.

Depths 8 and 32 were tested to work; 15, 16 and 24 were broken (colors wrong and/or squashed to left). Tested with an ATI Radeon 9200 Mac Edition, both for VGA and DVI.

To find a suitable mode value for your monitor, run from the OpenFirmware prompt:

dev screen
show-modes

[andreasf]

draft patch

[axeld]

The exciting parts (memory management, and mode selection) look very much like a hack at this point, but the rest seems to be pretty well.

IMO, the stuff that touches the generic stuff looks like it deserves a separate patch that could be applied now.

[andreasf]

proposed patch: generic video cleanup

[andreasf]

optional patch: generic video cleanup

[andreasf]

proposed patch: prepare frame buffer support

[andreasf]

draft patch: implement frame buffer support

[andreasf]

Patches 1-3 do the preparatory work and could be applied right away.

Patch 4 is an updated RFC: Setting mode and depth has been removed, they are not strictly needed since OpenFirmware initializes the screen. My old VGA-connected screen has some EDID issue, so that OpenFirmware uses odd-looking 832x624 resolution; on my other DVI-connected screen the native resolution 1280x1024 is used. In both cases the depth is 8 bit by default.

The "serial debug" kernel output leads to half-transparent text output in 8-bpp mode and to a grayish distortion in 32-bpp mode. Still have to find a condition to suppress the output.

[andreasf]

proposed patch: fix line endings

[andreasf]

proposed patch: suppress fake serial output for frame buffer

[andreasf]

Still have to find a condition to suppress the output.

Patches 5-6 do this. Patch 5 is a pure line ending conversion, feel free to run a tool yourself instead. Patch 6 depends on patch 3 (frame_buffer.enabled) but not on patch 4.

[andreasf]

how to: disable frame buffer once applied

[andreasf]

draft patch: read EDID

[andreasf]

I've added an RFC for reading the EDID. Unfortunately I could only guess how the EDID info relates to the numeric modes needed for set-mode - for my Radeon 9200 the established timings for VGA, followed by the established timings for DVI (labelled "LCD"), then a few more (but odd number). There's a mode# to retrieve the current mode though, and said show-modes to print the modes on-screen.

0 > show-modes
0 = 800 x 600 @ 60 Hz
1 = 800 x 600 @ 56 Hz
2 = 640 x 480 @ 75 Hz
3 = 640 x 480 @ 72 Hz
4 = 640 x 480 @ 67 Hz
5 = 640 x 480 @ 60 Hz
6 = 8 x 1 @ 0 Hz - Not Available
7 = 8 x 1 @ 0 Hz - Not Available
8 = 1280 x 1024 @ 75 Hz - Disabled
9 = 1024 x 768 @ 75 Hz
a = 1024 x 768 @ 70 Hz
b = 1024 x 768 @ 60 Hz
c = 1024 x 768 @ 43 Hz - Disabled
d = 832 x 624 @ 75 Hz
e = 800 x 600 @ 75 Hz
f = 800 x 600 @ 72 Hz
10 = 1152 x 870 @ 75 Hz - Disabled
11 = 800 x 600 @ 60 Hz - LCD - Not Available
12 = 800 x 600 @ 56 Hz - LCD - Not Available
13 = 640 x 480 @ 75 Hz - LCD - Not Available
14 = 640 x 480 @ 72 Hz - LCD - Not Available
15 = 640 x 480 @ 67 Hz - LCD - Not Available
16 = 640 x 480 @ 60 Hz - LCD - Not Available
17 = 8 x 1 @ 0 Hz - LCD - Not Available
18 = 8 x 1 @ 0 Hz - LCD - Not Available
19 = 1280 x 1024 @ 75 Hz - LCD - Not Available
1a = 1024 x 768 @ 75 Hz - LCD - Not Available
1b = 1024 x 768 @ 70 Hz - LCD - Not Available
1c = 1024 x 768 @ 60 Hz - LCD - Not Available
1d = 1024 x 768 @ 43 Hz - LCD - Not Available
1e = 832 x 624 @ 75 Hz - LCD - Not Available
1f = 800 x 600 @ 75 Hz - LCD - Not Available
20 = 800 x 600 @ 72 Hz - LCD - Not Available
21 = 1152 x 870 @ 75 Hz - LCD - Not Available
22 = 1024 x 768 @ 75 Hz
23 = 1280 x 1024 @ 60 Hz - Disabled
24 = 832 x 624 @ 75 Hz  * CURRENT
 ok
0 > 

[andreasf]

proposed patch: add frame buffer support

[andreasf]

draft patch: read EDID

[andreasf]

I've been able to simplify the main patch and promote it to proposed status: The frame buffer is already identity-mapped (0x90000000, length 268435456; address 98008000), so no need to map it again. Remapping it at the next find_free_virtual_range address (0x8022b000) results in a DEFAULT CATCH.

Opening the screen device reinitializes the display, so we should postpone that as far as possible.

Patch 7 is updated to reflect the latter. It could be applied as well but has no real function currently (just passes the EDID into the kernel like x86).

[axeld]

Applied patch 0001 & 0002 in hrev37007, thanks!

[axeld]

Have you tested what happens with Qemu PPC? Would be interesting how Mac specific those things are (not that this would be a problem for now).

[phoudoin]

Pardon my ignorance, but does OpenFirmware works in 32 bits only on Macs?

If 64bits is possible, shouldn't arch_mmu_map_physical_memory() use phys_addr_t argument type in openfirmware/arch/ppc/mmu.cpp and openfirmware/platform_arch.h?

AFAIK, for a EFI boot platform future support, both 32 and 64bits would have to be supported, as both can be found on Macs.

[andreasf]

Replying to axeld:

Have you tested what happens with Qemu PPC? Would be interesting how Mac specific those things are

Cf. #6071

First of all, QEMU emulates two types of PowerPC Macs, Old World (g3beige) and New World (mac99). Emulation, as far as working, is mostly Mac-specific. ​PReP emulation is currently broken because dependent on former OpenHackWare and because the Linux kernel dropped PReP support. The Bamboo board is used for KVM but not for emulation; the emulated boards do not use OpenBIOS, so likely need something like U-Boot and would thus be irrelevant to OpenFirmware. There was a GSoC proposal for ​BeBox emulation but no applicants apparently and unrelated to OpenFirmware, too. Having said that...

The addresses can and will vary depending on machine, memory and possibly other factors. We cannot apply my workarounds to trunk.
On QEMU g3beige and mac99, the frame buffer is at 0x80000000 and OpenBIOS is at the top of RAM, e.g. 0x07f00000. The set-mode, set-depth words and the EDID property appear not to be available. The default depth is 15. The VGA BIOS is known to have endianness issues. When started with -nographic, screen resolves to the serial device instead.

[andreasf]

Replying to phoudoin:

does OpenFirmware works in 32 bits only on Macs?

Haiku/ppc64 is completely broken, cf. #5164.

If 64bits is possible, shouldn't arch_mmu_map_physical_memory() use phys_addr_t argument type in openfirmware/arch/ppc/mmu.cpp and openfirmware/platform_arch.h?

phys_addr_t exists since hrev36926 11 days ago, whereas most of the ppc code is copyrighted around 2005...

The frame buffer address was said to be explicitly 32-bit though, at least for sparc64.

[andreasf]

My old ATI Rage 128 has the same properties and words as my Radeon 9200 plus some more. Default depth is 8, default mode is 640x480. Tested to work.

When connected to a different PCI(-X) slot in my PowerMac, either device is shown underneath the PCI bridge, does not get the address property and is not used as output device by OpenFirmware.

Alex' PowerBook's ATI chipset has the words except set-depth and the properties except EDID. Its default depth is 8 too, and the default mode is 1024x768.

[andreasf]

I've filed patch #6140 to be able to disable the frame buffer. For serious bug hunting it's more convenient to hardcode the corresponding option though. ;)

[andreasf]

Applied a new line ending conversion in hrev37265, obsoleting patch 0005.

[andreasf]

Applied slightly modified patches in hrev38299, hrev38300, hrev38301, hrev38305, hrev38306 and hrev38307.