On Sun, 08 Feb 2026 18:32:25 +0100,
Crystal Kolipe <kolipe.c@exoticsilicon.com> wrote:
> 
> On Sun, Feb 08, 2026 at 10:15:46AM +0300, Vitaliy Makkoveev wrote:
> > On Sat, Feb 07, 2026 at 07:20:04PM +0100, Kirill A. Korinsky wrote:
> > > On Sat, 07 Feb 2026 14:11:05 +0100,
> > > Vitaliy Makkoveev <mvs@openbsd.org> wrote:
> > > > 
> > > > On Fri, Feb 06, 2026 at 06:39:03PM +0100, Kirill A. Korinsky wrote:
> > > > > > > 
> > > > > > > What about my suggestion to have a dummy framebuffer?
> > > > > > > 
> > > > > > 
> > > > > > I had tried, but I wasn't able make something that works.
> > > > > > 
> > > > > > Or better to say all my attemt leads to that machine still hungs.
> > > > > > 
> > > > > > Here hard part: this is remote machine, I haven't got access to serial
> > > > > > console on it, I can only boot it, or boot in "rescue mode" (Linux) or as
> > > > > > to attach KVM.
> > > > > > 
> > > > > > ... and without the way to debug I can't figure out why and where it hangs.
> > > > > >
> > > > > 
> > > > > Shall I drop this diff ?
> > > > > 
> > > > 
> > > > I agree with Mark. The dummy console which you intentionally enable via
> > > > /etc/boot.conf like "set tty dummy" is the right way.
> > > > 
> > > 
> > > Well, I think this is another feature.
> > > 
> > > On this machine, it doesn't matter whether I set tty dummy or com0.
> > > 
> > > However, Linux boots headless on this machine and uses vgaarb for the video
> > > card, even though nothing is connected to it. My diff replicates the logic
> > > to decide that it is safe to use as VGA compatible card.
> > > 
> > > I think we need https://marc.info/?l=openbsd-tech&m=176980480915521&w=2 to
> > > support this setup, as I've seen a few reports of similar behavior.
> > > 
> > 
> > This machine boots only if it has monitor connected, right? Otherwise it
> > panics somewhere.
> 
> My understanding was that it doesn't _panic_, but init is unable to open
> /dev/console.
>

Yes, it looks like it waits something and as soon as KVM is attached it
normaly boots.

> In normal use, the machine is using amdgpu to provide a wsdisplay device.
> 
> When using the ramdisk kernel, since amdgpu is not available, we would expect
> the machine to fall back to efifb, which it _does_ IFF a monitor is connected,
> (or likely more accurately, if the firmware can read EDID data from such a
> monitor).
> 
> However if a monitor is not connected, the firmware of the machine does not
> configure a graphical efi framebuffer, and sets the efi framebuffer base
> address to 0x00, which correctly causes our efifb driver NOT to attach.
> 
> The firmware itself and the OpenBSD bootloader are presumably using efi text
> mode to function.  But efi text mode is not available after you make the call
> to exit boot services, so a kernel driver cannot, (easily), be written to use
> it.
> 
> In the past, most machines in this situation had one or both of:
> 
> * Working VGA hardware, that the vga driver in the ramdisk kernel could attach
>   to.
> 
> OR
> 
> * Operators knowledgable enough to recognise what was going on and work around
>   it, (E.G. use a serial console).
> 
> This hardware does not have fully enabled legacy VGA.
> 
> So no console device is available when booting the ramdisk kernel.
> 
> Various solutions have been proposed, each of which has downsides:
> 
> * Fake a serial console.
> 
> * Fake a VGA device, and write to the memory locations traditionally associated
>   with VGA hardware regardless of the consequences.
> 
> * Make a good-faith attempt to verify that there is actually VGA hardware at
>   those addresses and then write to them.
> 

So far I was able to boot this machine only with this three ways, all other
ideas leads to not boot.

> * Write a simple EFI application to reinit the hardware and enable the
>   graphical efi console regardless of whether a monitor is physically present.
> 
> * Fake a VGA device with system memory allocated to a dummy frame buffer.
> 
> * (a new one) write a kernel device driver that wsdisplay can attach to which
>   does nothing, or simulates an MDA or whatever.
>
> > Seems your video card reports wrong data in the
> > headless mode.
> 
> Not really.  The UEFI firmware gets no EDID data from the monitor, and as a
> result of that, does not confiure a framebuffer.  That's a valid, if unusual,
> behaviour for the firmware to take.  UEFI doesn't guarantee the presence of a
> graphical framebuffer.
> 

-- 
wbr, Kirill