VESA video mode - 800x600x16bit #60

jabedude · 2019-06-23T21:16:02Z

Hello all, this PR checks if VESA 2.0 or 3.0 is supported and then enables it with fixed 800x600. This is very rough, so please let me know what else we need to do.

TODO:

Proper color handling
Query the framebuffer address from hardware instead of hardcoding it (if possible)
Pass the framebuffer address in BootInfo

phil-opp · 2019-06-26T09:27:07Z

Thanks a lot for tackling this!

We don't want to hard code the video mode for the user, but instead make it configurable through cargo features. We currently support vga text mode and a simple vga graphics mode (320x200). Could you place the VESA code in a new file in src/video_mode and add a cargo feature for enabling it, like it is done for the other video modes?

jabedude · 2019-06-26T20:57:09Z

Sure thing!

phil-opp · 2019-07-01T12:57:04Z

Thanks, looks good now!

Were you able to print something to the screen through this? I just tried to update the src/printer/mod.rs module (used for printing panic messages) with a new vesa printer, but I didn't know the framebuffer location.

jabedude · 2019-07-01T17:49:08Z

I meant to ping you, I actually was hoping to get some help with testing printing with the new video mode. I should be able to get you the framebuffer address.

phil-opp · 2019-07-02T07:20:07Z

Sure!

Printing should work similar to the vga_320x200 module, we only need the framebuffer address and the pixel format (i.e. how many bytes per pixel, how are the RGB channels encoded).

jabedude · 2019-07-02T22:00:42Z

I found the framebuffer address for qemu: 0xFD000000. The pixel format is 5 red bits, 6 green, and 5 blue bits. I'm still having issues trying to modify vga_320x200 to print correctly

phil-opp · 2019-07-06T08:37:58Z

@jabedude Thanks! The problem was that we need to add a page table mapping for the physical address 0xFD000000 to the page table. I pushed a commit (I hope that is fine with you) that maps the framebuffer to the 500th entry of the level 2 page table. It also adds a new printer, which is the vga_320x200 printer with some modifications. Now it looks like this:

I didn't add any code for color handling, so the colors are a bit strange. I deliberately didn't paint the screen back in clear_screen so that we see that really the whole screen is blanked.

ethindp · 2019-07-06T17:08:02Z

Here's what I'm wondering: will this bootloader be modified sometime to make it possible to boot on real hardware? It seems like the bootloader goes off virtualized/emulated addresses, at least for anything that's not 0xb8000. I would love to be able to boot my kernel on real hardware with this thing! If not, how can I get it to do that?

…

On 7/6/19, Philipp Oppermann ***@***.***> wrote: @jabedude Thanks! The problem was that we need to add a page table mapping for the physical address `0xFD000000` to the page table. I pushed a commit (I hope that is fine with you) that maps the framebuffer to the 500th entry of the level 2 page table. It also adds a new printer, which is the vga_320x200 printer with some modifications. Now it looks like this: ![image](https://user-images.githubusercontent.com/1131315/60753915-cac2e280-9fd9-11e9-86f1-f3c38388002a.png) I didn't add any code for color handling, so the colors are a bit strange. I deliberately didn't paint the screen back in `clear_screen` so that we see that really the whole screen is blanked. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #60 (comment)

-- Signed, Ethin D. Probst

phil-opp · 2019-07-06T17:15:55Z

@ethindp For me the bootloader already works on real hardware. What problems do you have exactly?

Also, could you elaborate your statement about "virtualized/emulated addresses"? Since you replied to this pull request, I assume that you mean using the address 0xFD000000? This is just a stop-gap solution for experimentation, the plan is to query this address from the VESA later.

ethindp · 2019-07-06T21:27:42Z

Aha, I see. Well, I was following yorublog_os tutorial and wanted to make an ISO with it. I might've passed the wrong args to mkisofs, but I created the IsO and the bootloader got stuck on stage 1 (I think that there is an issue for this).

…

On 7/6/19, Philipp Oppermann ***@***.***> wrote: @ethindp For me the bootloader already works on real hardware. What problems do you have exactly? Also, could you elaborate your statement about "virtualized/emulated addresses"? Since you replied to this pull request, I assume that you mean using the address `0xFD000000`? This is just a stop-gap solution for experimentation, the plan is to query this address from the VESA later. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #60 (comment)

-- Signed, Ethin D. Probst

phil-opp · 2019-07-07T09:57:11Z

Have you tried the instructions at https://os.phil-opp.com/minimal-rust-kernel/#real-machine? The bootimage tool already creates a hard disk image, so you don't need mkisofs for this (I'm not sure about CD images though).

As a side note: Can we continue the conversation in a new issue? This issue issue is about adding support for the VESA video mode, so I think a separate issue would fit better.

jabedude · 2019-07-07T20:45:24Z

@phil-opp That is awesome! Of course, I was hoping to collaborate in this PR (I have no prior experience with VESA/BIOS printing).

phil-opp · 2019-07-09T12:41:57Z

@jabedude Great! I updated the PR description with a todo list. Do you think anything else is missing?

jabedude · 2019-07-11T02:35:51Z

The TODOs look good to me! I pushed a commit to query the framebuffer address, but I'm not sure the best way to test that.

Related to the third TODO, how can I get access to the VESAfb variable from load_elf()?

phil-opp · 2019-07-11T09:08:16Z

I think we can do the same as in

bootloader/src/main.rs

Lines 66 to 77 in b5d43ca

    
           // Symbols defined in `linker.ld` 
        
           extern "C" { 
        
               static mmap_ent: usize; 
        
               static _memory_map: usize; 
        
               static _kernel_start_addr: usize; 
        
               static _kernel_end_addr: usize; 
        
               static _kernel_size: usize; 
        
               static __page_table_start: usize; 
        
               static __page_table_end: usize; 
        
               static __bootloader_end: usize; 
        
               static __bootloader_start: usize; 
        
           }

to get access to VESAfb and then pass as argument to load_elf. To use it in the printer, we need to initialize it at runtime with the given framebuffer address, e.g. through an init method.

bjorn3 · 2019-07-11T14:39:58Z

src/printer/vesa_800x600.rs

+                    }
+                }
+            }
+            _ => panic!("unprintable character"),


Please dont panic in this case. Maybe print ? or something like that.

.
I realise this code doesn't actually contain a Mutex lock on the writer, so my previous comment is misguided, but generally yes - a substitute character is probably the way to go.

adeadman · 2019-08-11T00:37:45Z

I think we can do the same as in

bootloader/src/main.rs

Lines 66 to 77 in b5d43ca

// Symbols defined in `linker.ld`

extern "C" {

static mmap_ent: usize;

static _memory_map: usize;

static _kernel_start_addr: usize;

static _kernel_end_addr: usize;

static _kernel_size: usize;

static __page_table_start: usize;

static __page_table_end: usize;

static __bootloader_end: usize;

static __bootloader_start: usize;

}

to get access to VESAfb and then pass as argument to load_elf. To use it in the printer, we need to initialize it at runtime with the given framebuffer address, e.g. through an init method.

Thinking about this, for flexibility we probably want to load an entire VBEModeInfo struct into the kernel space so we have flexibility for choosing different modes in the bootloader.

The framebuffer mapping to virtual memory currently hardcodes the framebuffer address for qemu and the size for an 800x600x16 mode, so getting it to work with an arbitrary framebuffer address (e.g. from real hardware) using the vbe mode info is a bit harder. I've been working on it on and off for the last couple weeks and am wondering if it would be easier or even possible to do the memory mapping from the rust code, or if it has to be done while in protected mode stage 3 before we jump to the kernel loading.

ethindp · 2019-08-11T19:41:18Z

Hate to go OT, but would it be possible for me to boot my kernel using Grub? Or would that not work (i.e. if I were to use grub-mkrescue)?

…

On 8/10/19, Aaron Deadman ***@***.***> wrote: > I think we can do the same as in > > https://github.com/rust-osdev/bootloader/blob/b5d43caa72173b502dd1eabcee29d534ef24741a/src/main.rs#L66-L77 > > to get access to `VESAfb` and then pass as argument to `load_elf`. To use > it in the printer, we need to initialize it at runtime with the given > framebuffer address, e.g. through an `init` method. Thinking about this, for flexibility we probably want to load an entire VBEModeInfo struct into the kernel space so we have flexibility for choosing different modes in the bootloader. The framebuffer mapping to virtual memory currently hardcodes the framebuffer address for qemu and the size for an 800x600x16 mode, so getting it to work with an arbitrary framebuffer address (e.g. from real hardware) using the vbe mode info is a bit harder. I've been working on it on and off for the last couple weeks and am wondering if it would be easier or even possible to do the memory mapping from the rust code, or if it has to be done while in protected mode stage 3 before we jump to the kernel loading. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #60 (comment)

-- Signed, Ethin D. Probst

phil-opp · 2019-08-12T07:34:19Z

@ethindp See https://github.com/rust-osdev/bootloader/blob/master/doc/chainloading.md and #49. In the future, please just open a new issue instead of commenting on an unrelated issue.

phil-opp · 2019-08-12T07:39:13Z

@adeadman

I've been working on it on and off for the last couple weeks and am wondering if it would be easier or even possible to do the memory mapping from the rust code, or if it has to be done while in protected mode stage 3 before we jump to the kernel loading.

If we don't access it before the mapping, we can probably map it later. However, we need to adjust our panic printer for that (i.e. it shouldn't try to print to the VESA framebuffer before it is mapped).

phil-opp · 2021-05-22T16:42:07Z

Given that the bootloader was changed significantly since this PR (e.g. in #130), I'm going to give this a close. We still don't support choosing custom framebuffer resolutions though, so if anyone wants to tackle this, please let me know!

Thank you @jabedude for all your work!

Add .swp files (vim tmp files) to gitignore.

2512b1b

jabedude force-pushed the vesa branch from 71fd9ab to 0c9252d Compare June 24, 2019 22:31

Add VESA initiation code feature (Issue rust-osdev#37)

d433419

jabedude force-pushed the vesa branch from 0c9252d to d433419 Compare June 29, 2019 19:06

Map VESA framebuffer and print something

afce492

phil-opp mentioned this pull request Jul 9, 2019

Comments for "https://os.phil-opp.com/vga-text-mode/" phil-opp/blog_os#405

Closed

Get VESA framebuffer address from VESA Info Block

8635acd

bjorn3 reviewed Jul 11, 2019

View reviewed changes

Base automatically changed from master to main February 5, 2021 12:27

phil-opp closed this May 22, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VESA video mode - 800x600x16bit #60

VESA video mode - 800x600x16bit #60

jabedude commented Jun 23, 2019 •

edited by rybot666

Loading

phil-opp commented Jun 26, 2019

jabedude commented Jun 26, 2019

phil-opp commented Jul 1, 2019

jabedude commented Jul 1, 2019

phil-opp commented Jul 2, 2019

jabedude commented Jul 2, 2019

phil-opp commented Jul 6, 2019

ethindp commented Jul 6, 2019 via email

phil-opp commented Jul 6, 2019

ethindp commented Jul 6, 2019 via email

phil-opp commented Jul 7, 2019

jabedude commented Jul 7, 2019

phil-opp commented Jul 9, 2019

jabedude commented Jul 11, 2019

phil-opp commented Jul 11, 2019

bjorn3 Jul 11, 2019

adeadman Aug 1, 2019 •

edited

Loading

adeadman commented Aug 11, 2019

ethindp commented Aug 11, 2019 via email

phil-opp commented Aug 12, 2019

phil-opp commented Aug 12, 2019

phil-opp commented May 22, 2021 •

edited

Loading

VESA video mode - 800x600x16bit #60

VESA video mode - 800x600x16bit #60

Conversation

jabedude commented Jun 23, 2019 • edited by rybot666 Loading

phil-opp commented Jun 26, 2019

jabedude commented Jun 26, 2019

phil-opp commented Jul 1, 2019

jabedude commented Jul 1, 2019

phil-opp commented Jul 2, 2019

jabedude commented Jul 2, 2019

phil-opp commented Jul 6, 2019

ethindp commented Jul 6, 2019 via email

phil-opp commented Jul 6, 2019

ethindp commented Jul 6, 2019 via email

phil-opp commented Jul 7, 2019

jabedude commented Jul 7, 2019

phil-opp commented Jul 9, 2019

jabedude commented Jul 11, 2019

phil-opp commented Jul 11, 2019

bjorn3 Jul 11, 2019

Choose a reason for hiding this comment

adeadman Aug 1, 2019 • edited Loading

Choose a reason for hiding this comment

adeadman commented Aug 11, 2019

ethindp commented Aug 11, 2019 via email

phil-opp commented Aug 12, 2019

phil-opp commented Aug 12, 2019

phil-opp commented May 22, 2021 • edited Loading

jabedude commented Jun 23, 2019 •

edited by rybot666

Loading

adeadman Aug 1, 2019 •

edited

Loading

phil-opp commented May 22, 2021 •

edited

Loading