OSDev.org

Brendan wrote:

Solar wrote:Can we try and cut the discussion short this time?

All I'm saying is that people should design their OS and then decide if GRUB is suitable, rather than deciding to use GRUB and then making their OS suit it....

I totally agree. I just hate it when people blindly copy code from tutorials and ask us what is wrong because they did not follow it correctly. I believe that you have to understand what you are writing to say that it is yours. If you know what GRUB is does and know how it does it then I say use it.

As for OS design, the bootloader is the a very inportant part of the design. Without it the OS would not boot.

asmboozer wrote:

Also, does your kernel handle parameters? You could probably just use "kernel /bkern".

no parameters
the main() prototype is void main()

NO.

The main prototype is either int main() or int main(int argc, char **argv). The names of the arguments can be changed, but it's confusing to all the rest, yet you can not change the rest! Look in the C standard (ISO 9899:1999).

NO.

The main prototype is either int main() or int main(int argc, char **argv). The names of the arguments can be changed, but it's confusing to all the rest, yet you can not change the rest! Look in the C standard (ISO 9899:1999).

I know that, even main with the third parameter char* envp[],

but that's the codes from the tutorial

Candy wrote: NO.

The main prototype is either int main() or int main(int argc, char **argv). The names of the arguments can be changed, but it's confusing to all the rest, yet you can not change the rest! Look in the C standard (ISO 9899:1999).

Hmm, I seem to remember that that's only for a hosted environment, and it can be anything for a freestanding environment (which is what a kernel should use) (since main has no special meaning there).

Could be wrong though, and I can't remember where I read that. And I can't be bothered to check the standard

EDIT: the standard only mentions main at all in the context of a hosted environment. ISTR that gcc doesn't complain about the type of main when -ffreestanding is given.

I'm a firm believer, as are many other people here, that if you use an identifier which is part of the standard (such as main) then it should be declared/defined exactly as the standard to avoid this sort of confusion. 'main' really seems to be the worst, with huge misunderstandings of hosted vs. freestanding environments, such as:

Quote:
Also, does your kernel handle parameters? You could probably just use "kernel /bkern".
no parameters
the main() prototype is void main()

The point of a kernel taking parameters or not has nothing to do with the prototype for main, and this confusion is caused by using a standard name for a non-standard function.

So my kernel 'main' function is called kmain.

I'll shut up preaching now...

Exactly, if you're going to use a standard name for something then to avoid future confusion it would be best to use it exactly how it would be used in other circumstances. If you want your entry point to use different parameters and stuff then don't call it main().

I can not work right with the tutorial.

don't know why.

i think the difference between the author and me is that I use vmware and linux binutils, not the cygwin, djcpp?

and the link.ld file is modified by adding *(.rodata*) after *(.text)

a priori, it should work equally well with linux and cygwin tools. Maybe you could want to try it in another virtual machine and track what's going wrong. Bochs and its internal debugger may be very valuable here.

... or maybe QEMU and its GDBserver settings ...

Pype.Clicker wrote: a priori, it should work equally well with linux and cygwin tools. Maybe you could want to try it in another virtual machine and track what's going wrong. Bochs and its internal debugger may be very valuable here.

if i use bochs,
1) i have to build a internal-debugger-supported build bochs ,
2) and I have to make a image combined with grub and the kernel.

i have no experience with the 2 question, the first question i think i have to cvs the source code first.
the second, as far as i know, all the tutorial only said how to make a grub kerenl with floppy disk, but i have no floppy disk at hand. so i want to know how to make grub kernel file?

thanks.

BTW, after my gcc build the object file, i dump the symbol, there is no underscore before the symbol. i used the compile flag/option as the tutuorial said.

... or maybe QEMU and its GDBserver settings ...

don't know how to play with them either.

okay, take the time to consider the options before you complain on the board, right ?

Grab a source release of bochs (keep CVS snapshot for later), look at the flags of "./configure --help" and the be patient while "make" runs ... Bochs configures and compiles just like 80% of unix software.

Placing GRUB and your kernel together on the disk is independent on the machine you use, isn't it ? once you have a developer-friendly emulator, you can set a breakpoint at 0x7C00 or at 1MB and trace execution from there... to me, that's way more friendly than bare hardware or VMWare/VirtualPC for investigating problems ...
may help too ... (if you have a debian-based stuff, of course). See the "working with diskimages" page of the FAQ to see how you could manipulate it (or the mtools manpage)

Pype.Clicker wrote: Placing GRUB and your kernel together on the disk

first sorry for too many botherings.

Clicker, would you be kind to tell me how to place GRUB and a kernel together(make the 2 into a grub_dev_kernel.bin)?

I have no floppy disk. can I generate a grub_dev_kernel.bin in such a situation?

another question, if i write my own loader, would I have to tell the ld file the start kernel address? since my loader itself knows the address because I know it.

thanks.

asmboozer wrote: another question, if i write my own loader, would I have to tell the ld file the start kernel address? since my loader itself knows the address because I know it.

Providing that you're not doing anything fancy, you will still need to put the start address in the linker script so that your kernel itself accesses the right memory locations.

However, with your own bootloader, you will not need to put that address into a header in your kernel.

Hope this helps

asmboozer wrote:
Clicker, would you be kind to tell me how to place GRUB and a kernel together(make the 2 into a grub_dev_kernel.bin)?

I have no floppy disk. can I generate a grub_dev_kernel.bin in such a situation?

Yeah, sure. I even took notes of how to do it when i faced the same problem ... There are other alternatives such as loop devices, but for that purpose, mtools seems the easiest to use.

another question, if i write my own loader, would I have to tell the ld file the start kernel address?

Yes. Generally speaking, it's preferable to have the kernel state its load address and have the loader try to comply rather than loading "where you can" and then instructing the loaded kernel that "you're here".

Either you can compile your bootloader with the same parameters as the kernel (e.g. KERN_LOAD_ADDR defined or whatever) or you can have the load address written ahead of the kernel binary (e.g. arrange a "KERNLOADADDRxxxx" magic sequence or something looking more like multiboot header)

If the loader doesn't find the appropriate magic sequence in the kernel, it will complain and halt.

Pype.Clicker wrote: Yeah, sure. I even took notes of how to do it when i faced the same problem ... There are other alternatives such as loop devices, but for that purpose, mtools seems the easiest to use.

Clicker, what's the -i option for mcoy?
when I man mcopy under Fedora 5,
it gives the info,
mcopy(1) mcopy(1)

Name
mcopy - copy MSDOS files to/from Unix

Note of warning
This manpage has been automatically generated from mtools's texinfo documentation, and may not be entirely
accurate or complete. See the end of this man page for details.

Description
The mcopy command is used to copy MS-DOS files to and from Unix. It uses the following syntax:

mcopy [-bspanvmQT] [-D clash_option] sourcefile targetfile
mcopy [-bspanvmQT] [-D clash_option] sourcefile [ sourcefiles... ] targetdirectory
mcopy [-tnvm] MSDOSsourcefile

no -i option supported .

can you explain the usage in your example?

C32/> cp grub_image.img disk.img
C32/> mcopy -i disk.img kernel/kernel.kof ::
C32/> mcopy -i disk.img kernel/ramdisk.sfs ::



thanks.

the "-i" is for "here's the image file i want you to work with". i admit i don't know if it's widely supported or not. my manpage doesn't document it either and i couldn't tell you where i first heard of it. It works here, that all i can tell.

the "::" is just like you had "C:" or "D:" except it means "volume letter ':' is the file given by '-i <file>'" ...