I'm currently reading the boot.s
file in the source for the first ever Linux kernel (assuming that 0.01 is indeed the first public release).
I know C and ASM, the latter considerably less than the former. Even so, I seem to be able to understand and essentially grasp the code in the source files.
This file has me confused though. I now realise that's because it's in real mode, not protected mode. Needless to say, I've never seen ASM code written in real mode before. Protected mode was the defacto mode x86 OSes ran on before I was even born, so it's to be expected.
Here's a routine I want to comprehend better:
/*
* This procedure turns off the floppy drive motor, so
* that we enter the kernel in a known state, and
* don't have to worry about it later.
*/
kill_motor:
push dx
mov dx,#0x3f2
mov al,#0
outb
pop dx
ret
Looking up outb
, I find it's used to pass bytes to ports on the computer. I'll hazard a guess based on C documentation that this scenario passes the 'stop motor' byte as the first argument, and as the floppy drive port number as the second.
Is this interface provided by the BIOS? Or by the floppy drive directly? I'm assuming the BIOS has frugal 'drivers' for very basic operation of all the fundamental devices.
Here's where I'm stumped: it seems that numbers like #0x3f2
are being pulled out of thin air. They're clearly hardware port numbers or something. This file is sprinkled with such numbers, with no explanation what they're referring to. Where can I find a comprehensive reference that shows all the hardware ports and control numbers they can receive from real mode? Also, it seems the file moves the kernel around in memory throughout the booting processes, with hard-coded memory addresses. Where can I find a guide for what memory address ranges are available to write over during real mode?
I also read a comment by Linus about reprogramming interrupts to avoid a collision between the BIOS and internal hardware interrupts. I'm not going to lie, that went right over my head.
Help would be great; Google seems sparse on the topic, in case you're wondering.