x86 asm bios interrupts in C

[alberinfo]

hi, my question is, how can i add bios interrupts in my C kernel code?it's 'cause i'm trying to implement vesa.

this the asm code that i've tried to switch to a vesa mode:

Code: Select all

mov ax, 0x4F02  -  mov bx, 0x11B  -  int 10h

the code is for asm, but i cant call the interrupt in C.

That's all the question. Thanks!

[BenLunt]

You can use it and call the BIOS in C if you:

1) Use the correct compiler
*and*
2) Are in real (or unreal) mode.

Depending on your compiler, whether you loaded your kernel with Grub, are now in 32-bit protected mode, etc., you may not be able to at all.

We need more information. What stage of the loader/kernel are you in? What loaded the current code? Is it already in protected mode? What compiler are you using? Etc.

Ben

[alberinfo]

i compile my kernel with gcc, loaded by grub.my kernel is actually by the gui, i'm asking for the interrputs because im trying to call int 10h for set vesa video mode. grub loads a kernel loader, which (obviusly) loads the kernel.for the kernel loader i'm using nasm.it isn't in protected mode.

kernelloader.asm:

Code: Select all

BITS 32
section .text
      align 4
      dd 0x1BADB002
      dd 0x00
      dd - (0x1BADB002+0x00)

global start
extern main ; kernel function
start:
     cli
     call main
     hlt

thanks!

[SpyderTL]

Since you are using GRUB, by the time your code runs, you will already be in 32-bit Protected Mode, which means that you no longer have access to the BIOS to change the video mode.

However, you can request that GRUB set the video mode before running your code. Just add some additional fields to your "Multiboot Header" that contain the desired video resolution, and GRUB will handle it for you.

You can find the specs for the multiboot header here: https://www.gnu.org/software/grub/manua ... der-layout

I don't see any good OSDev Wiki pages for the multiboot header, so I may create one at some point.

[alberinfo]

thanks, but i don't understand how to set it in grub. anyway my question was how to call a bios interrupt, not how to set vesa mode... if the problem is that i'm in 32-bit protected mode, then i have to switch to real mode with my kernel...that's out my brain jaja

Thanks!

[Brendan]

Hi,

thanks, but i don't understand how to set it in grub. anyway my question was how to call a bios interrupt, not how to set vesa mode... if the problem is that i'm in 32-bit protected mode, then i have to switch to real mode with my kernel...that's out my brain jaja

To execute BIOS functions (including VBE) while your kernel is normally running in protected mode (or long mode) there's 4 options:

• Use virtual 80x86 mode (not supported for long mode)
• Use an interpreter/emulator (slow)
• Have a wrapper that switches to real mode, then uses the BIOS, then switches back to protected/long mode
• Reserve one CPU for "firmware stuff" and leave it in real mode doing a "for(ever) {wait for a command from other CPUs, and do it}" loop (very wasteful and silly)

The main problem (for all of these options) is that the BIOS will expect hardware to be in a specific state, so changing any of the hardware (changing MSRs, reconfiguring PIC or IO APIC, modifying anything in PCI configuration space, starting any native drivers, etc) has the potential of breaking firmware's expectations and causing problems; and when an OS is running (after drivers are started) it needs to be able to handle IRQs in a reasonable amount of time (to avoid losing IRQs; so that the OS does grind to a halt as processes wait for drivers that are waiting for IRQs that were lost).

Regardless of which option you choose to be able to execute BIOS functions, it becomes a huge/complex nightmare to make it work properly/safely (unless it's restricted to immediately after kernel starts, before anything is changed, where it's still a lot easier to just do it in boot loader instead).

The other problems are that the OS tends to become tied to BIOS and more difficult to port to anything else (including UEFI); and that the BIOS functions (all of them, including VBE) are a crippled joke (barely adequate for the < 1 second needed to get an OS started) that don't get you any closer to doing anything properly. In other words, it's simply too much hassle for something that's guaranteed to awful anyway.

For video; the best alternative is to get boot loader to do it and tell kernel the details of the frame buffer/s; so that kernel doesn't have to care if the boot loader used VBE (BIOS) or UGA or GOP (UEFI) or something else. The only real disadvantage is that you can't change the video mode after boot (until/unless you have native video drivers), but that's an "almost entirely irrelevant" disadvantage (especially if you have modern "resolution independent" graphics) - all of the users of your OS will accept that "no driver" means certain restrictions without complaining about the restrictions, partly because they'll be too busy complaining that there aren't enough native drivers (e.g. no "page flip on vertical sync", no GPU support, no shaders, no hardware accelerated MPEG decoder, no support for multiple monitors, ... ).


Cheers,

Brendan

[SpyderTL]

thanks, but i don't understand how to set it in grub.

Just add some additional fields to your "Multiboot Header" that contain the desired video resolution, and GRUB will handle it for you.

You currently have 3 fields in your multiboot header:

Code: Select all

      dd 0x1BADB002
      dd 0x00
      dd - (0x1BADB002+0x00)

If you read the multiboot header specs, you will see that you can add a few more fields and GRUB will set the desired graphics resolution for you.

[alberinfo]

thanks SpyderTL for your reply, i'll try to make it.
but brendan, your reply is very informative, and interesnting. about the options that you have told me, i want to use virtual 80x86 mode.can you give me a link or something like that, so i can know where to start??

Thanks!

[Schol-R-LEA]

If you haven't done so already, I recommend that you read the wiki page on Virtual 8086 Mode, though you should be aware that the page only provides an overview of the process; there are too many details which will be dependent on how your OS organizes things like interrupt handlers, process scheduling, and inter-process communication.

Note that these are all things that your OS must have in place before you will be able to set up V86 support, as my understanding is that the kernel must be able to (at minimum) manage the process(es) which run in V86 mode, trap any system instructions or illegal opcodes which get run in V86 mode for appropriate processing (which includes the INT instruction itself), and pass the results of any V86 operations to the kernel or other processes.

It is the considered opinion of several members here, including myself, that the work needed to get V86 mode running to the point where you can use the Legacy BIOS routines in a consistent and stable manner is more than the work of implementing those functions yourself in protected mode. It should also be considered that, as I mentioned in another thread recently, Intel has already given an End-Of-Life roadmap for UEFI Compatibility Mode Services (with a goal date of 2020), meaning that in a few years support for the Legacy BIOS routines will be removed entirely from newer Intel firmware, and there is every reason to believe that other UEFI implementations for x86 will follow suit.

The big exception to this is video mode setting, for which there is no stable hardware-level standard that can be used for all PC hardware. This is why UEFI boot loaders, and most 'serious' boot loaders for Legacy BIOS systems (such as GRUB), provide a way to set the video mode to what you want before loading the kernel. However, there is more to the story than this.

While the wiki claims that using VBE BIOS routines is the only option for mode-setting, this is not quite true; what it really means is that it is the only way to do it if you don't have details of the graphics system's hardware and internal firmware. In the days when the VESA VBE standard was set, this would have primarily meant the details of the video registers, but today, it means knowing how to interface with the GPU. If you know which video hardware is being used, and if you have the documentation needed to interface with the GPU, you can write a driver which can set the video mode as needed.

Unfortunately, those are two very big ifs.

The former presents a bootstrapping problem, as you will need to not only determine which driver you will need to use for the current hardware configuration when you install the system (or at least the video drivers), you will need to check for changes to it each and every time the system reboots. The usual solution is to have have a default video mode set by the boot loader, then when the kernel initializes the drivers (regardless of whether they are part of the kernel or separate user-space processes), the driver needs to confirm that the last known configuration still holds, and if not (e.g., if the owner replaced or upgraded the video card), then it needs to go at minimum inform the kernel that it cannot proceed with the driver previously in use.

The latter problem, on the other hand, may prove more stubborn, as not all manufacturers give out the details needed to write a complete driver (e.g., NVidia, Broadcomm), and some which do still hold back on the details of accessing the systems advanced or premium features. While the necessary details have often been partially or wholly reverse-engineered, the manufacturers are also constantly updating their designs to stay one step ahead of FOSS driver groups such as Nouveau. Also, most of the details of the FOSS implementations are really only found in the driver code itself, so if you are implementing (for example) an NVidia driver, you may need to grovel over a lot of that code to see how to adapt it to your OS.

[alberinfo]

Thanks for the reply.
i included it, in the instant that grub charges the bootloader, it comes back to grub.it think it's cause the iret function wich don't allows to call the kernel main function.
Any solution?
Thanks

UPDATE:as i was thinking removing iret function it charges kernel, but it don't make sense if i cant load correctly the mode

UPDATE2:i tried to switch to 11Bh vesa mode but while calling int 10h qemu restarts and comes back to grub...

[Brendan]

Hi,

i included it, in the instant that grub charges the bootloader, it comes back to grub.it think it's cause the iret function wich don't allows to call the kernel main function.
Any solution?

My solution would be to set the IDT limit to zero immediately after your protected mode code is started (by GRUB); so that it's easier to catch bugs when someone tries to use software interrupts designed for real mode while they're in protected mode (where those "designed for real mode" interrupts can't work properly at all).

That way you'll get an instant crash as soon as you do something silly (like try to use "int 0x10") instead of getting undefined behaviour with bizarre symptoms.


Cheers,

Brendan

[alberinfo]

I'll try tomorrow as soon as i can

Thanks!

[alberinfo]

hi i tried to set idt limit to zero, but ld gives me a error so i wont compile. the error is:

bootloader.o: in function 'idt_end':
bootloader.asm:(.text+0x3d): reubication truncated for adjust: R_386_16 agnaist '.text'

this is the bootloader code:

Code: Select all

BITS 32

section .text
    align 4
    dd 0x1BADB002
    dd 0x00
    dd - (0x1BADB002+0x00)

global start
extern main
start:
    cli
    lidt [idt_info]
    smsw ax
    and eax, 1
    je callmain
    mov ebp, esp
    push dword [ebp+4]
    push dword [ebp+8]
    pushfs
    or dword [esp], (1 << 17)
    push dword [ebp+12]
    push dword [ebp+16]
    iret

callmain:
    call main
    hlt

section .text
idt_info:
    idt_start dw 0
    idt_end dw idt_start - 1

why it fails!!??

now, there's something strange.there i call smsw ax, but why ax, and not eax??it's the code ok?

Thanks!

UPDATE: now solution is that it isnt pushfs, it's pushfd. also in idt_info is:

Code: Select all

idt_start dd 0
idt_end dd idt_start - 1

and not how says osdev wiki:

Code: Select all

dw idt_end - idt_start - 1
dd idt_start

but it doesn't work anyway.help please

[dseller]

I would suggest you learn x86 assembly first. Make sure you understand what labels are.

[alberinfo]

mmm... if i quit "iret", it continue fine and do not comes back to grub.it's fine or i have obligatory to use iret or it isn't important??

Thanks!