GRUB: RAW vs. any filesystem [fixed]

[Daevius]

Hi OSDev, I'm new

I've been reading a lot about the first steps for an OS to be designed. I've tried making my own bootloader with success, but I thought of using GRUB to take away some ASM pain (hurhur) and making the kernel dual-bootable.

So, I took GRUB...the binaries (unable to compile it in GCC on WinXP), loaded in stage1 (first 512 bytes) and stage2 (following space) to the floppy, adding some garbage of length 750, then my kernel, which would exactly be on offset 102400. I tried to run it through GRUB, but kept getting Error 13...it cannot recognize the executable format. Weird, since I do use the elf format as the tutorial(s) suggest. And I don't see why the multiboot part would not be in the binary...

So, according to many tutorials, I should "simply" copy the files to boot/grub/ and it'll be alright. Obviously, I'm missing a step. What filesystem to choose? And how to format the drive...through Windows? Then if we load the virtual floppy into Bochs...we never set the first 512 bytes, so how does it know how to boot? Are the first 512 bytes set when formatting the drive? Or should I write something that makes the drive use a certain filesystem.

Besides, there isn't any difference between a floppy and a harddrive, right? So if we want to test the kernel out at some point, I should just manage to copy it all to the HDD? So...I should make a kernel on a floppy, that copies all files of my actual kernel to the HDD, to install the OS, right?

Thanks!
Daevius

[Combuster]

What commands are you issuing to grub to boot the kernel?

Also, a harddisk has partitions whereas a floppy does not.

[Daevius]

kernel 200+5 <-- error
boot

My kernel is ~4.7 * 512 bytes in size, and at offset 200 * 512 bytes.

I concatenate stage1, stage2, 750 bytes of garbage and my kernel.bin to one file, and put that at offset 0 of the floppy drive.

[Creature]

Hi OSDev, I'm new

Welcome to the forums .

I tried to run it through GRUB, but kept getting Error 13...it cannot recognize the executable format. Weird, since I do use the elf format as the tutorial(s) suggest. And I don't see why the multiboot part would not be in the binary...

Are you sure the multiboot header (the assembly file with the multiboot header and GRUB stuff) is being linked as one of the first files in the executable (I believe it has to be somewhere up front and not to the back, but I don't know to what lengths GRUB will search the executable for it)?

So, according to many tutorials, I should "simply" copy the files to boot/grub/ and it'll be alright. Obviously, I'm missing a step. What filesystem to choose? And how to format the drive...through Windows? Then if we load the virtual floppy into Bochs...we never set the first 512 bytes, so how does it know how to boot? Are the first 512 bytes set when formatting the drive? Or should I write something that makes the drive use a certain filesystem.

The bootsector indeed isn't automatically set to what you probably want to do. There are a few options; you can either grab a floppy that already has the GRUB stage1 on the right spot on the floppy (sector 0, I believe), or you can put it on there yourself. If you've managed to write a bootloader before, you will probably know how to write your stage 1 bootloader to a floppy drive (if you don't, you can do it with several tools, such as dd and partcopy AFAIK).

Besides, there isn't any difference between a floppy and a harddrive, right? So if we want to test the kernel out at some point, I should just manage to copy it all to the HDD? So...I should make a kernel on a floppy, that copies all files of my actual kernel to the HDD, to install the OS, right?

Combuster stated the most important difference I think. If you want to test your kernel in GRUB, there are also several ways. Some people use a floppy image with GRUB and put their kernel binary on it. You can automate a lot of the process (compiling the files, putting the new kernel binary on the floppy, etc...). It is also possible to use a CDRom ISO to boot your OS from, or you can copy your OS (with some tools) directory to the hard drive, and boot from there. Most people start out with floppy drives, because they are fairly easy to work with, and move on to ISO's when they get too small.

I hope this was of some help to you.

[Daevius]

Yes, at the moment I copy my files using fdimage, an improvement of rawrite, since PartCopy didn't work for more then 7999 bytes. I've also automated the compile / copy / run procedure. This is how I compile and copy my files:

Code: Select all

nasm -f elf -o obj/start.o start.asm
ld -T link.ld -o bin/kernel.bin obj/start.o

"..\MergeFiles\bin\Release\MergeFiles" bin/boot.bin -fbin/stage1 -fbin/stage2 -g750 -fbin/kernel.bin
"F:\Program Files\PartCopy\fdimage" bin/boot.bin B:

MergeFiles is some small tool I wrote for this purpose. I take stage1 and stage2, glue them together, add 750 bytes of garbage and add the kernel.bin

start.asm has the multiboot header is right there:

Code: Select all

global start           ; making entry point visible to linker
;extern kmain            ; kmain is defined elsewhere

; setting up the Multiboot header - see GRUB docs for details
MODULEALIGN equ  1<<0                   ; align loaded modules on page boundaries
MEMINFO     equ  1<<1                   ; provide memory map
FLAGS       equ  MODULEALIGN | MEMINFO  ; this is the Multiboot 'flag' field
MAGIC       equ    0x1BADB002           ; 'magic number' lets bootloader find the header
CHECKSUM    equ -(MAGIC + FLAGS)        ; checksum required

section .text
align 4
MultiBootHeader:
   dd MAGIC
   dd FLAGS
   dd CHECKSUM

; reserve initial kernel stack space
STACKSIZE equ 0x4000                  ; that's 16k.

start:
   mov esp, stack+STACKSIZE           ; set up the stack
   push eax                           ; pass Multiboot magic number
   push ebx                           ; pass Multiboot info structure

   ;call  kmain                       ; call kernel proper

   cli
hang:
   hlt                                ; halt machine should kernel return
   jmp   hang

section .bss
align 32
stack:
   resb STACKSIZE                     ; reserve 16k stack on a quadword boundary

I compile to elf, and link it as the first and only object to a binary...I write it to offset 102400 till (102400 + 6010) = 108410 that is: kernel 200+12

Error 13: Invalid or unsupported executable format

[gravaera]

http://forum.osdev.org/viewtopic.php?p=164951#p164951

--All the best
gravaera

[Solar]

The GRUB Wiki page assumes an ext2fs formatted floppy. I'm sure we have some information on using GRUB on FAT formatted floppys, too, but I can't find it right now.

[Daevius]

Ha, got it fixed

It seems I was building a pei-i386 binary, according to objdump from the gcc toolchain. I downloaded the package from the wiki here: http://lowlevel.brainsware.org/wiki/ind ... Cr_Windows (it says, download the package, add the dir you extracted it to + \bin to your PATH, and prefix the tools with 'i586-elf-' like 'i586-elf-ld -T link.ld -o bin/kernel.bin obj/start.o').
'objdump -h' now says elf32-i386!

Version 0.96 of GRUB didn't work either, only 0.97 works.
Thanks guys

[Kevin]

Heh, I was already deliberating if I could post a link to our German language wiki for a Dutch original poster.

If you like to go for a file sytem (sooner or later you'll want to use one), there is an article about this too: http://lowlevel.brainsware.org/wiki/ind ... _(Windows).

[Creature]

Ha, got it fixed

It seems I was building a pei-i386 binary, according to objdump from the gcc toolchain. I downloaded the package from the wiki here: http://lowlevel.brainsware.org/wiki/ind ... Cr_Windows (it says, download the package, add the dir you extracted it to + \bin to your PATH, and prefix the tools with 'i586-elf-' like 'i586-elf-ld -T link.ld -o bin/kernel.bin obj/start.o').
'objdump -h' now says elf32-i386!

Version 0.96 of GRUB didn't work either, only 0.97 works.
Thanks guys

Well, if you were previously using a GCC that builds PE executables, and need a cross-compiler (that's what it's called) that builds ELF executables for you, you can always look at the wiki's GCC_Cross-Compiler article. Downloading one works too, of course, but it's always nice to know how to do it so you can build new versions early and such (or even patch GCC to your wishes).