You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 11, 2023. It is now read-only.
We've had a problem since last august. If graphics worked on qemu, they did not work
on hardware. If they worked on hardware, they did not work on qemu.
The problem comes down to the nature of VESA setup and how it works.
Quick tutorial.
Kernels on hardware start in 16-bit mode, go to 32-bit mode, then
64-bit mode. The 16-bit code, and much 32-bit code, is not considered
part of the kernel; it's setup stuff, tacked on once the kernel is built
by scripts from the kernel Makefile. It's discarded once the real kernel
starts. Think of the kernel as the spaceship, and this 16- and 32- bit
stuff as the first and second stage.
While in the 32-bit code, if VESA is enabled, the 32-bit code calls and
sets it up. The whole pile of code is pretty nasty.
That VESA interaction you see sometimes? Looks like this?
Press <ENTER> to see video modes available, <SPACE> to continue, or wait 30 sec
Mode: Resolution: Type: Mode: Resolution: Type: Mode: Resolution: Type:
0 F00 80x25 VGA 1 F01 80x50 VGA 2 F02 80x43 VGA
3 F03 80x28 VGA 4 F05 80x30 VGA 5 F06 80x34 VGA
6 F07 80x60 VGA 7 300 640x400x8 VESA 8 301 640x480x8 VESA
That's being done BEFORE the 64-bit kernel boots, in 32-bit code.
One reason to do this is it's pretty easy to call VESA BIOS setup calls
from that 32-bit code, but a mess to do it from 64-bit. And BIOS calls
are a security exposure anyway.
So, the boot sequence:
16 bit -> 32 bit -> ask about VESA if it's enabled -> 64 bit
What happens in kexec, i.e. when the webboot kernel boots
the tinycore kernel?
we did this: 16 bit -> 32 bit -> ask about VESA -> 64 bit
now we do this: -> kexec new kernel -> new kernel 64 bit
See the sequence? Second kernel's 32-bit code never runs.
And there's a problem. The second kernel never gets to ask you
about VESA mode. It has to be done in the first kernel. So we enable
all the VESA framebuffer stuff.
But what about hardware? Can't we just enable all the hardware?
Well, ... that's a problem, because then the flow changes. Kexec starts
the second kernel at the 64-bit entry point.
16 bit -> 32 bit -> 64 bit -> set up hardware
And, when you kexec:
we did this before: 16 bit -> 32 bit -> 64 bit -> set up hardware
now we do this: -> kexec -> 64 bit -> set up hardware
oh, oops.
You can see the problem: we enter the new kernel at the 64-bit entry point,
but it still wants to set up hardware, and that explains the hardware wedges
we were having.
So, this change enables all the VESA setup a kernel does in 32-bit, but nothing
more. It certainly fixes the problems we've had on qemu.
Will it work on hardware? We'll see. It should. But ... we'll see.
The trick will be not getting in trouble by enabling graphics HARDWARE
in the first kernel; let the kernel you kexec do that stuff.
N.B. This works ok with
qemu -kernel command.
it does not work with booting a usb stick in qemu via syslinux,
but it does work just fine on a thinkpad T510.
I also include a syslinux.cfg.example to show what I did that worked.
NOTE: you really need to pick a VESA type; if you don't, tinycore graphics
won't work.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
0 commit comments