GRUB2 VBE Set the highest and greatest possible video mode?

[Combuster]

I can't debug in VMWare

Ever heard of printf debugging?

[osdever]

@catnikita255

Do not use my nick!

Lol i was just called you, because you were have a topic about GRUB VBE.

I'm not using your nick, like in XenForo i'm calling you in thread, but looks this function not working in PhpBB

I'm not sure why you get so angry...

I'm not angry, sorry. Oh, I don't know anything about your question.

[CrafterMan24]

I can't debug in VMWare

Ever heard of printf debugging?

I debugged with serial debug after this, thanks.
I debugged with COM1 port.

[CrafterMan24]

Bump

[kzinti]

Bump

What are you waiting on?

[CrafterMan24]

Bump

What are you waiting on?

Is that possible that i said on the subject?

[kzinti]

Grub already picks a pretty good resolution by default... If you want something better, (but much more complicated), Brendan already answered you.

[freecrac]

Hello.
The details for to get the EDID/EEDID can be found in the following public documents from vesa.org (need register/login):
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf

Dirk

[CrafterMan24]

Hello, again. After many researchs, i found toaruos code.

His os is really great, cool work @klange!

I read from your source how can i set the video mode automaticly...

Then i modified my code like yours...

But i'm having a crazy problem

It is the output from the debugger:

Crafty Debug Mode:

SVGA Info:

Width: 61440
Height: 65363
Depth: 255
Screen Pointer: 0xF000D62C

My GRUB Config:

Code: Select all

insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
insmod iso9660

menuentry "Crafty" {
	multiboot /boot/Crafty.bin
	set gfxmode=auto
	boot
}

And then my bootstrap assembly:

Code: Select all

.extern sys_multiboot_info

# Declare constants used for creating a multiboot header.
.set ALIGN,    1<<0             # align loaded modules on page boundaries
.set MEMINFO,  1<<1             # provide memory map
.set VIDINFO,  1<<2             # provide video info
.set FLAGS,    ALIGN | MEMINFO | VIDINFO # this is the Multiboot 'flag' field
.set MAGIC,    0x1BADB002       # 'magic number' lets bootloader find the header
.set CHECKSUM, -(MAGIC + FLAGS) # checksum of above, to prove we are multiboot

# Declare a header as in the Multiboot Standard. We put this into a special
# section so we can force the header to be in the start of the final program.
# You don't need to understand all these details as it is just magic values that
# is documented in the multiboot standard. The bootloader will search for this
# magic sequence and recognize us as a multiboot kernel.
.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM

.long 0x00000000
.long 0x00000000
.long 0x00000000
.long 0x00000000
.long 0x00000000

.long 0x00000000

.long 0
.long 0
.long 32

# Currently the stack pointer register (esp) points at anything and using it may
# cause massive harm. Instead, we'll provide our own stack. We will allocate
# room for a small temporary stack by creating a symbol at the bottom of it,
# then allocating 16384 bytes for it, and finally creating a symbol at the top.
.section .bootstrap_stack, "aw", @nobits
stack_bottom:
.skip 16384 # 16 KiB
stack_top:

# The linker script specifies _start as the entry point to the kernel and the
# bootloader will jump to this position once the kernel has been loaded. It
# doesn't make sense to return from this function as the bootloader is gone.
.section .text
.global _start
.type _start, @function
_start:
	# Welcome to kernel mode! We now have sufficient code for the bootloader to
	# load and run our operating system. It doesn't do anything interesting yet.
	# Perhaps we would like to call printf("Hello, World\n"). You should now
	# realize one of the profound truths about kernel mode: There is nothing
	# there unless you provide it yourself. There is no printf function. There
	# is no <stdio.h> header. If you want a function, you will have to code it
	# yourself. And that is one of the best things about kernel development:
	# you get to make the entire system yourself. You have absolute and complete
	# power over the machine, there are no security restrictions, no safe
	# guards, no debugging mechanisms, there is nothing but what you build.

	# By now, you are perhaps tired of assembly language. You realize some
	# things simply cannot be done in C, such as making the multiboot header in
	# the right section and setting up the stack. However, you would like to
	# write the operating system in a higher level language, such as C or C++.
	# To that end, the next task is preparing the processor for execution of
	# such code. C doesn't expect much at this point and we only need to set up
	# a stack. Note that the processor is not fully initialized yet and stuff
	# such as floating point instructions are not available yet.

	# To set up a stack, we simply set the esp register to point to the top of
	# our stack (as it grows downwards).
	movl $stack_top, %esp

	pushl 	%eax
	pushl	%ebx

	# Write multiboot info pointer to memory
	mov		%ebx, sys_multiboot_info

	# We are now ready to actually execute C code. We cannot embed that in an
	# assembly file, so we'll create a kernel.c file in a moment. In that file,
	# we'll create a C entry point called kernel_main and call it here.
	call kernel_main

	# In case the function returns, we'll want to put the computer into an
	# infinite loop. To do that, we use the clear interrupt ('cli') instruction
	# to disable interrupts, the halt instruction ('hlt') to stop the CPU until
	# the next interrupt arrives, and jumping to the halt instruction if it ever
	# continues execution, just to be safe. We will create a local label rather
	# than real symbol and jump to there endlessly.
	cli
	hlt
.Lhang:
	jmp .Lhang

# Set the size of the _start symbol to the current location '.' minus its start.
# This is useful when debugging or when you implement call tracing.
.size _start, . - _start

Don't know what i'm doing wrong...

Also i tried changing "set gfxmode=auto" to set "gfxmode=1024x768", resolution intercased from the automatic resolution to 1024x768, but still same result in debugger output...

When i use my grub config as:

Code: Select all

menuentry "Crafty" {
	multiboot /boot/Crafty.bin
	set gfxmode=1024x768
	boot
}

It works correctly, it returns the correct values, but there is a problem...

When i set "set gfxmode=1024x768" to "gfxmode=auto" when my grub config like the above, it is not setting an automatic resolution, just changing to 640x480x32bpp

Not sure why, really... @klange if you see this, can you help me, please?

If you need, this is the correct output:

Crafty Debug Mode:

SVGA Info:

Width: 640
Height 480
Depth: 32
Screen Pointer: 0xFD000000

Using GRUB2,
i686-elf-gcc cross compiler...

[Combuster]

Screen Pointer: 0xF000D62C

That's an null pointer dereference alright.

Have you checked all the other variables as well? Are your structs OK?

[CrafterMan24]

Screen Pointer: 0xF000D62C

That's an null pointer dereference alright.

Have you checked all the other variables as well? Are your structs OK?

I think yes, because when i edit grub.cfg back, it returns with correct values...

Also looks when i edit grub.cfg to set automatic modes, it breaks the vbe mode info, but not multiboot info...

Because i added some infos and saw this:

Crafty Debug Mode:

SVGA Info:

Width: 61440
Height: 65363
Depth: 255
Screen Pointer: 0xF000D62C

Memory Info:

Memory Size: 128 MB

Memory size is correct, but others not...

Edit:

I converted Width, Height and Depth to hex, and got these results:

F000, FF53, FF...

Can it be a null pointer at F000:FF53? Not sure correct, just an idea.

Oh yes, it looks it is a null pointer. I searched on google and saw 3-4 null F000:FF53 errors about grub...
Also i tested vbe_info with 0, and yes, vbe_info is 0, so null...

So my problem is really similar at here: http://f.osdev.org/viewtopic.php?f=1&t=18297

After my some grub.cfg editings, it looks i'm really close to solve the problem...

When i remove "insmod video_bochs" it is being fixed, and working great, setting the automatic mode correctly, and getting the output, too...

So before the config looks:

insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
insmod iso9660

menuentry "Crafty" {
multiboot /boot/Crafty.bin
set gfxmode=auto
boot
}

After my fixing edits the config looks:

insmod vbe
insmod vga
insmod video_cirrus
insmod iso9660

menuentry "Crafty" {
multiboot /boot/Crafty.bin
set gfxmode=auto
boot
}