Physical Memory Management : Two Unsuccessful Scenario

[BASICFreak]

Are you getting an error from grub (such as "multiboot header not found")?

If not, where are you getting the error?

What does your kmain function look like?

Are you using legacy Grub or Grub 2?

[RezaNoei]

Are you getting an error from grub (such as "multiboot header not found")?

If not, where are you getting the error?

What does your kmain function look like?

Are you using legacy Grub or Grub 2?

no, i have no error but magic number in my multiboot header is 0x7000007e7, the i think something in my structure is wrong or incompatible.

here is my kernel.c file :

Code: Select all

#include <stdbool.h> 
#include <stddef.h>
#include "../Include/stdio.h"
#include "../Include/multiboot.h"

void kernel_main(multiboot_header_t *Header) {

	InitialScreen(White,Black,Light_Gray,Blue);
	putsmenu("CommandLine Interpreter ...");

	printf("Hello World...!\n");
//	printf("Headr.Magic = %#lx",Header->magic);
//	printf("Chakhan...\n");
	while(1);
}

i think my grub is legacy one, since it's configuration is done with this lines :
menu.lst:

Code: Select all

timeout=30
defalut=0
title	My OS (Demo)
	root (fd0)
	kernel /kernel.bin

is there any way that we can edit multiboot structure in grub or it is version dependent ?
because i think, maybe multiboot header has been changed by jamesmolloy or it is completely different because of version number.

[BASICFreak]

1, You are not passing Multiboot Header, you are passing struct multiboot_info
2, The "Magic Number" is stored in eax

you should push ebx then eax
then main should be (uint32_t MultibootMagic, struct multiboot_info *MBInfo)

Multiboot header is located at (Start of .Text + 4 [depending on your linker config])


3, do not use while(1);, use:

Code: Select all

while(1)
     __asm__ __volatile__ ("hlt");

Save power by making CPU sleep (plus helps to prevent overheating on poorly ventilated systems)

[RezaNoei]

1, You are not passing Multiboot Header, you are passing struct multiboot_info
2, The "Magic Number" is stored in eax

you should push ebx then eax
then main should be (uint32_t MultibootMagic, struct multiboot_info *MBInfo)

Multiboot header is located at (Start of .Text + 4 [depending on your linker config])


3, do not use while(1);, use:

Code: Select all

while(1)
     __asm__ __volatile__ ("hlt");

Save power by making CPU sleep (plus helps to prevent overheating on poorly ventilated systems)

Thanks,
now i can see 0x2BADB002 in output . i have replaced multiboot_info in the right place and i must check it's values.

i will add some code from my old os, tonight.

thanks

[RezaNoei]

Hello Again,

today I added my keyboard driver to my os.
so I'm happy for this event

and I have returned to my old problem, Memory Management agaim

main problem : is there any way to get my kernel size and entry point (address) while I'm using GRUB ?

Question : I want to implement a driver for one of the persistent storage devices (e.g. floppy disk, hard disk , ... ).
if i want to implement a floppy disk driver while I'm using GRUB, a question will appear in my way,
when GURB is in my floppy image, what file system it used for loading my kernel, is it FAT12, or ext family?

if i want to read and write from a usb flash drive, how long it takes to write a driver for that ?

thanks,

[BASICFreak]

Hello Again,

today I added my keyboard driver to my os.
so I'm happy for this event

and I have returned to my old problem, Memory Management agaim

main problem : is there any way to get my kernel size and entry point (address) while I'm using GRUB?

You should know where the beginning is, as you told it upon linking.

To get the end of the kernel add something similar to the following just before the last close bracket in the liker script:

Code: Select all

end = .; _end = .; __end = .;

And this will be your pointer to the end of the kernel. Accessed as:

Code: Select all

extern void* end(void);
uint32_t MyKEnd = (uint32_t)end;

Hope this helped.

And Kernel size = (End - Start).

Grub detects FS, and if it has the driver uses the disk - but yes I think FDD is FAT12/EXT2 only (unless you do sector loads instead of file loads)

[RezaNoei]

Hello Again,

today I added my keyboard driver to my os.
so I'm happy for this event

and I have returned to my old problem, Memory Management agaim

main problem : is there any way to get my kernel size and entry point (address) while I'm using GRUB?

You should know where the beginning is, as you told it upon linking.

To get the end of the kernel add something similar to the following just before the last close bracket in the liker script:

Code: Select all

end = .; _end = .; __end = .;

And this will be your pointer to the end of the kernel. Accessed as:

Code: Select all

extern void* end(void);
uint32_t MyKEnd = (uint32_t)end;

Hope this helped.

And Kernel size = (End - Start).

Grub detects FS, and if it has the driver uses the disk - but yes I think FDD is FAT12/EXT2 only (unless you do sector loads instead of file loads)

thanks,

excellent, this code works good as i think, but there is a question (most likely not a problem) ?
my kernel is about 30000 Byte, but when i used above code to retrieve my kernel size, the result was about 40000 byte !
is this difference says an important problem, or it is for alignment of each segments ?
is this a problem or it is normal ?
thanks

[BASICFreak]

excellent, this code works good as i think, but there is a question (most likely not a problem) ?
my kernel is about 30000 Byte, but when i used above code to retrieve my kernel size, the result was about 40000 byte !
is this difference says an important problem, or it is for alignment of each segments ?
is this a problem or it is normal ?
thanks

Are you remembering to subtract the Kernel's start address from the end address?

EDIT: It could also be the BSS section.

[RezaNoei]

excellent, this code works good as i think, but there is a question (most likely not a problem) ?
my kernel is about 30000 Byte, but when i used above code to retrieve my kernel size, the result was about 40000 byte !
is this difference says an important problem, or it is for alignment of each segments ?
is this a problem or it is normal ?
thanks

Are you remembering to subtract the Kernel's start address from the end address?

EDIT: It could also be the BSS section.

yes, Here :

Code: Select all

extern void* end(void);
extern void* _start(void);
uint32_t MyKEnd = (uint32_t)end;

_start symbol is in my boot.s :

Code: Select all

.....
.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM

.section .bootstrap_stack, "aw", @nobits
stack_bottom:
.skip 16384 # 16 KiB
stack_top:
.section .text
.global _start
.type _start, @function
_start:
	movl $stack_top, %esp
	pushl %ebx
	pushl %eax	
	call kernel_main
	cli
	hlt
.Lhang:
	jmp .Lhang
.size _start, . - _start

and as you said before, end symbol is in my linker script :

Code: Select all

ENTRY(_start)
SECTIONS
{
	. = 1M;
	.text BLOCK(4K) : ALIGN(4K)
	{
		*(.multiboot)
		*(.text)
	}
	.rodata BLOCK(4K) : ALIGN(4K)
	{
		*(.rodata)
	}
	.data BLOCK(4K) : ALIGN(4K)
	{
		*(.data)
	}
	.bss BLOCK(4K) : ALIGN(4K)
	{
		*(COMMON)
		*(.bss)
		*(.bootstrap_stack)
	}
	end = .; _end = .; __end = .;
}

_start is about 0x100000, i think.
if it is for .bss section, so we can accept this value.

[BASICFreak]

Looking at your code, your stack is 64KB (0x10000) and it seems the only thing in your BSS section.

The BSS section contains uninitialized data, the ELF loader should allocate space and clean (0) it for use by the Kernel.

To see how your ELF is loaded you can run (on *nix at-least):
objdump -x [KERNEL_ELF]
with a result similar to:

Code: Select all

architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x00100000

Program Header:
    LOAD off    0x00001000 vaddr 0xff100000 paddr 0x00100000 align 2**12
         filesz 0x00006000 memsz 0x00006000 flags r-x
    LOAD off    0x00007000 vaddr 0xff106000 paddr 0x00106000 align 2**12
         filesz 0x00002000 memsz 0x00282000 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00005000  ff100000  00100000  00001000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00001000  ff105000  00105000  00006000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00002000  ff106000  00106000  00007000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00280000  ff108000  00108000  00009000  2**12
                  ALLOC

I have 0x8000 Bytes of Code/Data, but my Kernel loads with 0x288000 Bytes of memory.

[RezaNoei]

Looking at your code, your stack is 64KB (0x10000) and it seems the only thing in your BSS section.

The BSS section contains uninitialized data, the ELF loader should allocate space and clean (0) it for use by the Kernel.

To see how your ELF is loaded you can run (on *nix at-least):
objdump -x [KERNEL_ELF]
with a result similar to:

Code: Select all

architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x00100000

Program Header:
    LOAD off    0x00001000 vaddr 0xff100000 paddr 0x00100000 align 2**12
         filesz 0x00006000 memsz 0x00006000 flags r-x
    LOAD off    0x00007000 vaddr 0xff106000 paddr 0x00106000 align 2**12
         filesz 0x00002000 memsz 0x00282000 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00005000  ff100000  00100000  00001000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00001000  ff105000  00105000  00006000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00002000  ff106000  00106000  00007000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00280000  ff108000  00108000  00009000  2**12
                  ALLOC

I have 0x8000 Bytes of Code/Data, but my Kernel loads with 0x288000 Bytes of memory.

Thank you a lot,
Physical memory management now is a part of my kernel, and i'm happy for that,
Next Mission : Virtual Memory Management