Project base

.gitignore

@@ -0,0 +1,3 @@
+*.o
+*.iso
+*.bin

Makefile

@@ -0,0 +1,32 @@
+CC = x86_64-elf-gcc
+AS = nasm
+
+BUILDDIR := build
+CFLAGS   := -ffreestanding -Wall -Wextra -Werror -mno-red-zone
+LDFLAGS  := -ffreestanding -nostdlib -lgcc -T kernel/kernel.ld
+
+KSRC := $(wildcard kernel/*.asm kernel/*.c)
+KOBJ := $(addprefix $(BUILDDIR)/, \
+		$(notdir \
+		$(patsubst %.asm,%.o, $(patsubst %.c,%.o, $(KSRC)))))
+KIMG := kernel.bin
+
+$(BUILDDIR)/$(KIMG): $(KOBJ)
+	$(CC) $^ -o $@ $(LDFLAGS)
+$(BUILDDIR)/%.o: */%.asm
+	$(AS) -felf64 $^ -o $@
+$(BUILDDIR)/%.o: */%.c
+	$(CC) $(CFLAGS) -c $^ -o $@
+
+kernel: $(BUILDDIR)/$(KIMG)
+
+$(BUILDDIR)/Hazel.iso: kernel
+	cp $(BUILDDIR)/kernel.bin boot/kernel.bin
+	grub-mkrescue -o  $(BUILDDIR)/Hazel.iso .
+iso: $(BUILDDIR)/Hazel.iso
+
+qemu: iso
+	qemu-system-x86_64 -cdrom $(BUILDDIR)/Hazel.iso
+
+clean:
+	rm build/* boot/*.bin

boot/grub/grub.cfg

@@ -0,0 +1,5 @@
+default=0
+timeout=0
+menuentry "Hazel" {
+    multiboot2 /boot/kernel.bin
+}

kernel/init.asm

@@ -0,0 +1,20 @@
+%define MAGIC 0xE85250D6
+%define ARCH  0x0
+%define LEN   (multiboot_end - multiboot_start)
+
+section .multiboot
+multiboot_start:
+dd MAGIC
+dd ARCH
+dd LEN
+dd -(MAGIC + ARCH + LEN)
+multiboot_end:
+
+section .text
+global _start
+_start:
+   mov byte [0xb8000], 'X'
+   mov byte [0xb8001], 0x0f
+
+   cli
+   jmp $

kernel/kernel.c

@@ -0,0 +1,4 @@
+void kernel() {
+    asm volatile ("cli" ::);
+    for (;;) {}
+}

kernel/kernel.ld

@@ -0,0 +1,52 @@
+/* The bootloader will look at this image and start execution at the symbol
+   designated as the entry point. */
+ENTRY(_start)
+
+/* Tell where the various sections of the object files will be put in the final
+   kernel image. */
+SECTIONS
+{
+	/* It used to be universally recommended to use 1M as a start offset,
+	   as it was effectively guaranteed to be available under BIOS systems.
+	   However, UEFI has made things more complicated, and experimental data
+	   strongly suggests that 2M is a safer place to load. In 2016, a new
+	   feature was introduced to the multiboot2 spec to inform bootloaders
+	   that a kernel can be loaded anywhere within a range of addresses and
+	   will be able to relocate itself to run from such a loader-selected
+	   address, in order to give the loader freedom in selecting a span of
+	   memory which is verified to be available by the firmware, in order to
+	   work around this issue. This does not use that feature, so 2M was
+	   chosen as a safer option than the traditional 1M. */
+	. = 2M;
+
+	/* First put the multiboot header, as it is required to be put very early
+	   in the image or the bootloader won't recognize the file format.
+	   Next we'll put the .text section. */
+	.text BLOCK(4K) : ALIGN(4K)
+	{
+		*(.multiboot)
+		*(.text)
+	}
+
+	/* Read-only data. */
+	.rodata BLOCK(4K) : ALIGN(4K)
+	{
+		*(.rodata)
+	}
+
+	/* Read-write data (initialized) */
+	.data BLOCK(4K) : ALIGN(4K)
+	{
+		*(.data)
+	}
+
+	/* Read-write data (uninitialized) and stack */
+	.bss BLOCK(4K) : ALIGN(4K)
+	{
+		*(COMMON)
+		*(.bss)
+	}
+
+	/* The compiler may produce other sections, by default it will put them in
+	   a segment with the same name. Simply add stuff here as needed. */
+}