Protected mode problems

If you are new to OS Development, plan on spending some time here first before going into the other forums.

Moderator:Moderators

hahnski07
Posts:19
Joined:Sat Jul 18, 2009 1:50 am
Re: Protected mode problems

Post by hahnski07 » Fri Aug 14, 2009 11:56 am

Well that seems to work, but I am still very confused.

When my bootloader and stage2 were still serparate I was having the exact same problems, but I have not heard anyone else encountering the same issues.
Mixing 16 bit and 32 bit code the way you are currently doing can cause possible alignment issues. ie, you are having 16 bit code call 32 bit functions that call BIOS interrupts. This alone is fine, but is also prone to possible low level issues (from my experience, anyways...)
What? All my functions are 16 bit except for the jump into protected mode so I'm still confused as to what you mean.

Andyhhp
Moderator
Posts:387
Joined:Tue Oct 23, 2007 10:05 am
Location:127.0.0.1
Contact:

Re: Protected mode problems

Post by Andyhhp » Fri Aug 14, 2009 12:10 pm

The reason other people tend not to have this problem is because they use ORG 0x7C00 for their bootloader and ORG 0x500 (or equivelent if loading to a different address) and set the segment registers to 0.

You had it the other way round which works for any relative addressing but failes for absolute addressing (loading the GDT in your case).

As for the mixing of 16bit and 32bit code, both sets of opcodes need aligning to specific values to work properly. Alignment issues cause the CPU to start reading one instruction from half way though another instruction, ultimatly putting garbage into the decode stage of the CPU.

Ideally, what you should do to reduce potential problems is something like this:

Code: Select all

16bit code
..
<jump to after utility functions>
<utility functions>
32bit code
2byte sigature
That way, there is only 1 potential alignment problem as opposed to two that you have when switiching back into 16bit mode after jumping to 0x0:0x500

~Andrew
Image

hahnski07
Posts:19
Joined:Sat Jul 18, 2009 1:50 am

Re: Protected mode problems

Post by hahnski07 » Fri Aug 14, 2009 12:27 pm

I see what you're saying now and I moved my 16 bit functions right after the OEM, the only reason I hadn't done that in the first place was cause I didn't want to have to scroll through the functions every time to get a point in my code :)

Andyhhp
Moderator
Posts:387
Joined:Tue Oct 23, 2007 10:05 am
Location:127.0.0.1
Contact:

Re: Protected mode problems

Post by Andyhhp » Fri Aug 14, 2009 12:28 pm

What do you mean right after the OEM?
Image

hahnski07
Posts:19
Joined:Sat Jul 18, 2009 1:50 am

Re: Protected mode problems

Post by hahnski07 » Fri Aug 14, 2009 7:49 pm

The OEM Parameter Block, Describes the disk as FAT12.

hahnski07
Posts:19
Joined:Sat Jul 18, 2009 1:50 am

Re: Protected mode problems

Post by hahnski07 » Fri Aug 14, 2009 11:18 pm

Here's a thought, the kernel is supposed to be loaded to 0x100000, right?

Why not set ds to 0xFFFF and di to 0x0010 after A20 has been enabled and load the kernel to the right place from 16 bit code?

Andyhhp
Moderator
Posts:387
Joined:Tue Oct 23, 2007 10:05 am
Location:127.0.0.1
Contact:

Re: Protected mode problems

Post by Andyhhp » Fri Aug 14, 2009 11:35 pm

You could do that if you want.

The reason the tutorials dont is because we load a second stage between the bootloader and the kernel which has to go somewhere else.

One point to note - if you are using that method then your kernel is limited to 64K. That is the maximum ammout you can load starting at the 1MB mark using realmode segment:offset addressing.

~Andrew
Image

hahnski07
Posts:19
Joined:Sat Jul 18, 2009 1:50 am

Re: Protected mode problems

Post by hahnski07 » Fri Aug 14, 2009 11:59 pm

Yeah, 64k could be kinda limiting, I'm just trying to make it as fast and space efficient as possible... maybe I'm just sick of Windows taking five minutes to boot :twisted:

Andyhhp
Moderator
Posts:387
Joined:Tue Oct 23, 2007 10:05 am
Location:127.0.0.1
Contact:

Re: Protected mode problems

Post by Andyhhp » Sat Aug 15, 2009 7:57 am

Yeah - I agree.

Then again, windows taking ages to boot is not entirely windows fault. The vast majority of the time taken is 3rd party processes starting at start-up and slowing everything down.

If you want a somewhat easier way of loading your kernel to anywhere in memory, read up about unreal mode
http://wiki.osdev.org/Unreal_mode
which is a brutal hack (it was a bug in some of the early processors that is now kept for backward compatability because people exploited the hack iirc)

Note however that int 0x13 uses es:di for addressing so to load out of the first 1MB, you need to alter the base address of es before loading. This new method does limit you to loading 1MB at a time.

However, you can just change the base of es after 1MB if you want and continue loading.

~Andrew
Image

Post Reply