Skip to content

Commit 8969dac

Browse files
authored
Test markdown detection (#96)
* Add markdown detection as language * Update FUNDING.yml * Update README.md Update some parts of the readme, removing text staitng that was a work in progress. * Typo fixes * Fix typo in boot protocols chapter * Minor fixes on boot protocl chapter * Add detail for gdb * Fix error in cross comiler character * Update updates
1 parent 7b4257d commit 8969dac

File tree

10 files changed

+22
-19
lines changed

10 files changed

+22
-19
lines changed

.gitattributes

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
*.md linguist-detectable=true
2+
*.md linguist-documentation=false

.github/FUNDING.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,10 @@
33
github: dreamos82
44
patreon: inuyasha82
55
open_collective: # Replace with a single Open Collective username
6-
ko_fi: # Replace with a single Ko-fi username
6+
ko_fi: dreamos82
77
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
88
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
99
liberapay: # Replace with a single Liberapay username
1010
issuehunt: # Replace with a single IssueHunt username
1111
otechie: # Replace with a single Otechie username
12-
custom: https://www.buymeacoffee.com/dreamos82
12+
custom:

01_Build_Process/02_Boot_Protocols.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ This chapter covers 2 protocols _Sultiboot 2_ and _Stivale 2_:
88

99
* _Stivale 2_ (also superceding stivale 1) is the native protocol of the limine bootloader. Limine and stivale were designed many years after multiboot 2 as an attempt to make hobbyist OS development easier. _Stivale 2_ is a more complex spec to read through, but it leaves the machine in a more known state prior to handing off to the kernel.
1010

11-
Recently limine has added a new protocol (the limine boot protocol) which is not covered here. It's based on stivale2, with mainly architectural architectural changes, but similar concepts behind it. If familiar with the concepts of stivale 2, the limine protocol is easy enough to understand.
11+
Recently limine has added a new protocol (the limine boot protocol) which is not covered here. It's based on stivale2, with mainly architectural changes, but similar concepts behind it. If familiar with the concepts of stivale 2, the limine protocol is easy enough to understand.
1212

1313
All the referenced specifications and documents are provided as links at the start of this chapter/in the readme.
1414

@@ -215,9 +215,9 @@ Stivale 2 has a number of major differences to multiboot 2 though:
215215

216216
- The kernel starts in 64-bit long mode, by default. No need for a protected mode stub to setup up some initial paging.
217217
- The kernel starts with the first 4GB of memory and any usable regions of memory identity mapped.
218-
- Stivale 2 also sets up a 'higher half direct map', or hhdm. This is the same identity map as the lower half, but it starts as the hhdm_offset returned in a struct tag when the kernel runs. The idea is that as long we ensure all the pointers are in the higher half, we can zero the bottom half of the page tables and easily be ready for userspace programs. No need to move code/data around.
218+
- Stivale 2 also sets up a _higher half direct map_, or _hhdm_. This is the same identity map as the lower half, but it starts at the `hhdm_offset` returned in a struct tag when the kernel runs. The idea is that as long we ensure all the pointers are in the higher half, we can zero the bottom half of the page tables and easily be ready for userspace programs. No need to move code/data around.
219219
- A well-defined GDT is provided.
220-
- Unlike mb2, a distinction is made between usable memory and the memory used by the bootloader, kernel/modules, and framebuffer. These are separate types in the memory, and don't intersect. Meaning usable memory regions can be used immediately.
220+
- Unlike _mb2_, a distinction is made between usable memory and the memory used by the bootloader, kernel/modules, and framebuffer. These are separate types in the memory, and don't intersect. Meaning usable memory regions can be used immediately.
221221

222222
To get the next tag in the chain, it's as simple as:
223223

02_Architecture/06_ACPITables.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ We need to access the ACPI Tables in order to read the IO-APIC information, used
88

99
Most of the information is organized and accessible through different data structures, but since the ACPI spec is quite big, and covers so many different components, we focus only on what we need to get the information about the APIC.
1010

11-
Before proceeding, let's keep in mind that all address described below are physical, so if we have enabled paging, we need to ensure they are properly mapped in the virtual memory space.
11+
Before proceeding, let's keep in mind that all addresses described below are physical, so if we we have enabled paging, we need to ensure they are properly mapped in the virtual memory space.
1212

1313
### RSDP
1414

@@ -82,7 +82,7 @@ bool validate_RSDP(char *byte_array, size_t size) {
8282
}
8383
```
8484
85-
Having last byte means that `result mod 0x100` is 0. Now there are two ways to test it:
85+
Having last byte equals `0`, means that `result mod 0x100` is 0. Now there are two ways to test it:
8686
8787
* Using the `mod` instruction, and check the result, if is 0 the structure is valid, otherwise it should be ignored.
8888
* Just checking the last byte of the result it can be achieved in several ways: for example is possible cast the result to `uint_8` if the content after casting is 0 the struct is valid, or use bitwise AND with `0xFF` value (`0xFF` is equivalent to the `0b11111111` byte) `sum & 0xFF`, if it is 0 the struct is valid otherwise it has to be ignored.

02_Architecture/07_APIC.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ Both types of APIC are accessed by memory mapped registers, with 32-bit wide reg
1717

1818
## Local APIC
1919

20-
When a system boots up, the cpu starts in PIC8259A emulation mode for legacy reasons. This simply means that instead of having the LAPIC and I/O APIC up and running, we have them working to emulate the old interrupt controller, so before we can use them properly we should to disable the PIC8259 emulation.
20+
When a system boots up, the cpu starts in PIC8259A emulation mode for legacy reasons. This simply means that instead of having the LAPIC and I/O APIC up and running, we have them working to emulate the old interrupt controller, so before we can use them properly we should disable the PIC8259 emulation.
2121

2222
### Disabling The PIC8259
2323

08_VirtualFileSystem/02_VirtualFileSystem.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -24,8 +24,8 @@ It shows a portion of a unix directory tree (starting from root), the gray circl
2424

2525
So for example:
2626

27-
* /home/userA point to a folder into the file system that is loaded at the "/" folder (we say that it's *mounted*)
28-
* /mnt/ext_device instead points to a file that is mounted within the /mnt folder
27+
* /home/user1 point to a folder into the file system that is loaded at the "/" folder (we say that it's *mounted*)
28+
* /mnt/ext_device/A instead points to a file that is mounted within the /mnt folder
2929

3030
When a filesystem is *mounted* in a folder it means that the folder is no longer a container of other files/directories for the same filesystem but is referring to another one somewhere else (it can be a network drive, external device, an image file, etc.) and the folder takes the name of *mountpoint*.
3131

99_Appendices/E_Cross_Compilers.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -138,7 +138,7 @@ As usual let's create a new folder called `build_qemu` and move into it. The con
138138
```
139139
where:
140140

141-
* `--target-list=riscv64-softmmu,x86_64`: is a comma separated list of platforms we want to support.
141+
* `--target-list=riscv64-softmmu,x86_64-softmmu`: is a comma separated list of platforms we want to support.
142142
* `--enable-tools`: will build support utilities that comes with qemu
143143
* `--enable-gtk`: it will enable the gtk+ interface
144144
* `--enable-vhost-net` : it will enable the vhost-net kernel acceleration support
@@ -167,6 +167,8 @@ The last two options enable compiling the text-user-interface (`--enable-tui`) a
167167

168168
The `--target=` flag is special here in that it can also take an option `all` which builds gdb with support for every single architecture it can support. If we're going to develop on one machine but test on multiple architectures (via qemu or real hardware) this is nice. It allows a single instance of gdb to debug multiple architectures without needing different versions of gdb. Often this is how the 'gdb-multiarch' package is created for distros that have it.
169169

170+
The `--host=` flags specify the host system running gdb, in the example above an `x86_64-linux-gnu` system, this should be changed depedning on the system used.
171+
170172
After running the configure script, we can build and install our custom gdb like so:
171173

172174
```bash

99_Appendices/J_Updates.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ Fourth book release
4949

5050
### Revision 4
5151

52-
Release date: TBD
52+
Release date: Sept 2024
5353
Fifth book release
5454

5555
* Typo fixes

99_Appendices/README.md

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,8 @@
55
- [Appendix C: C Language Extras](C_Language_Info.md)
66
- [Appendix D: Using NASM](D_Nasm.md)
77
- [Appendix E: Cross Compilers](E_Cross_Compilers.md)
8-
- [Appendix F: Debugging](E_Debugging.md)
9-
- [Appendix G: Memory Protection](F_Memory_Protection.md)
10-
- [Appendix H: Useful Resources](G_Useful_Resources.md)
11-
- [Appendix I: Acknowledgments](H_Acknowledgments.md)
8+
- [Appendix F: Debugging](F_Debugging.md)
9+
- [Appendix G: Memory Protection](G_Memory_Protection.md)
10+
- [Appendix H: Useful Resources](H_Useful_Resources.md)
11+
- [Appendix I: Acknowledgments](I_Acknowledgments.md)
12+
- [Appendix J: Updates](J_Updates.md)

README.md

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,7 @@
66
</span>
77
![](https://tokei.rs/b1/github/dreamos82/osdev-notes)
88

9-
A collection of notes, organised as a book, intended to guide a reader through the steps of building an operating system kernel from scratch. Written while writing (and re-writing) our own kernels, each chapter covers a step from selecting a bootloader to running a loaded ELF in userspace.
10-
11-
Currently these notes are a work in progress, but many chapters are functionally complete and available to read below. We'll keep updating old chapters and adding new ones over time so be sure to check back occasionally.
9+
A book, originated as a collection of notes, intended to guide a reader through the steps of building an operating system kernel from scratch. Written while writing (and re-writing) our own kernels, each chapter covers a step of the process from selecting a bootloader to running a loaded ELF in userspace.
1210

1311
We hope you enjoy, and find something interesting here!
1412

0 commit comments

Comments
 (0)