As per his blog using linker script, the layout of the binary is such that the start routine is placed at 0x100000 address. The BIOS loads the bootloader to 0x7C00 and then loads the kernel at location 0x100000. Now a days, bootloader’s function no less than an OS. Without the kernel there is plain Bootloader, with whatever capabilities it can provide. BIOS will first check for bootable sectors using a magic number, and this is where another program, the bootloader must be present to load the kernel. The reset vector expects a firmware (BIOS) to be present which will load any software destined to run on the CPU. for x86 Processors this reset vector is 0xFFFFFFF0. configure - prefix=/opt/qemu - target-list=i386-softmmu - enable-debug - enable-kvm - enable-sdl - enable-gtkĬat trace-events-all | grep “(“ | grep -v “#” | cut -f 1 -d “(“ > /tmp/eventsĮvery Processor has an interrupt vector, which is an address that the EIP instruction pointer needs to execute upon power-on. I will write as much detail I can, starting from what I believe is the starting point of all of this complex handling. Ultimately we need to connect multiple parts for getting the big picture of the interrupt mechanism. I have tried to keep the blog post as coherent and linked as possible, but since we are dealing with interrupts, there maybe multiple paths involved as interrupts are asynchronous, and some digression is enforced.
With that piece working, I decided to explore how interrupts are triggered in the QEMU guest when I press a key on my integrated PS/2 keyboard.
I started with this post on writing a simple kernel with keyboard and text display, I am presuming it is based on the OSdev’s tutorial on the same topic. This is a post on exploring how interrupts work on VMs, like the one’s launched using the qemu-system* emulator.
0 kommentar(er)
