Opened 9 years ago

Closed 9 years ago

#6105 closed enhancement (fixed)

[PATCH] OpenFirmware frame buffer support

Reported by: andreasf Owned by: axeld
Priority: normal Milestone: R1
Component: System/Boot Loader Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #1048
Has a Patch: yes Platform: PowerPC

Description

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

Attachments (11)

0001-Initial-OpenFirmware-frame-buffer-support.patch (9.6 KB ) - added by andreasf 9 years ago.
draft patch
0001-Remove-unnecessary-includes-unavailable-for-OpenFirm.patch (1.6 KB ) - added by andreasf 9 years ago.
proposed patch: generic video cleanup
0002-Remove-unnecessary-include.patch (771 bytes ) - added by andreasf 9 years ago.
optional patch: generic video cleanup
0003-OpenFirmware-Prepare-frame-buffer-support.patch (2.0 KB ) - added by andreasf 9 years ago.
proposed patch: prepare frame buffer support
0004-OpenFirmware-Add-frame-buffer-support.patch (7.2 KB ) - added by andreasf 9 years ago.
draft patch: implement frame buffer support
0005-Fix-line-endings.patch (10.7 KB ) - added by andreasf 9 years ago.
proposed patch: fix line endings
0006-Disable-fake-serial-output-for-frame-buffer.patch (1.2 KB ) - added by andreasf 9 years ago.
proposed patch: suppress fake serial output for frame buffer
of_disable_framebuffer.diff (379 bytes ) - added by andreasf 9 years ago.
how to: disable frame buffer once applied
0007-Retrieve-EDID-info.patch (2.2 KB ) - added by andreasf 9 years ago.
draft patch: read EDID
0004-OpenFirmware-Add-frame-buffer-support.2.patch (4.4 KB ) - added by andreasf 9 years ago.
proposed patch: add frame buffer support
0007-Retrieve-EDID-info.2.patch (2.2 KB ) - added by andreasf 9 years ago.
draft patch: read EDID

Download all attachments as: .zip

Change History (28)

by andreasf, 9 years ago

draft patch

comment:1 by andreasf, 9 years ago

Has a Patch: set

comment:3 by axeld, 9 years ago

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.

comment:4 by andreasf, 9 years ago

Has a Patch: unset

by andreasf, 9 years ago

proposed patch: generic video cleanup

comment:5 by andreasf, 9 years ago

Has a Patch: set

by andreasf, 9 years ago

optional patch: generic video cleanup

by andreasf, 9 years ago

proposed patch: prepare frame buffer support

by andreasf, 9 years ago

draft patch: implement frame buffer support

in reply to:  3 ; comment:7 by andreasf, 9 years ago

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.

by andreasf, 9 years ago

Attachment: 0005-Fix-line-endings.patch added

proposed patch: fix line endings

by andreasf, 9 years ago

proposed patch: suppress fake serial output for frame buffer

in reply to:  7 comment:8 by andreasf, 9 years ago

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.

by andreasf, 9 years ago

Attachment: of_disable_framebuffer.diff added

how to: disable frame buffer once applied

by andreasf, 9 years ago

draft patch: read EDID

comment:9 by andreasf, 9 years ago

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 > 

by andreasf, 9 years ago

proposed patch: add frame buffer support

by andreasf, 9 years ago

draft patch: read EDID

in reply to:  3 comment:10 by andreasf, 9 years ago

Summary: [RFC] OpenFirmware frame buffer support[PATCH] OpenFirmware frame buffer support

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).

comment:11 by axeld, 9 years ago

Applied patch 0001 & 0002 in hrev37007, thanks!

comment:12 by axeld, 9 years ago

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).

comment:13 by phoudoin, 9 years ago

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.

in reply to:  12 comment:14 by andreasf, 9 years ago

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.

in reply to:  13 comment:15 by andreasf, 9 years ago

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.

comment:16 by andreasf, 9 years ago

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.

comment:17 by andreasf, 9 years ago

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. ;)

comment:18 by andreasf, 9 years ago

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

comment:19 by andreasf, 9 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.