Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Moody <benjamin.moody@gmail.com>
To: kexec@lists.infradead.org
Subject: Setting "orig_video_isVGA" when handing off Linux framebuffer
Date: Fri, 23 Apr 2021 15:46:57 -0400	[thread overview]
Message-ID: <20210423154657.40324d86@gmail.com> (raw)

Dear kexec developers,

(Please let me know if there is a better place to discuss this issue.)

In setup_linux_vesafb (arch/i386/x86-linux-setup.c), we find the
following:

	struct fb_fix_screeninfo fix;
	struct fb_var_screeninfo var;
	int fd;

	fd = open("/dev/fb0", O_RDONLY);
	if (-1 == fd)
		return -1;

	if (-1 == ioctl(fd, FBIOGET_FSCREENINFO, &fix))
		goto out;
	if (-1 == ioctl(fd, FBIOGET_VSCREENINFO, &var))
		goto out;
	if (0 == strcmp(fix.id, "VESA VGA")) {
		/* VIDEO_TYPE_VLFB */
		real_mode->orig_video_isVGA = 0x23;
	} else if (0 == strcmp(fix.id, "EFI VGA")) {
		/* VIDEO_TYPE_EFI */
		real_mode->orig_video_isVGA = 0x70;
	} else if (arch_options.reuse_video_type) {
		int err;
		off_t offset = offsetof(typeof(*real_mode), orig_video_isVGA);

		/* blindly try old boot time video type */
		err = get_bootparam(&real_mode->orig_video_isVGA, offset, 1);
		if (err)
			goto out;
	} else {
		real_mode->orig_video_isVGA = 0;
		close(fd);
		return 0;
	}

What is the rationale for this logic?  What does the
'orig_video_isVGA' parameter actually mean, what is the difference
between VIDEO_TYPE_EFI and VIDEO_TYPE_VLFB, and why does the kernel
care about it?

I'm asking because in the context of Heads
(https://github.com/osresearch/heads), the framebuffer has been
configured by Linux (not by BIOS or UEFI), and indeed there *is* no
BIOS or UEFI, only coreboot.  Thus, 'fix.id' is not "VESA VGA" or "EFI
VGA", but rather "inteldrmfb" or "i915drmfb" or something like that,
and 'get_bootparam' provides nothing useful.  As a result,
'orig_video_isVGA' ends up being set to zero, and consequently the
booted kernel either displays nothing or displays garbage.

I realize that not all possible framebuffer formats can be described
by 'struct x86_linux_param_header', and I assume that's the reason for
checking 'fix.id'.  However, in this case, the framebuffer *is* a
standard linear format, and if we set 'orig_video_isVGA' to either
0x23 or 0x70, it appears to work correctly.

From my naive perspective, it seems that, rather than checking the
value of 'fix.id', kexec ought to be looking at 'fix.type',
'fix.visual', and perhaps other fields, to determine whether the
framebuffer format is compatible.  However, it's not apparent whether
'orig_video_isVGA' should be set to 0x23 or 0x70, since the two seem
to behave identically.

I'm a little unsure about the purpose of the "blindly try old boot
time video type" option but it seems like that's not really relevant
here in any case; the original bootloader has nothing to do with the
current framebuffer.

Benjamin

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

             reply	other threads:[~2021-04-23 19:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 19:46 Benjamin Moody [this message]
2021-05-04 23:09 ` Setting "orig_video_isVGA" when handing off Linux framebuffer Benjamin Moody
2021-05-18 16:55   ` Kairui Song
2021-05-24 22:19     ` Benjamin Moody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210423154657.40324d86@gmail.com \
    --to=benjamin.moody@gmail.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox