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.
Details
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. | |
| 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. | |
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.
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?
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.
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"
@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.
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.