When booting kernel in QEMU, QEMU just stays idle...

[monsterhunter445]

I've created a C kernel, and I've booted my kernel using the QEMU emulator. No error occurs, but QEMU emulator window just stays idle and prints 'Booting Hard Disk...'. Does it take that long to boot a small a** kernel... *cough* excuse my French. There is a screenshot attached below if you would like to see for your self what I'm taking about. I'll also post the source code below too as an attachment.

[gerryg400]

When you hlt with interrupts disabled in qemu, qemu will stop updating the display. This will be one of your problems.

This will also be a problem

Code: Select all

volatile char* videomem = (volatile char*) 0xB800;

Video memory is at 0xb8000.

[monsterhunter445]

I've did some changes, to both Kernel.asm and Kernel.c, but still the QEMU emulator just stays still and doesn't do anything. Here is command I used to start QEMU:

Code: Select all

qemu -L "C:\Program Files (x86)\Qemu\pc-bios" -hda win.qcow -kernel Kernel.bin -boot c

Code For Kernel.asm:

Code: Select all

;NASM Code For The Kernel
[BITS 32] ; Sets up 32-bit protected mode for the kernel!
[global start]
[extern _dmain] 
start: 
call _dmain ; Invokes the main function which is located in C the code.
hlt

Code For Kernel.c:

Code: Select all

// This source file contains the main algorithm for the Kernel.
// Written in C and written by Daniel Lopez

//Global variable, containing the pointer to the video memory.gcc 
volatile char* videomem = (volatile char*) 0xb800;
void print_string(int color, char* string)
{
	
	while(*string != 0)
	{
		*videomem = *string; // Assign each character to memory location 0xB800.
		*videomem++;	
		string++;
		*videomem = color;
		videomem++;
	}
	
}
int string_length(char* string) // This subroutine determines a string's length but not including the null terminating character.
{
	int length = 0;
	while(*string++)
	{
		length++;
	}
	return length;
}
void reverse_string(char* string, char* reversed_string) // This subroutine reverses a char array.
{
	int length = string_length(string) + 1;
	while(length == 0) // Loops until the length is equal to zero.
	{
		*reversed_string = string[length];
		length--;
		reversed_string++;
	}

}
dmain(void)
{
	print_string(8, "This is my first kernel!\n\nWelcome!");
}

P.S By the way my OS is Windows 7, but you probably could tell because of the file directory...

[gerryg400]

Rather than

Code: Select all

volatile char* videomem = (volatile char*) 0xb800;

Wouldn't

Code: Select all

volatile char* videomem = (volatile char*) 0xb8000;

be better ?

[monsterhunter445]

Damn...I didn't see the lack of a zero...sorry about that...I feel like a newbie...actually I'm . But still when I change the hex address to the correct address. It still stays idle and on top of that my AV scanner thinks my kernel is some trojan / virus which is a fallacy. But that is irrelevant to the problem. Oh...thanks for the help I appreciate your time and effort.

[neon]

Hello,

Code: Select all

*videomem++;

You are overwriting your character with the attribute byte. Also, I would personally recommend rewriting your print_string routine. It can be written much better.

[linuxfood]

Code: Select all

;NASM Code For The Kernel
[BITS 32] ; Sets up 32-bit protected mode for the kernel!
[global start]
[extern _dmain] 
start: 
call _dmain ; Invokes the main function which is located in C the code.
hlt

Sorry, am I missing something here about QEMU or the original post?

It doesn't look to me like the OP actually sets up protected mode, his stack segment, or anything else about his environment.. Nor does he specify that he is one of those odd folk using one of a handful of real mode C compilers.

[Chandra]

Can we have your bootloader source code? May be you have not loaded enough sectors from the disk(with respect to the size of the kernel). Did it ever work at some point of time?

[xenos]

Code: Select all

qemu -L "C:\Program Files (x86)\Qemu\pc-bios" -hda win.qcow -kernel Kernel.bin -boot c

According to the QEMU docs, a kernel loaded by the -kernel command line option needs to be either a bzImage or Multiboot compliant. It seems that your kernel does not belong to any of these categories. Probably the easiest way to fix this is to include a Multiboot header (see the link above) in your code.

(I never used the -kernel option, though.)

[CWood]

Personally, I would consider writing my own boot loader. Also, as it seems, you have done nothing in the way of initialisation. How does the kernel know where all of its data is going? Consider setting yourself up properly. On top of this, set yourself up in PMode, OR, write the whole thing in ASM. As well, [bits 32] comes later, when PMode has been set up. Put your multiboot header in, if you wish to use QEMU's loader, or GRUB, or anything else, for that matter, other than your own. Sorry, got a bit carried away there. But there is significantly a lot you can do. What does your makefile look like? Because, no offence, but judging by the mistakes you have made so far, its possible you are linking to ELF, or PE format. I don't know what formats QEMU supports in the way of multiboot executables, but I know that it would probably be wise to go flat binary.

[Combuster]

I don't know what formats QEMU supports in the way of multiboot executables, but I know that it would probably be wise to go flat binary.

Will you please read up on multiboot before making incorrect or misleading claims, like most if not all of your post.

[xenos]

I don't know what the heck QEMU is doing to make my (as I thought) Multiboot compliant ELF kernel crash completely when I try to load it with the -kernel option o.O Not even my physical memory manager works, even though the Multiboot info seems to be fine... I'm really curious to find out what's going on there, although I guess it would need a lot of debugging, and the result would not be of any practical use since my kernel will never be loaded this way.

I recommend using GRUB instead - it can save you a lot of trouble. (But if you want to go through a lot of trouble in order to learn something, start writing a boot loader from scratch, learn about the transition to protected mode and have fun )

[xenos]

I found the reason why my kernel crashes when it gets loaded by QEMU with the -kernel option: Im simulating a machine with 128 MB RAM. In the Multiboot structure, QEMU reports 128 MB of upper memory - but it should report only 127 MB since the first 1 MB belongs to lower memory. This causes my memory manager to assume that there is 1 MB more memory and it starts allocating pages and placing page tables in this non-existing area, which quickly leads to a page fault...