Improving Our Bootloader
We improve our bootloader that we made on the first lesson Lesson locked purchase
Description
This course is designed to teach you how to create your very own multitasking operating system and kernel from scratch. It is assumed you have no experience in programming kernels and you are taught from the ground up.
Real Mode Development
Real mode is a legacy mode in all Intel processors that causes the processor to start in a legacy state, it performs like the old 8086 Intel processors did back in the way.
In the "Real Mode Development" section of the course we start by learning about the boot process and how memory works, we then move on to creating our very own boot loader that we test on our real machine! This boot loader will output a simple "Hello World!" message to the screen and we write this boot loader in purely assembly language.
In this section we also read a sector(512 bytes) from the hard disk and learn all about interrupts in real mode and how to create them.
This section gives you a nice taster into kernel development, without over whelming you with information. You are taught the basics and enough about the legacy processors to be able to move forward to more modern kernel development further into this course.
Protected Mode Development
In this section we create a 32 bit multi-tasking kernel that has the FAT16 filesystem. Our kernel will use Intel's built in memory protection and security mechanisms that allow us to instruct the processor to protect our kernel and prevent user programs from damaging it.
This section is very in depth, you are taught all about paging and virtual memory. We take advantage of clever instructions in Intel processors to allow all processes to share the same memory addresses, this is known as memory virtualization. We map memory addresses to point to different physical memory addresses to create the illusion that every process that is running is loaded at the same address. This is a very common technique in kernel development and is also how swap files work (Those files that are used to compensate for when you run out of usable RAM).
We create our own virtual filesystem layer that uses a design that is similar to the Linux kernel. This clever abstraction that will be taught to you was inspired by the instructors knowledge of writing Linux kernel drivers in his past.
You are taught about the design of the FAT16 filesystem and how the FAT16 filesystem is broken down into clusters and that they can chain together. We then implement our very own FAT16 filesystem driver allowing files to be born!
We implement functionality for tasks and processes and write our own keyboard drivers.
In this course you also get to learn how memory management works, we implement the "malloc" and "free" functions creating our very own heap that's designed to keep track of what memory is being used. Memory management is essential in any operating system and kernel.
Let us not forget that we even create an ELF file loader, we will compile all our operating systems programs into ELF files and allow the loading of binary programs or ELF programs. ELF files contain a lot of information that describes our program for example where our program should be loaded into memory and the different sections of the program.
By the end of this course you will have a fully functioning 32 bit multi-tasking kernel that can have many processes and tasks running at the same time. You will have a working shell that we can use as well.
Assembly language bonus
This is a bonus section designed to bring your assembly skills up to scratch should you struggle a little bit with the assembly language in this course. It's however advised you come to this course with experience in assembly language, we do use it and its important. Never the less if you want to take a chance on this course with no assembly experience then this section will help point you in the right direction so your able to take what you learned and apply it to the kernel.
Taught by an expert that has created Linux kernel modules professionally in the work place.
Requirements
-
Understanding the C programming language
-
Understanding Assembly Language
Who This Course is For
People who want to develop a kernel from scratch
What You Will be Learn
How to create a kernel from scratch
How to create a multi-tasking kernel
How to handle malicious or problematic programs in your operating system. Terminating them if they misbehave.
How memory works in computers
The difference between kernel land, user land and the protection rings that make up modern computing
Kernel design patterns used by the Linux kernel its self
You will learn all about virtual memory and how to map virtual addresses to physical addresses
You will learn how to make the kernel understand processes and tasks
You will learn how to load ELF files
You will learn how to debug disassembled machine code
You will learn how to debug your kernel in an emulator with GDB.
Dragon Zap Instructor
Daniel McCarthy is a seasoned software engineer, boasting an impressive career spanning over 14 years in the industry. Holding a Master's Degree in Advanced Computer Science from Cardiff Metropolitan University, his broad spectrum of experience encompasses everything from web development to complex compiler and interpreter development. Daniel has honed his skills in bootloader and kernel development. In testament to his proficiency in the field, he has designed two proprietary programming languages: Craft, a general-purpose language, and Marble, a web-focused language akin to PHP. Moreover, he has successfully developed compilers for the C programming language. A testament to his versatility, Daniel demonstrates proficiency in an extensive list of programming languages that includes C, C++, Java, x86 Assembly language, PIC assembly, SQL, PHP, HTML5, JavaScript, CSS, and of course, his own creations, Craft and Marble. His professional portfolio also includes the development of Linux kernel modules, a task he has executed with proficiency in a professional context. Currently, Daniel is channeling his wealth of experience and expertise into the education sector, with the aim of nurturing the next generation of professional software engineers.
Ask a question
Questions (1)
Olivier Henley
2 years ago
I am a bit lost here. Just to confirm, our code, this bin, will be loaded at absolute address 0x7c0. We change our code segment to 0x7c0 and start referring to everything with an origin of 0. 1) Does it mean 'ds' and 'es' point to a) absolute address 0x7c0 or b) 0x7c0 (where we are loaded, now referred as 0) + 0x7c0? If it's a), overlapping the code segment and data segment address cannot cause problems? 2) The stack segment 'finishes' at 0x00 and at the top, the stack pointer starts at 0x7c00. Are the interrupts not within this range? I think It would help to have a visual walkthrough of where all the things we learned get mapped at this point. Also, the use of '0x7c0' and '0x7c00' for many different things is confusing me; it seems like everything steps on each one's toes but at the same time both addresses are far away. Thank you.
Daniel McCarthy
2 years ago
Hello Oiliver, Thanks for your question. I will be happy to assist. Theirs an assembly section at the end of this course that explains all your questions in a lot of detail I recommend watching it. Whilst we are in real mode we have what is known as segment registers. These registers point to in memory the address multiplied by 16. So if the segment register is 0x7c0 it points to address 0x7c00. Lets pretend the data segment is at 0x7c0. Then when accessing data such as mov byte [0x01], 30 you are moving decimal 30 into address 0x7c01 because the data segment is used. Depending on the instructions used determines which segment register is used. The interrupt vector table starts at absolute address 0x00, to access it set the data segment to address 0x00. Then all your offsets will offset from the interrupt vector table. Does that make sense? Check the assembly catchup for sure as we have a lot of information in there. Thanks, Dan
Olivier Henley
2 years ago
Thank you Daniel. I already listened to the assembly catchup. Ok, I re-listened to episode 8. and now I get it ... except the stack segment at 0x00 * 16 = 0x000. Isn't there an overlap with the interrupt vector table "starts at absolute address 0x00"? Thank you.
Olivier Henley
2 years ago
Ok I think I get it from episode 13. ss is set at 0x00 for convenience as we will be using it to move interrupt handlers and offset to the addresses of the interrupt vector tables. I suppose, if we were to let the stack grow, we would not allow it to grow over the interrupts range. Probably this will be more detailed as we move on. Thank you.
Daniel McCarthy
2 years ago
Sorry for the late reply Oliver my mother came to visit me for one month, I live abroad. I am back to work now. Did you find out what you are looking for or did you have any other question relating to this.
Olivier Henley
2 years ago
Hey Daniel! Hope you had a good time with your mom. :) Yeah, everything is fine now. Thank you!
Daniel McCarthy
2 years ago
Great yes we had a great time thanks :) Any more questions you know how to find me! For direct contact feel free to email at daniel@dragonzap.com or ask another question here.