OSDev.org

I've been trying to write my own basic OS, and I've failed horribly.

To begin with, I went through Bran's kernel development tutorial, which was quite helpful.
I then decided to try and write my own.
I'm using GRUB as a bootloader, so I looked up the docs for it and found that I could use Multiboot to boot my OS easily.
I set it up, I've got it working (using the example kernel as a base for multiboot-specific code), except for one thing - all the info in the multiboot_info type seems wrong, other than the flags!
I don't really have much added yet, so I don't know what could be causing it to go wrong - I have console functions, and that's about it. I also implemented variations on a few standard library functions like memset and itoa.

Here is what it outputs: I'd really appreciate any help with this!
There's probably some really easy solution I'm overlooking, but nothing I can figure out works. I get this exact same output on Bochs, QEMU and Virtual PC 2007.
I can post my code, if needed, but I'm reluctant to due to the messiness of it and such.
Thanks to anyone who can tell me what I'm doing wrong, in advance.

Hi,

I think it's impossible to tell where your problem is without seeing the code. Your multiboot structure and the routines associated with it should do.

Cheers,

James

The mboot.h file is pretty much this with the names of the #defines changed: http://www.gnu.org/software/grub/manual ... 002eh.html

This is the main function: http://pastebin.com/m76d1d186

After looking at it a bit more, it seems that not *everything* is bad - the boot_device seems to be correct (I am booting from a floppy drive), as is the cmd_line. Not sure about mem_lower/mem_upper - but surely 639KB is not correct for mem_upper, I tried it with both 4MB and 8MB of RAM and get that result only.
The ELF section and memory map seems to definitely be incorrect.

It 12:00 am here.

But it seems to me that it's your printf that is the problem.

Let me explain

- flags is ok (one var passed to printf)
- mem_lower, and mem_upper are wrong (2 args passed in, both producing the same value)
- boot_device is ok (one var passed in)
- cmd_line is ok (one var passed in)
- elf_sec, size, addr, shndx are wrong (4 passed in all same value)
- mmap_addr, mmap_length are wrong (2 args passed in, both same value)
- size = 0x14, base_addr, length, type are wron (6 vars passed in all same value, based_addr is made up of upper an lower vars (which are 0x14).

See the problem

Okay, I finally figured it out! I feel so stupid - I had forgotten one line in printf.

It works now, but I have a few more questions.

When GRUB boots my OS, am I in real mode or in protected mode? The Multiboot specification doesn't seem very specific on this. If I'm in protected mode, how do I call real-mode only interrupts, if I need any?

And is there a way to find out the amount of RAM in the system? The memory map returned by GRUB is useful for the OS's internal usage, but not if I want to find out how much is available.

Sorry for asking so many things, but I want to be sure so I don't waste my time coding something completely the wrong way.

edit: Forgot to mention this.
I noticed two rather weird things in the memory map. A few of the regions have types 0x3 (the document I'm looking at mentions that only 1 and 2 are used). The last region has a base address of 0x0-40000. Is this my problem (itoa maybe?) or the memory map? Thanks.

For the real mode/protected mode thing:

I believe GRUB has an option that lets you change that for I know it can boot into 32-bit so I would assume 16-bit also. If you boot into protected mode then you won't have the interrupts. You will have to make them your-self. I believe you are booting into 32-bit (probably protected mode) because in you printf function (I use assembly and stumble through reading C so I could be wrong) you are accssesing mem and placing the data into it.(though that can be in real mode too)

As for the ram question:
There is an interrupt that does this but if you are in protected more then it is not availible. To use it you would have to boot into real-mode use the interrupt store the info then boot into your protected-mode kernel. (a bit more work for you will be activating A20 and protected-mode on your own.)

NOTE: there are methods to come out of protected-mode use the interrupts and then go back to protected mode but it is very time/proccesor consuming.

As for the last question I do not know.

You will find many of the answers in the wiki:
http://www.osdev.org/wiki/Detecting_Memory_%28x86%29

GRUB puts you in pmode. As said above, you cannot access BIOS functions in pmode. The memory map you get from GRUB is all there is. The wiki article tells you what "type 3" is. Everything that is type 1 memory is "avaialble" -- I don't know what more you would want to know about that.

And is there a way to find out the amount of RAM in the system? The memory map returned by GRUB is useful for the OS's internal usage, but not if I want to find out how much is available.

Why is the memory map not useful if you want to find out how much is available?

The memory map passed by GRUB is discovered via the BIOS functions mentioned above by bewing, so you don't have to do that yourself.