OSDev.org

Posted: **Mon Jan 13, 2020 9:56 am**

Hi,

There are many GRUB-experts on this forum, maybe one of you know the answer.
My boot loader is capable of booting many different ways (from ROM, disk, cdrom, as Linux kernel, etc.) All works fine, except when I boot it with recent GRUB2 versions.

Because my loader is quite complex, I've narrowed the problem down to a simple VESA call and 512 bytes of code. I've attached the source and the outputs. The problem is, when this code is booted through GRUB using Multiboot, and it switches back to real mode to continue where the other boot paths start, then some of the BIOS routines go crazy. I think the code sets up everything for real mode correctly (segments, GDT, IVT etc.). I wonder what could be missing.

Code: Select all

            USE32
multiboot_start:
            cli
            cld
            lgdt        [GDT_value]
            mov         ax, DATA_BOOT
            mov         ds, ax
            mov         es, ax
            jmp         CODE_BOOT:.real ;load 16 bit mode segment into cs
            USE16
.real:      mov         eax, CR0
            and         eax, 07FFFFFFEh ;switching back to real mode
            mov         CR0, eax
            xor         ax, ax
            mov         ds, ax          ;load segment registers DS and CS
            jmp         0:@f
@@:         lidt        [idt16]         ;restore IDT as newer GRUBs mess it up
            ;fallthrough realmode_start

realmode_start:

The expected behaviour: this code (after realmode_start) should print strings on screen as well as on serial port, then set up 800x600x32 VESA mode. That's it. This works in both qemu and bochs if you boot it from ROM, though boot sector etc. But if you boot it through GRUB, then the screen resolution is either wrong; not set; or the BIOS code gets into an infinite loop. If it's not how I switch to real mode, then could it be that GRUB accidentally destroys some variables in BDA or EBDA? Bochs also gives me "io write to address 00000000 len 2" errors (as you can see in the attachment, there's no out instruction in stage2.asm, only BIOS int calls).

I've provided a Makefile for testing ("make all" will compile the code and create the required images):

Code: Select all

make bochsrom
make bochsbios
make bochsgrub
make qemurom
make qemubios
make qemugrub

The question is: how can we switch back to real mode properly after booting from Multiboot so that BIOS routines work as expected?

Cheers,
bzt

ps: the attachment is a targz, but phpbb does not allow the extension tgz.

Posted: **Mon Jan 13, 2020 11:35 am**

Try adding "mov ss, ax" before jumping to CODE_BOOT:.real.
It seems that grub leaves the upper part of ESP nonzero. If the SS shadow descriptor is left with D=1, then CPU will use ESP when accessing stack. And BIOS expects that after "mov bp, sp" the BP register will point to the current stack, which is no longer true.

Posted: **Mon Jan 13, 2020 2:02 pm**

quirck wrote:Try adding "mov ss, ax" before jumping to CODE_BOOT:.real.
It seems that grub leaves the upper part of ESP nonzero. If the SS shadow descriptor is left with D=1, then CPU will use ESP when accessing stack. And BIOS expects that after "mov bp, sp" the BP register will point to the current stack, which is no longer true.

Bingo! Thank you very much! It was indeed! I set up ss and sp as well in 16 bit mode, but the upper part of esp left nonzero. Reloading the ss shadow register and clearing all 32 bits of esp solved the issue! It's still not working properly, but at least the code doesn't get into an infinite loop in a BIOS routine any more!

Thanks!
bzt

OSDev.org

[SOLVED] Switching back to real mode from GRUB

[SOLVED] Switching back to real mode from GRUB

Re: Switching back to real mode from GRUB

Re: Switching back to real mode from GRUB