[BITS 32] [global start] [extern _k_main] ; this is in the c file start: call _k_main cli ; stop interrupts hlt ; halt the CPU
porting first steps asm code to GNU
.global start [extern _k_main] ; _start: call _k_main cli ; hlt ;
$as --64 kernel_start.s kernel_start.s: Assembler messages: kernel_start.s:2: Error: junk at end of line, first unrecognized character is `[' $
linux 0.01 boot.s (copy from linux 0.01)
boot.s is loaded at 0x7c00 by the bios startup routines and moves itself out of the way to address 0x90000, and jumps there.It then loads the system at 0x10000, using BIOS interrupts. Thereafter it disables all interrupts,moves the system down to 0x0000 , changes to protected mode and calls the start of system. The system then should reinitialize the protected mode in it's own tables, and enables interrupts as needed.
boot.s (copy) 0.01 kernel size and paging
currently system is atmost 8*65536 bytes long. This should be no problem even in the future. I want to keep it simple.This 512 size kernel kB kernel size should be enough - infact more would mean we should have to move not just these startup routines, but also do something about the cache memory(block I/O devices.the area left over in the lower 640kB is meant for these.No oher memory is assumed to be "physical", ie all memory above 1Mb is demand paging. All addresses under 1Mb are guaranteed to match their physical addresses.
searching for call …
$grep -r setup *
boot/head.s: call setup_idt
boot/head.s: call setup_gdt
boot/head.s: mov %ax,%es # reloaded in 'setup_gdt'
boot/head.s: * setup_idt
boot/head.s:setup_idt:
boot/head.s: * setup_gdt
boot/head.s:setup_gdt:
boot/head.s: jmp setup_paging
boot/head.s:setup_paging:
include/linux/sys.h:extern int sys_setup();
include/linux/sys.h:fn_ptr sys_call_table[] = { sys_setup, sys_exit, sys_fork, sys_read,
include/unistd.h:#define __NR_setup 0 /* used only by init, to get system going */
init/main.c:static inline _syscall0(int,setup)
init/main.c: * Interrupts are still disabled. Do necessary setups, then
init/main.c: setup();
kernel/hd.c:int sys_setup(void)
IDT interrupt descriptor table
The Interrupt Descriptor Table (IDT) is an array of 8 byte interrupt descriptors in memory devoted to specifying (at most) 256 interrupt service routines. The first 32 entries are reserved for processor exceptions, and any 16 of the remaining entries can be used for hardware interrupts. The rest are available for software interrupts. source : http://www.acm.uiuc.edu/sigops/roll_your_own/i386/idt.html
LEA instruction
The lea instruction places the address specified by its second operand into the register specified by its first operand. Note, the contents ofthe memory location are not loaded, only the effective address is computed and placed into the register. This is useful for obtaining a pointer into a memory region. source: http://www.cs.virginia.edu/~evans/cs216/guides/x86.html
setup_idt …
Bochs
snippet 1
$apt-cache search bochs grub-firmware-qemu - GRUB firmware image for QEMU vgabios - VGA BIOS software for the Bochs and Qemu emulated VGA card bochs - IA-32 PC emulator bochs-doc - Bochs upstream documentation bochs-sdl - SDL plugin for Bochs bochs-svga - SVGA plugin for Bochs bochs-term - Terminal (ncurses-based) plugin for Bochs bochs-wx - WxWindows plugin for Bochs bochs-x - X11 plugin for Bochs bochsbios - BIOS for the Bochs emulator bximage - Disk Image Creation Tool for Bochs
snippet 2
Setting up libasound2 (1.0.24.1-2) ... Setting up libasound2-dev (1.0.24.1-2) ... Setting up lib32asound2 (1.0.24.1-2) ... Setting up libltdl7 (2.4-2) ... Setting up libltdl-dev (2.4-2) ... Setting up bochsbios (2.4.6-3) ... Setting up vgabios (0.6c-3) ... Setting up bximage (2.4.6-3) ... Setting up bochs-wx (2.4.6-3) ... Setting up bochs (2.4.6-3) ... Processing triggers for menu ... $
ELF spec. types of object files
A relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object file. An executable file holds a program suitable for execution; the file specifies how exec(BA_OS) creates a program's process image. A shared object file holds code and data suitable for linking in two contexts. First, the link editor [see ld(SD_CMD)] may process it with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file and other shared objects to create a process image. source : ELF Specification.