./configure
make

./run

./run bios_hello_world
./run bios_putc

./run min
./run min.
./run min.S
./run min.img

./run bios_hello_world bochs

c

Insert an USB, determine its device (/dev/sdX) with:

Pick the .img file that you wan to run and:

Then:

• insert the USB in a computer

• during boot, hit some special hardware dependant key, usually F12, Esc

• choose to boot from the USB

When you are done, just hit the power button to shutdown.

For example, on my T430 I see the following.

After turning on, this is when I have to press Enter to enter the boot menu:

Then, here I have to press F12 to select the USB as the boot device:

From there, I can select the USB as the boot device like this:

Alternatively, to change the boot order and choose the USB to have higher precedence so I don’t have to manually select it every time, I would hit F1 on the "Startup Interrupt Menu" screen, and then navigate to:

See also: Test hardware

2.1.1. Getting started with the big image

make big.img

sudo dd if=big.img of=/dev/sdX

qemu-system-i386 -hda big.img

If you don’t have an Ubuntu box, this is an easy alternative, for the first run:

and the following runs:

and to nuke the container later on:

Then proceed normally in the guest: install packages, and build:

To overcome the lack of GUI, we can use QEMU’s VNC implementation instead of the default SDL, which is visible on the host due to --net=host:

and then on host:

TODO: get sound working from docker: PC speaker: https://stackoverflow.com/questions/41083436/how-to-play-sound-in-a-docker-container

It should also be possible to run a GUI inside the container, but I haven’t tested: https://stackoverflow.com/questions/40658095/how-to-open-ubuntu-gui-inside-a-docker-image/57636624#57636624

To GDB step debug the program, run it with:

This will leave you at the very first instruction executed by our program, which is the beginning of our BEGIN macro.

Note however that this is not the very first instruction QEMU executes: that will actually be BIOS setup code that runs before our program itself.

You can then basically debug as you would a normal userland program, notably:

• I then highly recommend that you use GDB Dashboard to see what is going on.

• n skips over macros

• ni steps within macros. But you will need to enable the printing of assembly code on GDB Dashboard to see where you are at

With this God-like GDB Dashboard setup, at 89cbe7be83f164927caebc9334bc42990e499cb1 I see a perfect program view such as:

Debug symbols are obtained by first linking ELF files, and then using objcopy on them to generate the final image. We then pass the ELF files with the debug information to GDB: https://stackoverflow.com/questions/32955887/how-to-disassemble-16-bit-x86-boot-sector-code-in-gdb-with-x-i-pc-it-gets-tr/32960272#32960272

How to step over int calls: http://stackoverflow.com/questions/24491516/how-to-step-over-interrupt-calls-when-debugging-a-bootloader-bios-with-gdb-and-q

Single stepping until a given opcode can be helpful sometimes: https://stackoverflow.com/questions/14031930/break-on-instruction-with-specific-opcode-in-gdb/31249378#31249378

TODO: detect if we are on 16 or 32 bit automatically from control registers. Now I’m using 2 functions 16 and 32 to switch manually, but that sucks. The problem is that it’s not possible to read them directly: http://stackoverflow.com/a/31340294/895245 If we had cr0, it would be easy to do with an if cr0 & 1 inside a hook-stop.

TODO: Take segmentation offsets into account: http://stackoverflow.com/questions/10354063/how-to-use-a-logical-address-in-gdb

Outcome: QEMU window opens up, prints a few boot messages, and hangs.

Our program itself does not print anything to the screen itself, just makes the CPU halt.

This example is generated with printf byte by byte: you can’t get more minimal than this!

It basically consists of:

• byte 0: a hlt instruction

• bytes 1 through 509: zeroes, could be anything

• bytes 510 and 511: mandatory magic bytes 0xAA55, which are required for BIOS to consider our disk.

Minimal example that just halts the CPU without using our mini-library common.h:

Source: min.S

Outcome: QEMU window opens up, prints a few firmware messages, and hangs.

Here is an equivalent example using our mini-library:

Source: template.S

You can use that file as a quick template to start new tests.

3.2.1. Infinite loop

./run infinite_loop

3.2.2. Linker script

Print hello world after the firmware messages:

Source: bios_hello_world.S

3.3.1. C hello world

cd c_hello_world
./run

objdump -D -m i8086 main.elf

00007c17 <main>:
    7c17:       66 55                   push   %ebp
    7c19:       66 89 e5                mov    %esp,%ebp
    7c1c:       66 83 ec 10             sub    $0x10,%esp

Print hello world without using an explicit linker script:

Sources:

• no-linker-script/Makefile

• no-linker-script/main.S

Uses the default host ld script, not an explicit one set with -T. Uses:

• -tText

• .org inside each assembly file

• _start must be present to avoid a warning, since the default linker script expects it

This is a hack, it can be more convenient for quick and dirty tests, but just don’t use it.

mov <function-id>, %ah
int <interrupt-id>

10h

Does any official documentation or standardization exist?

• https://en.wikipedia.org/wiki/BIOS_interrupt_call#Interrupt_table

• http://www.ctyme.com/intr/int.htm Ralf Brown’s Interrupt List. Everyone says that this is the ultimate unofficial compilation.

• https://en.wikipedia.org/wiki/INT_10H good quick summary

• http://www.scs.stanford.edu/nyu/04fa/lab/specsbbs101.pdf says little about interrupts, I don’t understand it’s scope.

Print a single @ character:

Source: bios_putc.S

Print a newline:

Source: bios_newline.S

Outcome:

Carriage returns are needed just like in old days:

Source: bios_carriage_return.S

Outcome:

Change the current cursor position:

Source: bios_cursor_position.S

Outcome:

4.2.1. BIOS color

./run bios_color

bcd

./run bios_background

4.2.2. BIOS scroll

./run bios_scroll

a
  c
 GG
   d

a
 b
  c
   d

a
 XX
 YY
   d

./run bios_clear_screen

b

4.2.3. BIOS draw pixel

./run bios_pixel

./run bios_pixel_line

4.2.4. BIOS keyboard

./run bios_keyboard

./run bios_keyboard_loop

4.2.5. BIOS disk load

./run bios_disk_load

a

./run bios_disk_load2

ab

4.2.6. BIOS detect memory

./run bios_detect_memory

4.2.7. BIOS sleep

./run bios_sleep

4.2.8. BIOS initial state

./run bios_initial_state

ax = 00 00
bx = 00 00
cx = 00 00
dx = 80 00
cs = 00 00
ds = 00 00
es = 00 00
fs = 00 00
gs = 00 00
ss = 00 00
cr0 = 53 FF 00 F0

Get BIOS information. On host:

Standardized by: https://en.wikipedia.org/wiki/Distributed_Management_Task_Force

TODO: how is it obtained at the low level?

Bibliography:

• http://stackoverflow.com/questions/20604644/how-to-check-the-bios-version-or-name-in-linux-through-command-prompt

• https://en.wikipedia.org/wiki/System_Management_BIOS SMBIOS

http://www.seabios.org/SeaBIOS

Open source x86 BIOS implementation.

Default BIOS for QEMU and KVM.

Source: no_bios_hello_world.S

Outcome:

with red foreground and blue background shows on the top left of the cleared screen.

This example uses the fact that BIOS maps video memory to address 0xB8000.

We can then move 0xB800 to a segment register and use segment:offset addressing to access this memory.

Then we can show characters by treating 0xB800:0000 as a uint16_t array, where low 8 bytes is the ASCII character, and the high 8 bytes is the color attribute of this character.

(all modes)
|
| Reset
|
v
+---------------------+
| Real address (PE=0) |
+---------------------+
^
|
| PE
|
v
+------------------------+
| Protected (PE=1, VM=0) |
+------------------------+
^                   ^
|                   |
|                   | VM
|                   |
v                   v
+--------------+    +---------------------+
| IA-32e       |    | Virtual-8086 (VM=1) |
+--------------+    +---------------------+

+------------------------+
| System management mode |
+------------------------+
|          ^
|          |
| RSM      | SMI#
|          |
v          |
(All other modes)

The term defined in the Intel manual Volume 3 - CHAPTER 2 "SYSTEM ARCHITECTURE OVERVIEW":

Real mode, protected mode, virtual 8086 mode, and system management mode. These are sometimes referred to as legacy modes.

In other words: anything except IA-32e and System management mode.

This further suggests that real, protected and virtual mode are not the main intended modes of operation.

http://wiki.osdev.org/Real_Mode

The CPU starts in this mode after power up.

All our BIOS examples are in real mode.

It is possible to use 32-bit registers in this mode with the "Operand Size Override Prefix" 0x66.

TODO is it possible to access memory above 1M like this:

http://stackoverflow.com/questions/6917503/is-it-possible-to-use-32-bits-registers-instructions-in-real-mode

6.2.1. Real mode segmentation

./run real_segmentation

AAAAAA

<segment> * 16 + <original-address>

./run cs

00
01
02

./run ss

0102

objdump -D -b binary -m i8086 segment_registers.img

20:   a0 63 7c                mov    0x7c63,%al
34:   26 a0 63 7c             mov    %es:0x7c63,%al
40:   64 a0 63 7c             mov    %fs:0x7c63,%al
4c:   65 a0 63 7c             mov    %gs:0x7c63,%al
58:   36 a0 63 7c             mov    %ss:0x7c63,%al

6.2.2. Interrupts

./run interrupt

ab

./run interrupt1

./run interrupt_loop

Trying to execute code outside RAM or ROM at 0x000a0000

./run interrupt_zero_divide

IDTR -> +-----------------------+
0       |Address      (2 bytes) |
2       |Code segment (2 bytes) |
        +-----------------------+
        +-----------------------+
4 ----> |Address      (2 bytes) |
6       |Code segment (2 bytes) |
        +-----------------------+
        +-----------------------+
8 ----> |Address      (2 bytes) |
A       |Code segment (2 bytes) |
        +-----------------------+

...     ...

./run lidt
./run lidt2
./run lidt0

ab

Print hello world in protected mode:

Source: protected_mode.S

Major changes from real mode:

• VGA must be used for output since BIOS is not available in protected mode.

• segmentation takes effect immediately, so we have to set the GDT up

• we have to encode instructions differently, thus a .code32 is needed. 16-bit mode 32-bit instructions are encodable with a special prefix.

Bibliography:

• http://stackoverflow.com/questions/28645439/how-do-i-enter-32-bit-protected-mode-in-nasm-assembly Initially adapted from this.

• http://wiki.osdev.org/Journey_To_The_Protected_Land

• http://wiki.osdev.org/Protected_Mode

• https://github.com/chrisdew/xv6/blob/master/bootasm.S

• https://thiscouldbebetter.wordpress.com/2011/03/17/entering-protected-mode-from-assembly/ FASM based. Did not word on first try, but looks real clean.

• http://skelix.net/skelixos/tutorial02_en.html

• Linux kernel v4.12 arch/x86/include/asm/segment.h

6.3.1. Intel protected mode example

6.3.2. Protected mode draw pixel

6.3.3. Protected mode segmentation

./run segmentation

x
a
b

x
a

+-----------+--------+--------------------------+
| Program 1 | Unused | Program 2                |
+-----------+--------+--------------------------+
^           ^        ^                          ^
|           |        |                          |
Start1      End1     Start2                     End2

6.3.4. IDT

./run idt

int 0 handled

./run idt1

int 1 handled

./run pit_protected

./run idt_zero_divide

division by zero handled

6.3.5. SMP

./run smp

SMP started

6.3.6. Paging

./run paging

00001234
00005678

./run page_fault

Page fault handled. Error code:
00000002

Wikipedia seems to call it long mode: https://en.wikipedia.org/wiki/Long_mode

Contains two sub-modes: 64-bit mode and Compatibility mode.

This controlled by the CS.L bit of the segment descriptor.

It appears that it is possible for user programs to modify that during execution from userland: http://stackoverflow.com/questions/12716419/can-you-enter-x64-32-bit-long-compatibility-sub-mode-outside-of-kernel-mode

TODO vs Protected mode.

64-bit is the major mode of operation, and enables the full 64 bit instructions.

There are currently no examples in this repo because I was lazy to make them.

As someone once brilliantly put it: https://twitter.com/garybernhardt/status/1106255947138125824

Watching an x86-64 CPU boot is like watching an amoeba slowly evolve into a dog.

The backward compatibility of x86 is mind boggling.

Compatibility mode emulates IA-32 and allows to run 32 and 16 bit code.

But 64 bit Linux and Windows don’t seem to allow 16 bit code anymore?

• http://stackoverflow.com/questions/27868394/switch-from-64-bit-long-mode-to-32-bit-compatibility-mode-on-x64

• https://stackoverflow.com/questions/7829058/how-to-run-16-bit-code-on-32-bit-linux

• https://superuser.com/questions/140953/why-cant-a-64-bit-os-run-a-16-bit-application

Compatibility vs protected: https://stackoverflow.com/questions/20848412/modes-of-intel-64-cpu

man inb
man outb

Not all instruction sets have dedicated instructions such as in and out for IO.

In ARM for example, everything is done by writing to magic memory addresses.

The dedicated in and out approach is called "port mapped IO", and the approach of the magic addresses "memory mapp"

From an interface point of view, I feel that memory mapped is more elegant: port IO simply creates a second addresses space.

TODO: are there performance considerations when designing CPUs?

Bibliography: http://superuser.com/questions/703695/difference-between-port-mapped-and-memory-mapped-access

Whenever you press a key down or up, the keyboard hex scancode is printed to the screen:

Source: ps2_keyboard.S

Uses the PS/2 keyboard controller on in 60h: http://wiki.osdev.org/%228042%22_PS/2_Controller

The in always returns immediately with the last keyboard keycode: we then just poll for changes and print only the changes.

Scancode tables: TODO: official specs?

• https://en.wikipedia.org/wiki/Scancode#PC_compatibles

• http://flint.cs.yale.edu/cs422/doc/art-of-asm/pdf/APNDXC.PDF

TODO do this with the interrupt table instead of in. Failed attempt at: interrupt_keyboard.S

TODO create an example:

• http://wiki.osdev.org/Mouse_Input

• Random threads with source code, ah those OS devs:

  • https://forum.osdev.org/viewtopic.php?t=10247

  • https://forum.osdev.org/viewtopic.php?t=24277

• https://courses.engr.illinois.edu/ece390/books/labmanual/io-devices-mouse.html

I am so going to make a pixel drawing program with this.

Real Time Clock: https://en.wikipedia.org/wiki/Real-time_clock

Get wall time with precision of seconds every second:

Source: rtc.S

Sample outcome:

which means:

3rd April 2010, 02 hours 01 minute and 00 seconds.

Uses out 70h and in 71h to query the hardware.

This hardware must therefore use a separate battery to keep going when we turn off the computer or remove the laptop battery.

We can control the initial value in QEMU with the option:

The RTC cannot give accuracy greater than seconds. For that, consider the PIT, or the HPET.

Bibliography:

• http://wiki.osdev.org/RTC

• http://wiki.osdev.org/CMOS

• http://stackoverflow.com/questions/1465927/how-can-i-access-system-time-using-nasm

• https://github.com/torvalds/linux/blob/v4.2/arch/x86/kernel/rtc.c#L121

Programmable Interval Timer: https://en.wikipedia.org/wiki/Programmable_interval_timer

Superseded by the HPET.

Print a\n with the minimal frequency possible of 0x1234DD / 0xFFFF = 18.2 Hz:

Source: pit.S

Make the PIT generate a single interrupt instead of a frequency:

Source: pit_once.S

Outcome:

TODO I think this counts down from the value value in channel 0, and therefore allows to schedule a single event in the future.

The PIT can generate periodic interrupts (or sound!) with a given frequency to IRQ0, which on real mode maps to interrupt 8 by default.

Major application: interrupt the running process to allow the OS to schedule processes.

The PIT 3 channels that can generate 3 independent signals

• channel 0 at port 40h: generates interrupts

• channel 1 at port 41h: not to be used for some reason

• channel 2 at port 42h: linked to the speaker to generate sounds

Port 43h is used to control signal properties except frequency, which goes in the channel ports, for the 3 channels.

Bibliography:

• http://wiki.osdev.org/PIT

• https://en.wikipedia.org/wiki/Intel_8253 that is the circuit ID for the PIT.

• http://kernelx.weebly.com/programmable-interval-timer.html

7.5.1. PIT frequency

7.5.2. HPET

7.5.3. PC speaker

./run pc_speaker

-soundhw pcspk

https://en.wikipedia.org/wiki/Mode_13h

Example at: BIOS draw pixel

Video Mode 13h has: 320 x 200 Graphics, 256 colors, 1 page.

The color encoding is just an arbitrary palette that fits 1 byte, it is not split colors like R R R G G G B B or anything mentioned at: https://en.wikipedia.org/wiki/8-bit_color. Related: http://stackoverflow.com/questions/14233437/convert-normal-256-color-to-mode-13h-version-color

• https://en.wikipedia.org/wiki/Video_Graphics_Array

• https://en.wikipedia.org/wiki/VGA-compatible_text_mode

TODO: what is it exactly?

BIOS cannot be used when we move into Protected mode, but we can use the VGA interface to get output out of our programs.

Have a look at the macros prefixed with VGA_ inside common.h.

Infinite reboot loop on emulator!

Source: reboot.S

TODO why does it work?

Bibliography: http://stackoverflow.com/questions/32682152/how-to-reboot-in-x86-assembly-from-16-bit-real-mode

Turn on and immediately shutdown the system closing QEMU:

Source: apm_shutdown.S

Fancier version copied from http://wiki.osdev.org/APM (TODO why is that better):

Source: apm_shutdown2.S

Older than ACPI and simpler.

By Microsoft in 1995. Spec seems to be in RTF format…​

Can’t find the URL. A Google cache: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAAahUKEwj7qpLN_4XIAhWCVxoKHa_nAxY&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F1%2F6%2F1%2F161ba512-40e2-4cc9-843a-923143f3456c%2FAPMV12.rtf&usg=AFQjCNHoCx8gHv-w08Dn_Aoy6Q3K3DLWRg&sig2=D_66xvI7Y2n1cvyB8d2Mmg

Bibliography:

• https://en.wikipedia.org/wiki/Advanced_Power_Management

• http://wiki.osdev.org/APM

• http://wiki.osdev.org/Shutdown

• http://stackoverflow.com/questions/21463908/x86-instructions-to-power-off-computer-in-real-mode

• http://stackoverflow.com/questions/678458/shutdown-the-computer-using-assembly

• http://stackoverflow.com/questions/3145569/how-to-power-down-the-computer-from-a-freestanding-environment

TODO example

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

TODO get a hello world program working:

• http://www.rodsbooks.com/efi-programming/hello.html Best source so far: allowed me to compile the hello world! TODO: how to run it now on QEMU and real hardware?

• https://fedoraproject.org/wiki/Using_UEFI_with_QEMU

• https://wiki.ubuntu.com/UEFI/OVMF

• https://github.com/tqh/efi-example

Running without image gives the UEFI shell, and a Linux kernel image booted fine with it: http://unix.stackexchange.com/a/228053/32558, so we just need to generate the image.

The blob uefi/ovmf.fd IA32 r15214 was downloaded from: https://sourceforge.net/projects/edk2/files/OVMF/OVMF-IA32-r15214.zip/download TODO: automate building it from source instead, get rid of the blob, and force push it away from history. Working build setup sketch: https://github.com/cirosantilli/linux-cheat/blob/b1c3740519eff18a7707de981ee3afea2051ba10/ovmf.sh

It seems that they have moved to GitHub at last: https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF/e372aa54750838a7165b08bb02b105148e2c4190

• https://www.youtube.com/watch?v=V2aq5M3Q76U hardcore kernel dev Matthew Garrett saying how bad UEFI is

• https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface

• http://wiki.osdev.org/UEFI

Outcome: you are left in an interactive GRUB menu with two choices:

• hello-world: go into a hello world OS

• self +1: reload ourselves, and almost immediately reload GRUB and fall on the same menu as before

This example illustrates the chainloader GRUB command, which just loads a boot sector and runs it: https://www.gnu.org/software/grub/manual/grub/html_node/chainloader.html

This is what you need to boot systems like Windows which GRUB does not know anything about: just point to their partition and let them do the job.

Both of the menu options are implemented with chainloader:

• hello-world:

  Loads a given image file within the partition.

  After build, grub-mkrescue creates a few filesystems, and grub/chainloader/iso/boot/main.img is placed inside one of those filesystems.

  This illustrates GRUB’s awesome ability to understand certain filesystem formats, and fetch files from them, thus allowing us to pick between multiple operating systems with a single filesystem.

  It is educational to open up the generated grub/chainloader/main.img with the techniques described at https://askubuntu.com/questions/69363/mount-single-partition-from-image-of-entire-disk-device/673257#673257 to observe that the third partition of the image is a VFAT filesystem, and that it contains the boot/main.img image as a regular file.

• self +1: uses the syntax:

  chainloader +1

  which reloads the first sector of the current partition, and therefor ourselves.

TODO: why does it fail for hybrid ISO images? http://superuser.com/questions/154134/grub-how-to-boot-into-iso-partition#comment1337357_154271

TODO get working.

OK, let’s have some fun and do the real thing!

Expected outcome: GRUB menu with a single Buildroot entry. When you select it, a tiny pre-built Linux image boots from: https://github.com/cirosantilli/linux-kernel-module-cheat

Actual outcome: after selecting the entry, nothing shows on the screen. Even if we fix this, we will then also need to provide a rootfs somehow: the initrd GRUB command would be a simple method, that repo can also generate initrd images: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/c06476bfc821659a4731d49e808f45e8c509c5e1#initrd Maybe have look under Buildroot boot/grub2 and copy what they are doing there.

The GRUB command is of form:

so we see that the kernel boot parameters are passed right there, for example try to change the value of the printk.time parameter:

and see how the dmesg times not get printed anymore.

QEMU supports multiboot natively https://stackoverflow.com/questions/25469396/how-to-use-qemu-properly-with-multi-boot-headers/32550281#32550281:

which actually runs:

where main.elf is the multiboot file we generated.

Outcome:

Or you can use grub-mkrescue to make a multiboot file into a bootable ISO or disk:

The main.img file can also be burned to a USB and run on real hardware.

Example originally minimized from https://github.com/programble/bare-metal-tetris

This example illustrates the multiboot GRUB command: https://www.gnu.org/software/grub/manual/grub/html_node/multiboot.html

We also track here the code from: http://wiki.osdev.org/Bare_Bones:

Outcome:

This is interesting as it uses C as much as possible with some GAS where needed.

This should serve as a decent basis for starting a pet OS. But please don’t, there are enough out there already :-)

Tests for utilities defined in this repo, as opposed to x86 or external firmware concepts.

TODO: implement the function and enable this test: test_vga_print_bytes.S

14.1.1. PRINT_BYTES

./run test_print_bytes

40 41 42 43 44 45 46 47
48 49 4A 4B 4C 4D 4E 4F
50

14.1.2. PIT_SLEEP_TICKS

./run test_pit_sleep_ticks

./run test_pit_sleep_protected

14.2.1. ThinkPad T400

14.2.2. ThinkPad T430

This repository covers only things that can only be done from ring 0 (system) and not ring 3 (userland).

Ring 3 is covered at: https://github.com/cirosantilli/x86-assembly-cheat

An overview of rings 0 and 3 can be found at: https://stackoverflow.com/questions/18717016/what-are-ring-0-and-ring-3-in-the-context-of-operating-systems/44483439#44483439

There are a few tutorials that explain how to make an operating system and give examples of increasing complexity with more and more functionality added: Progressive tutorials.

This is not one of them.

The goal of this repository is to use the minimal setup possible to be able to observe a single low-level programming concept for each minimal operating system we create.

This is not meant provide a template from which you can write a real OS, but instead to illustrate how those low-level concepts work in isolation, so that you can use that knowledge to implement operating systems or drivers.

Minimal examples are useful because it is easier to observe the requirements for a given concept to be observable.

Another advantage is that it is easier to DRY up minimal examples with macros or functions, which is much harder on progressive OS template tutorials, which tend to repeat big chunks of code between the examples.

Using C or not is a hard choice.

It does make it much easier to express higher level ideas, and gives portability.

However, it increases the complexity that one has to understand a bit, so I decided to stay away from it when I wrote this tutorial.

But I have since change my mind, and if I ever touch this again seriously, I would rewrite it in C based on C hello world and Newlib: https://electronics.stackexchange.com/questions/223929/c-standard-libraries-on-bare-metal/400077#400077

If this is done, we this repo should then be merged into: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/87e846fc1f9c57840e143513ebd69c638bd37aa8#baremetal-setup together with the ARM Newlib baremetal setups present there.

What the heck is a serial in the real world: https://unix.stackexchange.com/questions/307390/what-is-the-difference-between-ttys0-ttyusb0-and-ttyama0-in-linux/367882#367882

Currently all text output is done the display, and that was a newbie design choice from before I knew the serial existed. The serial is just generally more minimal and elegant than the display, and should have been used instead.

On QEMU, we see the serial output on the host terminal:

and on Bochs we redirect it to a file:

Source: bios_serial.S

TODO: failed attempt without BIOS:

Source: serial.S

Like every other of those old hardwares, it is impossible to find its documentation, must be rotting on some IBM mainframe that is not connected to the internet, so we go for:

• OSDev: https://wiki.osdev.org/Serial_Ports

• Samy likely just copied OSDev that for his: https://github.com/SamyPesse/How-to-Make-a-Computer-Operating-System/blob/eb30f8802fac9f0f1c28d3a96bb3d402bdfc4687/src/kernel/modules/x86serial.cc#L38

Bibliography:

• https://stackoverflow.com/questions/22571379/intel-galileo-bare-metal-uart

• https://stackoverflow.com/questions/27594297/how-to-print-a-string-to-the-terminal-in-x86-64-assembly-nasm-without-syscall

This would open up:

• gem5 benchmarking and exploration, currently blocked on https://stackoverflow.com/questions/50364863/how-to-get-graphical-gui-output-and-user-touch-keyboard-mouse-input-in-a-ful/50364864#50364864

• the output stays persistently on the host terminal. So we can run QEMU without a GUI, immediatily shutdown the machine it at the end, and not have to close QEMU manually all the time.

• automated unit tests. Ha, like I’m gonna be that diligent!

• easily working on ARM in a more uniform way to prepare for the move in to https://github.com/cirosantilli/linux-kernel-module-cheat/tree/87e846fc1f9c57840e143513ebd69c638bd37aa8#baremetal-setup

Using macros for now on common.h instead of functions because it simplifies the linker script.

But the downsides are severe:

• no symbols to help debugging. TODO: I think there are assembly constructs for that.

• impossible to step over method calls: you have to step into everything. TODO: until?

• larger output, supposing I can get linker gc for unused functions working, see --gc-section, which is for now uncertain.

  If I can get this working, I’ll definitely move to function calls.

  The problem is that if I don’t, every image will need a stage 2 loader. That is not too serious though, it could be added to the BEGIN.

  It seems that ld can only remove sections, not individual symbols: http://stackoverflow.com/questions/6687630/c-c-gcc-ld-remove-unused-symbols With GCC we can use -ffunction-sections -fdata-sections to quickly generate a ton of sections, but I don’t thing GAS supports that…​

We should just rewrite the whole thing to use functions instead…​

15.5.1. Macro conventions

Source: nasm/bios_hello_world.asm

While NASM is a bit more convenient than GAS to write a boot sector, I think it is just not worth it.

When writing an OS in C, we are going to use GCC, which already uses GAS. So it’s better to reduce the number of assemblers to one and stick to GAS only.

Right now, this directory is not very DRY since NASM is secondary to me, so it contains mostly some copy / paste examples.

On top of that, GAS also supports other architectures besides x86, so learning it is more useful in that sense.

Always try looking into the Linux kernel to find how those CPU capabilities are used in a "real" OS.

OS dev is one of the most insanely hard programming tasks a person can undertake, and will push your knowledge of several domains to the limit.

Knowing the following will help a lot:

• userland x86 assembly: https://github.com/cirosantilli/assembly-cheat

• compilation, linking and ELF format basics

• GDB debugging

While it is possible to learn those topics as you go along, and it is almost certain that you will end up learning more about them, we will not explain them here in detail.

We are interested mostly in the "Intel Manual Volume 3 System Programming Guide", where system programming basically means "OS stuff" or "bare metal" as opposed to userland present in the other manuals.

This repository quotes by default the following revision: 325384-056US September 2015 https://web.archive.org/web/20151025081259/http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf

Fun, educational and useless:

• https://github.com/arjun024/mkeykernel, https://github.com/arjun024/mkernel

  Worked, but bad build system: not Makefile or .gitignore.

The following did not work on my machine out of the box:

• https://github.com/apparentlymart/ToyOS

• https://github.com/rde1024/toyos

16.2.1. Baremetal games

• https://farid.hajji.org/en/blog/46-hello-world-on-the-bare-metal

• https://arobenko.gitbooks.io/bare_metal_cpp/content/

16.3.1. Educational NIXes

16.3.2. Educational non-NIXes

• 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

• http://www.osdever.net/

• https://courses.engr.illinois.edu/ece390/books/labmanual/index.html Illinois course from 2004

16.5.1. jamesmolloy

16.5.2. cfenollosa/os-tutorial

cd 23-fixes
make run

16.5.3. SamyPesse/How-to-Make-a-Computer-Operating-System

16.5.4. Other progressive tutorials

These are not meant as learning resources but rather as useful programs:

• https://github.com/scanlime/metalkit A more automated / general bare metal compilation system. Untested, but looks promising.

• Python without an "OS": https://us.pycon.org/2015/schedule/presentation/378/

A list of ARM bare metal resources can be found at: https://github.com/cirosantilli/arm-assembly-cheat/tree/117f5d7d3458c028275ce112725f2e36f594f13c#bare-metal