How develop a simple boot loader for linux kernel 3.0
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: RHEL, CentOS, Debian, Oracle Solaris 10
Assuming you're using nasm and you're on an x86 processor, here is an example of boot sector code to print "Hello World"
; helloworld.asm: print "Hello world" <strong class="highlight">to</strong> the screen and hang ;
mov si, msg ; Place message in si
call putstr ; Print the string
; hang: hang the machine indefinitely
; putstr: print <strong class="highlight">a</strong> string given in si <strong class="highlight">to</strong> the screen
pusha ; Push all registers
mov ah, 0eh ;
; putchar: print <strong class="highlight">a</strong> character from the string
lodsb ; Get <strong class="highlight">a</strong> character
cmp al, 0 ; Check <strong class="highlight">for</strong> null-terminator
je .return ; NULL found, stop
; Not NULL, print the character
popa ; Pop all registers
mov ax, 0
ret ; Return (0 in ax)
section .data ; This always goes at the end of the binary, so putting it at the
; end of the source file makes sense.
msg db 'Hello world', 13, 10, 0 ; The 13, 10, 0 refers <strong class="highlight">to</strong> '\r\n\0' in C/C++.
times 482-($-$$) db 0 ; Fill the binary until it's 512 bytes
dw 0xaa55 ; Boot signature stored as 0x55 0xaa in memory (little endian)
Now, for some reason times isn't working. Actually it should be:
Just out of curiosity, Satyaveer, did you write that yourself, or did you copy and paste from some webpage?
What I'm curious about myself, is that the kernel has to be read, off of a ext4 filesystem, and then JMPed to - how is this accomplished? IS IT IN ASM???!!!! Would LOVE to have a chat with the guy who wrote this!
There are lots of different types of bootloaders for lots of different architectures and situations.
In order to know how to provide any useful advice, one would have to know something about those specifics. My next question would be 'are you sure you need to do this?'. It sounds a lot like re-inventing a well rounded wheel.
There are two strategies regarding access to the filesystem by a bootloader. The issue is that the bootloader must either have drivers for the hardware and fileystem type built in at boot time (size and complexity), or the bootloader can know a priori where the blocks that store the relevant parts are located on the disk, and simply use low-level functions to get those blocks (smaller and simpler).
The first approach is what grub does. It is fully filesystem aware, and can fetch things from disk using filesystem descriptions (albeit, using its own syntax). The latter approach is what lilo does. At boot time, it just fetches a list of disk blocks, and doesn't know anything about filesystems. All of the work of locating the appropriate blocks is done while Linux is fully up and running, and has the benefit of a fully functioning host to support all of the difficult work. That is why any change to the boot configuration requires you to run lilo before rebooting.
The upshot of this is that you can use grub sources to see how a bootloader reads the filesystem. I've never looked, but I feel certain that it is a fairly complex bit of code. I doubt that much of it is written in assembler.