OSDev.org

Posted: **Thu Nov 18, 2010 9:39 am**

gerryg400 wrote:Did you set ES when you got to protected mode ? Did you enable a20 ?

You're loading your kernel at 0x1000 and your bootloader is at 0x7c00. If your kernel is bigger than 0x6c00 what will happen ?

When you use objcopy to make your binary, you are assuming that _main appears at the very beginning of the file (at offset 0). Does this in fact happen ? You are making the very dangerous assumption that the entry to main will be the very first byte in the .text segment of your linked code.

so according to the bootloader's requirements, what i need to do to make things up and going?
yes, im assuming that the main function starts at the first byte, if its not, what i need to do to run it from the bootloader?
why do i need to enable a20?
what value i need to put in ES when i go to protected mode and why?

Posted: **Thu Nov 18, 2010 12:28 pm**

Hello,

All of the information provided should be enough to answer your question. You know your bootloaders limitations, so you need to either:

-Verify using a debugger that your entry point is indeed at the start of the binary it might not be. or:
-Prepend a header to your kernel binary that tells your bootloader where the entry point is actually at. or:
-Add file loading capability to your bootloader. Have it load and execute the entry point directly so no assumption is made (recommended)

why do i need to enable a20?

You dont need to enable A20, however you will if you want to access the HMA.

what value i need to put in ES when i go to protected mode and why?

You only set DS, SS, and CS to a valid data segment when entering pmode. The other segments are invalid so if they are referenced it will result in a #GPF.

Posted: **Mon Nov 22, 2010 3:23 am**

OK... i think i fixed it.

i changed the name of the main function to "kmain".
im using this linking script:

Code: Select all

ENTRY(main)
phys = 0x00001000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}

and the bat file:

Code: Select all

nasm bootsect.asm -f bin -o build\bootsect.bin

gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o build\main.o main-basic.c
gcc -c video-basic.c -o build\video.o
gcc -c string-basic.c -o build\string.o

ld -T link.ld -o build\kernel.o build\main.o build\video.o build\string.o
objcopy -R .note -R .comment -S -O binary build\kernel.o build\kernel.bin

makeboot build\a.img build\bootsect.bin build\kernel.bin
pause

but!!!
now im having a new problem... and I think its related to the way i compile things.
im trying to print "hello world" on the screen, but then i am trying, im having some very weird problems...

then i trying to print something with a length of 1 or 3 characters its look like the string is empty. when the length is 4-5 its normal, and when its more then 5 its crashes...
thats the way im trying to use the function.

Code: Select all

const char hello[] = "hello";
kprint(&hello);

this is the function:

Code: Select all

void kprint(char *_message)
{
  unsigned int i=0;
  unsigned char *vidmem = (unsigned char *)0xB8000;

  while (_message[i] != 0) {
    *vidmem = _message[i];
	vidmem += 2;
	i++;
  }

  out(0x3D4, 14);
  out(0x3D5, (unsigned char)(0));
  out(0x3D4, 15);
  out(0x3D5, (unsigned char)(i));
}

Posted: **Mon Nov 22, 2010 3:38 am**

Why does the name (kmain) matter ?

Did you fix the other problems ? In particular, the problem that you are assuming that main begins at the first byte in your binary ?

Please post your binary file.

Posted: **Mon Nov 22, 2010 5:05 am**

You're not setting the attribute byte for each character. So the colour (background, foreground, blink) it appears is completely random.

Posted: **Mon Nov 22, 2010 6:03 am**

gerryg400 wrote:Why does the name (kmain) matter ?

Did you fix the other problems ? In particular, the problem that you are assuming that main begins at the first byte in your binary ?

Please post your binary file.

i dont know why... but the compilization works when i name the main function "kmain", and all the other stuff works... so i think it start at the first byte...

JamesM wrote:You're not setting the attribute byte for each character. So the colour (background, foreground, blink) it appears is completely random.

i have another function that clear the screen to black.

a.img is the combination of bootsect.bin and kernel.bin and its runnable (im using bochs)

Posted: **Mon Nov 22, 2010 6:24 am**

i think it start at the first byte...

Don't think, know. You can use objdump to find out.

Posted: **Mon Nov 22, 2010 7:28 am**

This is what the beginning of your code looks like

Code: Select all

00000000 <.>:
       0:	83 ec 2c             	sub    $0x2c,%esp
       3:	c7 44 24 1a 68 65 6c 	movl   $0x6c6c6568,0x1a(%esp)
       a:	6c 
       b:	66 c7 44 24 1e 6f 00 	movw   $0x6f,0x1e(%esp)
      12:	e8 55 00 00 00       	call   *** clrscreen   0x6c
      17:	8d 44 24 1a          	lea    0x1a(%esp),%eax
      1b:	89 04 24             	mov    %eax,(%esp)
      1e:	e8 0a 01 00 00       	call   *** kprint 0x12d
      23:	eb fe                	jmp    0x23

Can you see the bytes from offset 7 (0x68 0x65 0x6c 0x6c) ? That's 'h', 'e', 'l', 'l'. I don't know how you did that but it doesn't doesn't look normal. It's not normal.

Posted: **Mon Nov 22, 2010 7:40 am**

Code: Select all

const char hello[] = "hello";
kprint(&hello);

Oh I just noticed this. It's wrong. The first line is okay. But &hello is not the address of the string. It's the address of the entire array. You should say

Code: Select all

kprint(hello);

Make sure you have function prototypes for all your functions and that your code has no warnings before you run it.

And please, write an assembler stub to stick at address 0 that can call 'main' for you.

Posted: **Mon Nov 22, 2010 11:56 am**

i did all the things that you guys said (&hello to hello, assembler stub at the start), and still the same thing happed... what should i do?

bulid.rar - 5 character print (working)
build2.rar - 6 character print (crashing)

Posted: **Mon Nov 22, 2010 12:47 pm**

Please post your source code.

Posted: **Mon Nov 22, 2010 12:56 pm**

gerryg400 wrote:Please post your source code.

This is the source code...

Posted: **Mon Nov 22, 2010 1:42 pm**

usb2killer wrote:
gerryg400 wrote:Please post your source code.
This is the source code...

i just found out that the kernel is 9 sectors and im loading in the bootsector only 8...

its working!!!

Posted: **Mon Nov 22, 2010 3:14 pm**

Well done, but...

Are you sure you're setting the segment regs (es in particular) once you're in protected mode ? gcc assumes you have.

gcc also assumes the direction bit is clear. Have you done that ?

You haven't explicitly put the stub at the start of the .text segment. In fact you haven't actually defined any segments in stub.asm. And on your link command line you haven't listed stub.o as the first file. It works but that may be a fluke of the way nasm works. You need to check that.

OSDev.org

Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel

Re: Problems with kernel