OSDev.org

This is the BGA initialization code: After initialising the BGA, I use a GDT segment which starts at the BAR0 address of the BGA PCI device and write 720*400 dwords of 0x00FFFFFF: Yet the screen remains black.
I'm using Bochs to test my OS.
Github: https://github.com/Th3Matt/FlameOS-Rewrite3/

What value you got from BAR0? Are you sure this is not bug in your PCI driver? I can not found it on git. In your GDT I see that you map memory for your graphic mode on 0xA0000-0xE6500. I don’t deal with BGA, but are you sure that video ram have to be there? From my experience with VESA, it is rather somewhere like 0xE0000000 And also, from another side of this problematic, it is easy to implement VESA, and your OS will have graphic mode on all emulators, and also on legacy real hardware.

BAR0 is 0x02000000. My GDT entry 0x38 only points to 0xA0000-0xE6500 if VGA Hardware driver is selected, otherwise it should point from BAR0 to BAR0+0x119fff, which it does in Bochs. It also seems to work in VirtualBox. My early driver code still hasn't been split off from Kernel.asm, it starts a bit after the GDT definition. I'm currently updating the Github, previously the driver only had one function, so, along with some unimportant changes to the selection dialog, I've split the function in half so it would be easier to understand (one half checks BGA ID, the other one finds BGA in PCI).
I'm using BGA because it you can control it from protected mode and don't have to switch back to real mode, so even though it doesn't work on real hardware, it's supported on Bochs, QEMU and VirtualBox, so it's still useful to implement as one of the drivers. Once I finish this driver I will move on to writing the VBE 2.0+ driver so I can support real hardware.

Th3Matt wrote:BAR0 is 0x02000000.

I'm pretty sure it isn't.

Th3Matt wrote:My GDT entry 0x38 only points to 0xA0000-0xE6500 if VGA Hardware driver is selected,

That range is too large. The VGA framebuffer is limited to 128kiB (0xA0000-0xBFFFF), and typical VGA modes only allow 64kiB (0xA0000-0xAFFFF or 0xB0000-0xBFFFF) to leave room for a second display adapter. If the framebuffer doesn't fit in that space, you must use bank switching.

Out of curiosity, have you dumped GS (using "info sreg" in the Bochs debugger) to make sure it actually points to BAR0 instead of 0xA0000? According to the wiki, some virtual machines will allow you to access the framebuffer at 0xA0000 when you request a linear framebuffer, but Bochs won't.

Using segmentation for storing the framebuffer base address is not really a portable choice. You're reserving the GS register for it, which is generally used for storing per-CPU kernel information (x86_64 has SWAPGS for that purpose).

There is no clean way to access GS and FS in C (GCC and Clang have named address spaces, but they're a nonstandard feature which is not supported in older compiler versions either), and other architectures have no concept of segmentation at all.
Storing it in a global variable results in more concise code too, no need to touch the GDT

Octocontrabass wrote:I'm pretty sure it isn't.

I've manually checked all PCI device functions and there is only one that matches the vendor ID and the device ID of the BGA card, so the BAR0 should be correct.

Octocontrabass wrote:That range is too large. The VGA framebuffer is limited to 128kiB (0xA0000-0xBFFFF), and typical VGA modes only allow 64kiB (0xA0000-0xAFFFF or 0xB0000-0xBFFFF) to leave room for a second display adapter. If the framebuffer doesn't fit in that space, you must use bank switching.

I'm just too lazy to implement a seperate size just for the VGA framebuffer, so I'm just using the same size as the BGA framebuffer.

Octocontrabass wrote:Out of curiosity, have you dumped GS (using "info sreg" in the Bochs debugger) to make sure it actually points to BAR0 instead of 0xA0000? According to the wiki, some virtual machines will allow you to access the framebuffer at 0xA0000 when you request a linear framebuffer, but Bochs won't.

See the attached screenshot.

StaticSaga wrote:There is no clean way to access GS and FS in C (GCC and Clang have named address spaces, but they're a nonstandard feature which is not supported in older compiler versions either), and other architectures have no concept of segmentation at all.

I don't plan to use C or any higher level language for my OS. Also I'm currently not planning to develop my OS for other architectures.

Th3Matt wrote:I've manually checked all PCI device functions and there is only one that matches the vendor ID and the device ID of the BGA card, so the BAR0 should be correct.

But you're not reading BAR0. You're reading the command and status registers.

Octocontrabass wrote:But you're not reading BAR0. You're reading the command and status registers.

Thanks, setting the offset to 0x10 fixed it.