Using the VMM & Kernel load trouble

[Fadekraft]

Hey there

First of all, I love your tutorials, you guys have teached me a lot on OS development (After spending like, 3 months reading up on assembly and Machine Arcitechture I was real excited on getting started haha).

Anyway, I've gotten past all the current tutorials and everything works, also had to fix the kernel size problem in bootloader, wasn't to hard though.
And now I want to write a heap manager, logic tells me that a kmalloc/kfree would use the VMM instead of PMM, what would the point be otherwise?

But but but, I can't figure out how to actually use the VMM. Do i use the vmmngr_alloc_page (and in that case, how do i obtain the correct pt_entry to use for argument?)
Or do i use the MmMapPage, in which case i get page_faults everytime i try to allocate something like:

Code: Select all

	//Allocate place for heap
	for (int i = 0, j = 0; i < 1024; i++, j += 4096)
             MmMapPage (pmmngr_alloc_block (), (char *) 0xD0000000+j);

And i do use the updated version of vmm, from earlier threads
I've searched far and wide and never seemed to find a solution on these forums, I can't be only one asking this question?

Anyway, hope to get some help, thanks!


Edit* I actually fixed the loop, stupid mistake on my behalf. But would that be the correct way of doing it?

Also, i can't seem to load my kernel to other addresses that isn't in the 0000:0000-FFFF range, if i try loading it at , lets say, 1000:0000
It triple faults on kernel entry. (Actually, at first it gets a divide_by_zero exception, then it page faults).

[Andyhhp]

Also, i can't seem to load my kernel to other addresses that isn't in the 0000:0000-FFFF range, if i try loading it at , lets say, 1000:0000
It triple faults on kernel entry. (Actually, at first it gets a divide_by_zero exception, then it page faults).

How large is your kernel? The chances are that it overlaps the 1MiB boundary and loops over the IVT at the base of RAM, or that you are simply trying to write outside what 16bit mode is capable of.

I suggest you learn to use Unreal Mode http://wiki.osdev.org/Unreal_mode.

Sorry, but I cant help with your VMM question - my expertise are rather lower level than that.

~Andrew

[Fadekraft]

Thank you for the response!

The memory map for 1 mb says we have

;0x00007E00 - 0x0009FFFF - free

And by loading it to 0x1000:0x0000, which translates to 0x10000 linear should not be a problem

My kernel is 31 KiB so far. I tried loading it to 0x2000:0x3000 (0x23000), and it actually loads the kernel perfectly fine to the desired location. And it gets remapped to 1 mb after going 32 bit perfectly. However my kernel can't exceed 31 KiB now it seems before triple faulting after jumping to kernel.
When adding a bit code, so size gets increased to 31,5 KiB it almost instantly triple faults at load.
Actually i narrowed it down to it triple faulting during my second call to dprintf() Untill then all registers and segments look fine.

And no problem about the VMM, hopefully Mike or someone else gets around to answer that part then

[Andyhhp]

Have you checked how many times the bootloader loops to load your kernel? This doesnt sound like a coincidence that it fails at a power of 2.

Perhaps have your bootloader print out how many blocks of 512 bytes it has copied, and assert that it is the same size as what you are expecting for the kernel.

~Andrew

[Fadekraft]

Thanks for replying, mmm so i tried. My bootloader prints a '.' for each sector read, counted it out to be 63 dots.

My kernel is 32.256 bytes, divide that by 512 and you get 63, so it seems to load the complete kernel.

So it seems that the full kernel is getting loaded to memory, which makes it even more strange. But when you say that it's funny when it fails on a power of 2, it reminds me i not long ago had a problem with kernel going to 30,5 KiB instead of 30 KiB... I'm going to try make it be 32 KiB exactly, then its a power of 2. But this seems like a stupid problem if thats why its faulting, isn't there a fix to this?

[Fadekraft]

Okay, so i tried just making 32 KiB fully instead of 31,5 KB, now my kernel triple faults almost instantly on being jumped too (It triple faults instead of at the second dprintf(). So it only made the problem worse. I must be overwriting something in memory??


Looks like it's faulting here (when kernel is 32,0 KiB):

0008:0000000000101645 (unk. ctxt) push 0x00000000

And then it says next:
jmp far f000 : e05b
which i know is because of triple fault in bochs. But that seems like it's faulting on a stack operation, so perhaps the stack is all messed up?

Edit*

When kernel is 31,5 KiB it seems to fault here:

0008:0000000000102409 (unk. ctxt) inc eax

[halofreak1990]

I have the same problem with triple faulting if my kernel size exceeded 31.5 KB
However, up until that point it runs just fine. Could you post the code that sets up the stack?
I had a problem with the stack, as set up by the bootloader, that was overwriting parts of my kernel.
I relocated the stack somewhere else, and the problem went away.

[Fadekraft]

I have the same problem with triple faulting if my kernel size exceeded 31.5 KB
However, up until that point it runs just fine. Could you post the code that sets up the stack?
I had a problem with the stack, as set up by the bootloader, that was overwriting parts of my kernel.
I relocated the stack somewhere else, and the problem went away.

Bootloaders stack real mode:

Code: Select all

cli
xor               ax, ax
mov               ds, ax
mov               es, ax
mov               ax, 0x9000  ;Begin stack at 0x98000
mov               ss, ax
mov               sp, 0x8000
sti

Bootloader stack protected mode:

Code: Select all

mov               ax, KRNL_DATA_DESC	;data selector
mov               ds, ax
mov               es, ax
mov               ss, ax
mov               esp, 90000h          ;Stack starts at 90000h and grows downwards

Kernel never modifies the stack from bootloader protected mode, so its the same there

[Fadekraft]

Okay, so narrowed it down to where it actually faults

It gets a DIVIDE_BY_ZERO exception when accessing data from the struct:

Code: Select all

/**
*	Mounts the filesystem
*/
void fsysFatMount () {

	//! Boot sector info
	PBOOTSECTOR bootsector;

	//! read boot sector
	bootsector = (PBOOTSECTOR) flpydsk_read_sector (0);

	//! store mount info (IT FAULTS IN THE BELOW CODE) 
	_MountInfo.numSectors     = bootsector->Bpb.NumSectors;
	_MountInfo.fatOffset      = 1;
	_MountInfo.fatSize        = bootsector->Bpb.SectorsPerFat;
	_MountInfo.fatEntrySize   = 8;
	_MountInfo.numRootEntries = bootsector->Bpb.NumDirEntries;
	_MountInfo.rootOffset     = (bootsector->Bpb.NumberOfFats * bootsector->Bpb.SectorsPerFat) + 1;
	_MountInfo.rootSize       = ( bootsector->Bpb.NumDirEntries * 32 ) / bootsector->Bpb.BytesPerSector; (DIVIDE_BY_ZERO, Data might be corrupt?)

}

Edit*
Okay so i printed out the sector read in hex, and it was nothing but 0's. So the sector is getting read wrong

So came a bit further, i moved the DMA buffer to a place i knew where data already. And now i printed the data at the dma buffer, not the data it is supposed to read from the floppy. It simply does not read the data, keep in mind that all of this works when i load the kernel to a place below 0x10000 (before relocation to 1mb). Right now I'm loading to 0x21000

[halofreak1990]

DMA memory needs to be identity mapped and not cross a 64KB boundary.
If you hadn't already done so, allocate a region of memory, and identity map it.

To do so, I use the following code to set up a 64KB DMA memory region:

Code: Select all

// allocate 64KB DMA buffer and identity map it
void* flpydsk_dma = pmmngr_alloc_blocks(16);
vmmngr_map_page(flpydsk_dma, flpydsk_dma);

I know 64KB is mostly overkill, but I like to be able to load most files into memory in one go.