Framebuffer problem

[mishpro]

I'm developing my own kernel using the Multiboot2 protocol. I request a 1280x720x32 framebuffer, then handle the tag in kernel_main to initialize the framebuffer. It works perfectly in QEMU (with OVMF) and Bochs, but when I test it on real hardware, the screen stays blank. My kernel: https://github.com/asfi43/upload1

My hardware setup: MSI H510M-B, Intel Core i3-10105F, NVIDIA GT 1030

[Octocontrabass]

Is it possible the 64-bit framebuffer address doesn't fit in a 32-bit pointer?

[iansjack]

W hich bootloader are you using? The specification says that this is a 64-bit address but the boot loader should set it to a value under 4GB.

[eekee]

Serial port output (or i/o) makes debugging display issues very much easier. Ethernet (with telnet) is good too, but serial is easier to drive.

Some machines have a debug port. It's even easier to drive than serial port, you just outb a byte to the port, but it's not universally available and the port number varies. One of the most common ports may conflict with ACPI. If your motherboard has a hex display or is very old (up to MCA or so), you have this. The older machines send it to a serial port, presumably at a fixed speed. Honestly, I'd go for the regular serial port, but I'll paste my notes if you want.

[mishpro]

I don't think the issue is with the pointer size because I'm emulating it in qemu-system-x86_64, which means it's also emulating a 64-bit system. That said, my kernel is linked as a 32-bit executable, and GRUB loads it in 32-bit mode, not 64-bit.

I'm using GRUB 2.12.

I can't access the serial port because I don't have a second machine and a serial adapter. I'd really like to see some logs if possible.

[AnotherIdiot]

I'm using GRUB 2.12.

That means you are getting 100% correct multiboot2 implementation, as GRUB2 is the reference implementation for multiboot2.

I don't think the issue is with the pointer size because I'm emulating it in qemu-system-x86_64, which means it's also emulating a 64-bit system. That said, my kernel is linked as a 32-bit executable, and GRUB loads it in 32-bit mode, not 64-bit.

Try it with qemu-system-i386 to see if it works, if it does, its a QEMU bug, if not, its your code that is doing something wrong.

I can't access the serial port because I don't have a second machine and a serial adapter. I'd really like to see some logs if possible.

Yes you can, its a thing in QEMU, pass the flag -serial stdio to log it to the terminal output, or you can just output it to a file, but -serial stdio is better than the file in my opinion because of how it does terminal formatting.

[mishpro]

Try it with qemu-system-i386 to see if it works

It does

Yes you can, its a thing in QEMU, pass the flag -serial stdio to log it to the terminal output, or you can just output it to a file, but -serial stdio is better than the file in my opinion because of how it does terminal formatting.

Yeah, I know I can view the serial output in QEMU. What I meant is, I'd like to see the logs directly on my machine without using serial, since I don't have it set up.

[Octocontrabass]

W hich bootloader are you using? The specification says that this is a 64-bit address but the boot loader should set it to a value under 4GB.

The specification can say whatever it wants; the bootloader has no control over where the firmware chooses to place the framebuffer. (But the firmware might have a setting to place PCI MMIO below 4GB, which would include the framebuffer.)

I don't think the issue is with the pointer size because I'm emulating it in qemu-system-x86_64, which means it's also emulating a 64-bit system.

That just means OVMF has chosen to place the framebuffer below 4GB. It still won't work on any PC where the firmware chooses to place the framebuffer above 4GB.

[mishpro]

I fixed this issue by changing the UEFI mode from UEFI to CSM in the BIOS. So, from what I understand, this means my firmware was giving me a 64-bit pointer that couldn't be used because the kernel was in 32-bit mode. Does this mean I need to switch to 64-bit mode? Is there a way to do this by requesting it from GRUB instead of enabling long mode manually?

[thewrongchristian]

I fixed this issue by changing the UEFI mode from UEFI to CSM in the BIOS. So, from what I understand, this means my firmware was giving me a 64-bit pointer that couldn't be used because the kernel was in 32-bit mode. Does this mean I need to switch to 64-bit mode? Is there a way to do this by requesting it from GRUB instead of enabling long mode manually?

As far as I know, multi-boot and grub don't support native 64-bit mode.

But there are other bootloader options that do support loading and running a kernel directly into 64-bit mode, such as Limine or BOOTBOOT.

[Octocontrabass]

Does this mean I need to switch to 64-bit mode?

No, you can access any 64-bit physical address using PAE paging in 32-bit mode.

Is there a way to do this by requesting it from GRUB instead of enabling long mode manually?

No, GRUB can't move the framebuffer or enable paging or switch to 64-bit mode for you.

[eekee]

Does this mean I need to switch to 64-bit mode?

No, you can access any 64-bit physical address using PAE paging in 32-bit mode.

You may want PAE paging for some other peripherals too.