cirosantilli/x86-bare-metal-examples
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Split up README

Browse Source
This commit is contained in:
Ciro Santilli
2015-09-14 16:51:29 +02:00
parent a8d90ac777
commit d217b180be
5 changed files with 106 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
README.md
View File

@@ -14,9 +14,14 @@ Hello world programs that run without an operating system.
1. [Multiboot](multiboot/) 1. [Multiboot](multiboot/)
1. TODO not working 1. TODO not working
1. [UEFI](uefi/) 1. [UEFI](uefi/)
1. [BIOS](bios.md) 1. Misc
1. Misc 1. [hajji](hajji/)
1. [hajji](hajji/) 1. Theory
1. [Formats](formats.md)
1. [MBR](mbr.md)
1. [IO](io.md)
1. [BIOS](bios.md)
1. [Bibliography](bibliography.md)
1. [TODO](TODO.md) 1. [TODO](TODO.md)
## Getting started ## Getting started
@@ -50,86 +55,3 @@ Then:
- choose to boot from the USB - choose to boot from the USB
Tested on: ThinkPad T400. Tested on: ThinkPad T400.
## Formats
When we create a regular Linux program, we generate an ELF file, which is read by the OS.
Without an OS, we can use the following formats:
- boot sector. TODO where is it specified, if at all? Wiki page describes MBR well enough: <https://en.wikipedia.org/wiki/Master_boot_record>
- multiboot. Defined by GRUB. More boilerplate, but much more convenient.
## Gotchas
- bytes 511 and 512 of the boot sector must be `0x55aa` or else the BIOS will refuse to load
- BIOS loads the program into memory at the address `0x7C00`.
We must tell that magic number to the linker somehow, either with a linker script, `-tText=-Ttext 0x7C00` or NASM `org 0x7c00`.
This will only matter when you access a memory address, because of relocation.
If you don't know what relocation is, first read this: <http://stackoverflow.com/questions/12122446/how-does-c-linking-work-in-practice/30507725#30507725>
When we link a normal program with an OS, the linker tells where it wants the OS to place it in virtual memory.
But for the boot sector, the BIOS puts the program into memory. So we must tell that to the linker somehow. Otherwise it cannot know what addresses to use for instructions.
- x86 processors start in 16-bit mode.
## IO
You cannot use any libraries, so how to do IO? Some ways that this can be done:
- BIOS functions: <http://wiki.osdev.org/BIOS>. Not well standardized like it's successor UEFI. Called through interrupts.
- <https://en.wikipedia.org/wiki/VGA-compatible_text_mode>
- VBE <https://en.wikipedia.org/wiki/VESA_BIOS_Extensions>
Showdown and restart can be managed with either:
- ACPI <https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface>
Newer and better.
Now managed by the same group that manages UEFI.
Spec:
- current: <http://uefi.org/specifications>
- old: <http://www.uefi.org/acpi/specs>
- APM <https://en.wikipedia.org/wiki/Advanced_Power_Management>
<http://wiki.osdev.org/APM>
Older and simpler.
By Microsoft in 1995. Spec seems to be in RTF format...
See also: <http://wiki.osdev.org/Shutdown>
## Bibliography
- <https://github.com/cirosantilli/assembly-cheat> Information about assembly in general.
- <http://stackoverflow.com/questions/22054578/run-a-program-without-an-operating-system>
- <https://github.com/programble/bare-metal-tetris> tested on Ubuntu 14.04. Just works.
Has Multiboot and El Torito. Uses custom linker script.
Almost entirely in C `-nostdlib`, with very few inline `asm` commands, and a small assembly entry point. So a good tutorial in how to do the bridge.
- osdev.org is a major source for this.
- <http://wiki.osdev.org/C%2B%2B_Bare_Bones>
- <http://wiki.osdev.org/Text_UI>
- <http://wiki.osdev.org/GUI>
- <https://github.com/scanlime/metalkit> A more automated / general bare metal compilation system. Untested, but looks promising.
The following did not work on my machine out of the box:
- <https://github.com/apparentlymart/ToyOS>
- <https://github.com/rde1024/toyos>

24
bibliography.md Normal file
View File

@@ -0,0 +1,24 @@
# Bibliography
- <https://github.com/cirosantilli/assembly-cheat> Information about assembly in general.
- <http://stackoverflow.com/questions/22054578/run-a-program-without-an-operating-system>
- <https://github.com/programble/bare-metal-tetris> tested on Ubuntu 14.04. Just works.
Has Multiboot and El Torito. Uses custom linker script.
Almost entirely in C `-nostdlib`, with very few inline `asm` commands, and a small assembly entry point. So a good tutorial in how to do the bridge.
- osdev.org is a major source for this.
- <http://wiki.osdev.org/C%2B%2B_Bare_Bones>
- <http://wiki.osdev.org/Text_UI>
- <http://wiki.osdev.org/GUI>
- <https://github.com/scanlime/metalkit> A more automated / general bare metal compilation system. Untested, but looks promising.
The following did not work on my machine out of the box:
- <https://github.com/apparentlymart/ToyOS>
- <https://github.com/rde1024/toyos>

19
formats.md Normal file
View File

@@ -0,0 +1,19 @@
# Formats
When we create a regular Linux program, we generate an ELF file, which is read by the OS.
Without an OS, we can use the following formats:
- boot sector, of which MBR is an important type.
- El Torito for CDs: <https://en.wikipedia.org/wiki/El_Torito_%28CD-ROM_standard%29>
- multiboot
- hybrid boot sector / El Torito. It is possible to generate images that can be burnt either to USBs or optic disks.
The Linux kernel 4.2 for example does that by default upon `make isoimage`.
- PXE: <https://en.wikipedia.org/wiki/Preboot_Execution_Environment> and its implementation <https://en.wikipedia.org/wiki/IPXE>
Boot from the network. TODO how does it work exactly? I suppose there is a server, and then the BIOS can download the boot sector from it.

30
io.md Normal file
View File

@@ -0,0 +1,30 @@
# IO
You cannot use any libraries, so how to do IO? Some ways that this can be done:
- BIOS functions: <http://wiki.osdev.org/BIOS>. Not well standardized like it's successor UEFI. Called through interrupts.
- <https://en.wikipedia.org/wiki/VGA-compatible_text_mode>
- VBE <https://en.wikipedia.org/wiki/VESA_BIOS_Extensions>
Showdown and restart can be managed with either:
- ACPI <https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface>
Newer and better.
Now managed by the same group that manages UEFI.
Spec:
- current: <http://uefi.org/specifications>
- old: <http://www.uefi.org/acpi/specs>
- APM <https://en.wikipedia.org/wiki/Advanced_Power_Management>
<http://wiki.osdev.org/APM>
Older and simpler.
By Microsoft in 1995. Spec seems to be in RTF format...
See also: <http://wiki.osdev.org/Shutdown>

25
mbr.md Normal file
View File

@@ -0,0 +1,25 @@
# MBR
A major type of boot sector.
Wiki page describes it well enough: <https://en.wikipedia.org/wiki/Master_boot_record>
TODO where is it specified, if at all?
## Gotchas
- bytes 511 and 512 of the boot sector must be `0x55aa` or else the BIOS will refuse to load
- BIOS loads the program into memory at the address `0x7C00`.
We must tell that magic number to the linker somehow, either with a linker script, `-tText=-Ttext 0x7C00` or NASM `org 0x7c00`.
This will only matter when you access a memory address, because of relocation.
If you don't know what relocation is, first read this: <http://stackoverflow.com/questions/12122446/how-does-c-linking-work-in-practice/30507725#30507725>
When we link a normal program with an OS, the linker tells where it wants the OS to place it in virtual memory.
But for the boot sector, the BIOS puts the program into memory. So we must tell that to the linker somehow. Otherwise it cannot know what addresses to use for instructions.
- x86 processors start in 16-bit mode.