Wiki: Bare bones

[paxcoder]

Re: Bare_bones

I tried to assemble stuff from the above article, but it was no go:

Code: Select all

loader.s:21: Error: suffix or operands invalid for `push'
loader.s:22: Error: suffix or operands invalid for `push'

I understand it's because code is architecture specific (32 bit oriented, and I have 64 bit Athlon).
So: could anyone please write a more cross-platform "bare bones" (so it includes at least x86 64bits as well)?
I can't really start without it.

[AJ]

Hi,

The code works even on a CPU with 64 bit capabilities and should work if you are using GRUB legacy.

Unless you have explicitly switched to 64 bit mode, you need to use a 32 bit assembler (or your existing assembler outputting 32 bit code). If you really did intend to assemble 64 bit code (unlikely at this stage), try changing eax and ebx to rax and rbx.

Cheers,
Adam

[paxcoder]

Unless you have explicitly switched to 64 bit mode, you need to use a 32 bit assembler

Uhm... that's pretty low for me. I just want my C to start kicking in
Can you clarify it a bit for me? I'm using 64 bit processor in its 64 bit mode, and I have 64 bit assembler, I guess.
Are you saying I should start with 32 bit assembly, and if you do, how exactly do I do that (on a 64 bit machine), and, more importantly how can I switch later on?

Basically, I'd much rather pass all this asm, and go with C and occasional inline asm.
But I want it all to work on at least on those two x86 platforms. So if you can help, anything would be greatly appreciated.

[AJ]

Hi,

Can you clarify it a bit for me? I'm using 64 bit processor in its 64 bit mode, and I have 64 bit assembler, I guess.

Even a 64 bit processor starts in 16 bit (real) mode. Because you are using GRUB, you get a switch to 32 bit (protected) mode for free. That is the point you are at when 'loader.s' kicks in. If you want to use GRUB and have a 64 bit kernel, you need to switch to 64 bit (long) mode. Good news! You can do most of this in C - just follow the bare bones in 32 bit mode and write the C code to switch to long mode.

Alternative: Use a boot loader that switches to 64 bit mode for you like GRUB 2 (not yet very far on), Pure64 (a name I have seen around the forums recently - one of our members has created it) or write one yourself. I am working on such a boot loader myself (which includes support for jumping straight in to a main() routine), but it is nowhere near production quality yet.

Cheers,
Adam

[paxcoder]

Thanks. WIll look into it.
For now, seems like for utilizing 64 bit benefits, you need a rewrite after all.

[AJ]

Hi,

I just found this on the wiki: Creating_a_64-bit_kernel.

HTH,
Adam

[paxcoder]

Yeah, that looks even more complicated.
Plus it's incompatible as well, just the other way....
(-_- ) ahhh... nevermind, I'll think of something.

[Combuster]

That's because 64-bit mode is essentially different from 32-bit mode. They will always need different code

[paxcoder]

That's because 64-bit mode is essentially different from 32-bit mode. They will always need different code

I always thought porting (of applications, for example) boiled down to recompiling, but I guess there's a lot more reorganizing (and, I realize now, rewriting!) to it...

[Combuster]

For well-written applications, yes. Because there is a platform-dependent kernel that abstracts away the differences, and some platform dependent system call stuff that is implicitly linked with your "portable" code.

[Solar]

I always thought porting (of applications, for example) boiled down to recompiling...

For code that uses nothing but the standard library of a language, that is true for every platform supporting that language.

Code: Select all

#include <stdio.h>

int main()
{
    puts( "Hello world!" );
    return 0;
}

This will run (virtually) everywhere with a simple recompile, because the differences in platforms are hidden away behind the "#include <stdio.h>". It has a well-defined interface towards the application, which guarantees that puts() (or printf() etc.) always do the same on all platforms.

However, when you're doing kernel-space programming, you are on the other side of that well-defined interface. Your job is to take whatever the platform does for printing text - int 0x10, writing to 0xb8000, graphics output - and provide a way for puts() to print its line. You have to support a standard library before you can enjoy its benefits...

Especially in the early phases of system setup, which the "Baby Steps" and "Bare Bones" tutorials are about, are very much platform dependent, and there's next to nothing you could do about it.

[paxcoder]

I always thought porting (of applications, for example) boiled down to recompiling...

For code that uses nothing but the standard library of a language, that is true for every platform supporting that language.

So compiler is responsible for utilizing the 64 bits.
But yeah, most ASM parts (and that includes drivers) are to be rewritten, are they not?

[yakahughes]

Hey guys,
I am trying to follow the tutorial, but when I get to this part where I build the floppy image, I type:

Code: Select all

cat  stage1 stage2 pad kernel.bin > floppy.img

which works fine, and when I do the

Code: Select all

copy stage1+stage2+pad+kernel.bin floppy.img

it says

Code: Select all

bash: copy: command not found

so then I try cp instead of copy, but it says

Code: Select all

cp: cannot stat `stage1+stage2+pad+kernel.bin': No such file or directory

so I tried putting spaced between the plus signs and the stage1, stage2, etc. and then it says

Code: Select all

cp: target `floppy.img' is not a directory

Which effectively halts my progress through the tutorial. Could anyone help me? I am using Ubuntu linux btw.

[Brynet-Inc]

Hey guys,
I am trying to follow the tutorial, but when I get to this part where I build the floppy image, I type:

Code: Select all

cat  stage1 stage2 pad kernel.bin > floppy.img

which works fine, and when I do the

Code: Select all

copy stage1+stage2+pad+kernel.bin floppy.img

Are you seriously unable to recognize your error? both of the above commands do the same thing under different operating systems.. due to the fact you admitted to using Linux, only the first one applies.

The problem? your ability to comprehend basic instructions is severely impaired..

[yakahughes]

Ok, so that was what the comments were at the end of the lines.

Now when I type bochs, I get this:

Code: Select all

00000000000i[APIC?] local apic in  initializing
========================================================================
                       Bochs x86 Emulator 2.3.6
             Build from CVS snapshot, on December 24, 2007
========================================================================
00000000000i[     ] LTDL_LIBRARY_PATH not set. using compile time default '/usr/lib/bochs/plugins'
00000000000i[     ] BXSHARE not set. using compile time default '/usr/share/bochs'
00000000000i[     ] reading configuration from bochsrc.txt
00000000000i[     ] lt_dlhandle is (nil)
00000000000p[     ] >>PANIC<< dlopen failed for module 'x': file not found
========================================================================
Event type: PANIC
Device: [     ]
Message: dlopen failed for module 'x': file not found

A PANIC has occurred.  Do you want to:
  cont       - continue execution
  alwayscont - continue execution, and don't ask again.
               This affects only PANIC events from device [     ]
  die        - stop execution now
  abort      - dump core 
  debug      - hand control to gdb
Choose one of the actions above: [die]