Page MenuHomeFreeBSD

Add a delayed VT attachment for ofwfb
Needs ReviewPublic

Authored by jhibbits on Jun 15 2018, 3:57 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Feb 2, 2:29 AM
Unknown Object (File)
Sat, Jan 24, 6:14 AM
Unknown Object (File)
Thu, Jan 22, 8:32 PM
Unknown Object (File)
Jan 4 2026, 8:28 PM
Unknown Object (File)
Dec 29 2025, 9:55 AM
Unknown Object (File)
Dec 14 2025, 9:17 PM
Unknown Object (File)
Nov 24 2025, 11:44 PM
Unknown Object (File)
Nov 23 2025, 12:32 AM

Details

Reviewers
nwhitehorn
Summary

In some cases, /chosen/stdout is not the VGA console. In this case there may still be a viable console. This adds a device node under vgapci* if it's a viable OFW device tree node.

Test Plan

Still need to test that I didn't break direct attachment.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17316
Build 17151: arc lint + arc unit

Event Timeline

sys/dev/vt/hw/ofwfb/ofwfb.c
90

No way for these to be the same driver?

522

It seems a bit weird to have a newbus device appear only if it's *not* the console.

525

How does this interact with drm consoles? I guess the probe bits compete later on? How about module loading of drm consoles?

551

"Open Firmware" usually has a space in it.

jhibbits added inline comments.
sys/dev/vt/hw/ofwfb/ofwfb.c
90

I think they could be the same. I mentioned this on IRC just a few minutes ago. If I move the /chosen handling code into the ofwfb_probe function instead, that might suffice, so that it's not looking for /chosen properties in the ofwfb_init().

522

If it's not the system console, but has all the makings of a video console.

525

Not sure. I don't have anything that can really use drm console right now. Maybe 'fb' device name is wrong for this.

551

Oops. I'll blame my chrome keyboard's tendency to forget I hit space.

jhibbits marked an inline comment as done.

Reduce the diff, by sharing the same VT driver between the early attach and delayed attach. This required moving some config setting into the probe routine, but that should be fine.

sys/dev/vt/hw/ofwfb/ofwfb.c
116

Is this tested on Apple hardware?

522

So? Don't you always want a newbus device, even if it is the console (like uart)?

What is needed to get this in tree? Testing on Apple hardware was mentioned. What should be tested?

@tuexen this needs revisited to clean up a bit. As @nwhitehorn mentioned, it looks a little strange in how it attaches, so I need to rethink it. Right now the patch exists to help those who have a Talos or Blackbird and want to boot from serial, but output to the onboard VGA/HDMI.

sys/dev/vt/hw/ofwfb/ofwfb.c
522

Newbus should always have a node if the hardware is there... console or not is something else and should have no influence on this choice.

@jhibbits Thanks for the explanation. I'm using it on a blackbird. I have also a G5 Powermac in my lab, so if there is a need for testing, just let me know. I would like to run an unmodified version of FreeBSD just to make sure I don't commit anything by accident...

Justin, I tested this patch on Blackbird and it looks good, just need to be rebased to latest main. Also tested it along with D30626.

I didn't check how does it interact with loader.conf(5) "console" parameter: should it suppress the attachment if user explicitly sets console=comconsole? ; Should it attach only if user explicitly sets console="comconsole,vidconsole" or console="vidconsole" and the /chosen device is the serial?

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

In D15818#1253535, @fuz wrote:

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

Since we don't provide Open Firmware interfaces on PowerNV systems, that makes some sense. What we do provide (at least for certain video controllers) is a linear framebuffer available at the address listed in the device tree.

In D15818#1253535, @fuz wrote:

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

Since we don't provide Open Firmware interfaces on PowerNV systems, that makes some sense. What we do provide (at least for certain video controllers) is a linear framebuffer available at the address listed in the device tree.

So, @jhibbits mentioned that getting the framebuffer used to work at some point in time, as long as you selected the boot device from Petitboot via keyboard and screen. But it doesn't anymore and it's unclear why. Also, none of the tutorials show how to set up any Raptor machine as a desktop, so this is somewhat confusing.

In D15818#1253535, @fuz wrote:

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

Since we don't provide Open Firmware interfaces on PowerNV systems, that makes some sense. What we do provide (at least for certain video controllers) is a linear framebuffer available at the address listed in the device tree.

ofwfb isn't Open Firmware-specific, it just depends on the device tree providing the necessary properties, but those properties appear to no longer be provided, and even when launched from the local VGA interface, the "linux,stdout-path" still points to the serial console.

In D15818#1253535, @fuz wrote:

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

Since we don't provide Open Firmware interfaces on PowerNV systems, that makes some sense. What we do provide (at least for certain video controllers) is a linear framebuffer available at the address listed in the device tree.

ofwfb isn't Open Firmware-specific, it just depends on the device tree providing the necessary properties, but those properties appear to no longer be provided, and even when launched from the local VGA interface, the "linux,stdout-path" still points to the serial console.

OK, I'm obviously not familiar with the ofwfb driver, thank you for the information!

Do you happen to know which properties are required / which properties disappeared? I'm wondering if since the PowerNV support wasn't used in Linux, if it got dropped at some point in the firmware. If so, Raptor will likely want to update the firmware to fix that...

ofwfb needs the following properties to work correctly:

  • height
  • width
  • depth
  • device_type of 'display'

Without the height, width, and depth, the driver has no way to determine the dimensions of the frame buffer. Another option we could use is adding a mode hint to this, like I did with the DIU driver, where the hint would be specified in the form of: hint.vgapci.0.mode="1280x1024@60"

In D15818#1253535, @fuz wrote:

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

Since we don't provide Open Firmware interfaces on PowerNV systems, that makes some sense. What we do provide (at least for certain video controllers) is a linear framebuffer available at the address listed in the device tree.

ofwfb isn't Open Firmware-specific, it just depends on the device tree providing the necessary properties, but those properties appear to no longer be provided, and even when launched from the local VGA interface, the "linux,stdout-path" still points to the serial console.

OK, I'm obviously not familiar with the ofwfb driver, thank you for the information!

Do you happen to know which properties are required / which properties disappeared? I'm wondering if since the PowerNV support wasn't used in Linux, if it got dropped at some point in the firmware. If so, Raptor will likely want to update the firmware to fix that...

@jhibbits has the following vga@0 node on firmware version 2.0:

vga@0 {

        assigned-addresses = <0x2000000 0x0 0x82010000 0x0 0xdf0000>;
        class-code = <0x30000>;
        depth = <0x20>;
        device-id = <0x2000>;
        device_type = "display";
        height = <0x300>;
        ibm,loc-code = "Backplane BMC";
        ibm,pci-config-space-type = <0x0>;
        interrupts = <0x1>;
        linux,boot-display;
        linux,opened;
        little-endian;
        phandle = <0x100003d6>;
        reg = <0xc0000 0x0 0x0 0x0 0x0>;
        revision-id = <0x30>;
        vendor-id = <0x1a03>;
        width = <0x400>;
};

instead I get on firmware version 2.7.0-dev-581-g18878e4f6:

vga@0 {

        phandle = <0xff>;
        ibm,pci-config-space-type = <0x0>;
        class-code = <0x30000>;
        revision-id = <0x41>;
        vendor-id = <0x1a03>;
        device-id = <0x2000>;
        interrupts = <0x1>;
        aspeed,scu-revision-id = <0x4030303>;
        aspeed,mcr-configuration = <0x11200756>;
        aspeed,mcr-scu-mpll = <0x71c1>;
        aspeed,mcr-scu-strap = <0x0>;
        ibm,loc-code = "BMC";
        reg = <0x20000 0x0 0x0 0x0 0x0>;
};

Note how device-type and various others are now no longer present.

I have been informed that this is a device tree node from a POWER8 machine. I'll wait for @jhibbits to deliver the appropriate node from his Thalos desktop.

In D15818#1259708, @fuz wrote:

@jhibbits has the following vga@0 node on firmware version 2.0:

vga@0 {

        assigned-addresses = <0x2000000 0x0 0x82010000 0x0 0xdf0000>;
        class-code = <0x30000>;
        depth = <0x20>;
        device-id = <0x2000>;
        device_type = "display";
        height = <0x300>;
        ibm,loc-code = "Backplane BMC";
        ibm,pci-config-space-type = <0x0>;
        interrupts = <0x1>;
        linux,boot-display;
        linux,opened;
        little-endian;
        phandle = <0x100003d6>;
        reg = <0xc0000 0x0 0x0 0x0 0x0>;
        revision-id = <0x30>;
        vendor-id = <0x1a03>;
        width = <0x400>;
};

The above snippet is from my POWER8 machine, not my Talos. My Talos, running BMC firmware 2.0 (IIRC), and, from the device tree, host firmware "talos-v1.20-983-gf6295c9c"

vga@0 {
        class-code = <0x30000>;
        device-id = <0x73ff>;
        ibm,loc-code = "CPU1 Slot2 (16x)";
        ibm,pci-config-space-type = <0x01>;
        interrupts = <0x01>;
        phandle = <0x6f5>;
        reg = <0x30000 0x00 0x00 0x00 0x00>;
        revision-id = <0xc7>;
        vendor-id = <0x1002>;
};

I don't have a dump of my Talos device tree with AST as the primary display.