This repository has been archived by the owner on Jul 11, 2023. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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>
- Loading branch information
