Memory in protected mode

[konglikecomputer]

Hi all,
I am a beginner in OS development and I have been reading this site as non-member for about
2 months now. I have not started coded anything, I have average knowlege in Assembly language and C language. I am just accumulating theories as much as possible before I begin programming. I had already read Bran's Kernel Development and James Malloy Tutorial, both tutorials gave me so much knowledge about developing a simple OS.I have read about paging too, this is where I would like to put my question. Why all the codes here and tutorial always send the kernel to 1 MB address space or above like 0xC0000000 when doing paging. Never was mentioned the kernel be put to 0x0000 as starting point. I am guessing because the first 1 MB is not contigous memory because of video memory, I also would like to consider that the bios data are at the first 1 Mb, but we won't use the bios data if we are in already in protected, right? wrong?.
What am I missing in my understanding in why no one use the first 1 MB in their OS development as kernel location.

Thank you so much.
kong

[Creature]

Most of the first 1 MB does indeed belong to the BIOS. However, it also contains valuable information about things such as APM, where to find a list of available VBE modes, etc. If you want to do any kind of interaction with the BIOS, you will need this data to be intact. Also when working with GRUB, there is a 32-bit protected mode GDT set up for you. But you don't know where it is located, so in theory there is a chance you'd overwrite it with your kernel (which will probably cause a triple fault).

So in short: there is a lot of BIOS data under 1 MB and you will probably need a part of this data.

[konglikecomputer]

Hi Creature,
Thanks for your good response, but I won't use GRUB as bootloader, I will use simple boot loader that I read here in this forum, once I switched to protected mode I have no intention of going back to real mode so I believe I don't need the Bios data anymore. Why I would like to put my kernel at 0x0000 because it is so easy to understand in mapping and paging. I guess that video card would be my problem or I still missing more?

Thanks,
Kong

[Hangin10]

There's also ACPI information which is often found in the BIOS area. There could also be reserved memory (often below the VGA memory) which is unconditionally used by hardware running code that the OS can't do anything about (afaik). If you ever want to change video modes without writing a driver for each card, you'll need at least a copy of the IVT and BIOS.

As long as your code can handle the memory map returned by the BIOS, you should be OK, but eventually you will realize how difficult placement at 0x0 is going to make life for your kernel (and you). 0x100000 is often the start of contiguous memory with very few "gotchas" higher up (at least for the next 14MB, when there used be a hole (at 15MB)).

Is it really that hard to use a link script to link the kernel elsewhere, especially when not using paging?
Oh, and if you don't use paging and put the kernel at 0x0, how do you plan on catching pointer bugs (or at least the easy ones)?

[konglikecomputer]

Hangin 10,
Thank you so much, these info that you told me are missing in my thoughts.
Catching pointer bugs is very new to me, can't we point the pointers to specific address that we reserve for this purpose?


Kong

[Brendan]

Hi,

Thanks for your good response, but I won't use GRUB as bootloader, I will use simple boot loader that I read here in this forum, once I switched to protected mode I have no intention of going back to real mode so I believe I don't need the Bios data anymore. Why I would like to put my kernel at 0x0000 because it is so easy to understand in mapping and paging. I guess that video card would be my problem or I still missing more?

There's a large difference between physical addresses and virtual addresses. If you put your kernel at physical address 0x00000000, then your kernel will not be able to be larger than about 600 KiB, because the EBDA, the legacy video area and the ROM space all get in the way. If you put your kernel at virtual address 0x00000000, then you can use whatever physical addresses you like (e.g. the kernel could be at virtual address 0x0000000 while also being at physical address 0x00100000 where there's less chance of "stuff" being in the way). If you like, you can also determine which physical addresses to use for the kernel dynamically, to avoid any possible "stuff" (and even use multiple physically non-contiguous pieces of RAM), while still having the kernel at a fixed virtual address.

Catching pointer bugs is very new to me, can't we point the pointers to specific address that we reserve for this purpose?

Uninitialised data areas (e.g. a program's ".bss") are typically filled with zeros. This means uninitialised integers end up being zero, and uninitialised pointers also end up being zero. If you fill a program's uninitialised data area with something else, then uninitialised pointers could end up pointing somewhere else, but uninitialised integers would also contain "strange" values. Also, some accesses tend to be offsets from a base address (e.g. "foo = myStruct->myField;"), which means if the pointer "myStruct" happens to be zero (uninitialised), then the CPU would access "0x000000000 + offset_of_MyField". Basically to catch bugs you'd want an area (e.g. 0x00000000 to 0x0000FFFF) and not just one address.


Cheers,

Brendan

[egos]

If kernel is placed above application in virt. addr. space then application can have fixed base regardless of kernel size.

[konglikecomputer]

Hi Brendan,
I think that's about it.
Now,I will try to make an OS located at physical address 0x10000 and virtual address 0xC00000000.

Thank you very much.

Egos thank you also for your input.

Kong

[Solar]

Regarding pointer bugs... it's been some time since I last told an Amiga episode.

AmigaOS didn't have memory protection, virtual addressing or anything like that. All addresses were physical. That also meant that libraries would be loaded at some random address, wherever there was space at the time of loading. To get access to the library functions, an app would request the library from the OS (OpenLibrary()), receiving a LibraryBase pointer as return value. Each function in that library had a fixed offset from LibraryBase, where you would find a pointer to that function in the current version of the library. (Function addresses would change, but the offset would always stay the same. This even allowed for having multiple versions of the same function - e.g. for backward compatibility - in one library binary.)

However, to be able to call OpenLibrary() in the first place, you needed the kernel's address (ExecBase). Since 0x00000000 is not a valid address in a C machine (C standard states that writing to NULL must never break anything), the engineers chose "the next best thing", and placed ExecBase, by convention, at 0x00000004.

Now picture:

Code: Select all

// No-one would write this code verbatim, but it's easy to picture
// some screwed-up implementation doing something similar.
int * p = NULL;
p[1] = 0;

BOOM. Anyone who didn't cache ExecBase somewhere is now unable to contact the kernel.

[konglikecomputer]

Hi Solar,
This is a very important lesson/experience.

Thank you so much.
Perry