I want to crate an OS as a hobby project, but I have absolutely no idea where to start.
Questions: Where can I get a kernel? How would I use it? Do I need to create my own? Should I boot it with UEFI or BIOS? What dev tools do I need? Will it be compatible with CPUs that are not what I’m testing with? Should I use a VM instead of a physical machine?
Any help will be much appreciated.
Where to start and questions
-
- Posts: 1
- Joined: Mon Apr 26, 2021 10:42 pm
Where to start and questions
Last edited by Octocontrabass on Wed May 05, 2021 8:36 pm, edited 2 times in total.
Reason: Spam links removed.
Reason: Spam links removed.
Re: Where to start and questions
That's just my opinion but I think most of the people here create their own kernels. Maybe you could grab something like Linux kernel and work with that, but you'll miss out most of the fun of developing your own OS. I wouldn't bother with booting with BIOS or UEFI directly at first. It's easier to start with something like GRUB. GRUB supports many ways of booting OS images. IMO, the most universal would be Multiboot.
As for tools. You'll need about the same tools that you would use for regular programming. Maybe with the exception of assembler. You will need to write some small parts in assembler. To create bootable multiboot USB disk image you'll need to use `grub-mkrescue` and `dd` commands. https://wiki.osdev.org/Bare_bones describes how to use them.
I've just cobbled together some very basic bare bones kernel stub for x86. I was about to do it anyway. So feel free to make use of it.
https://github.com/pvc988/bare-bare-i386 It does not need any cross compiler in most cases.
My favorite combination is GRUB(loader) + YASM(assembler) + GCC(compiler) + Qt Creator(IDE) + GNU LD(linker) + GNU Make (build system) + QEMU(VM) + GDB(debugger).
As for tools. You'll need about the same tools that you would use for regular programming. Maybe with the exception of assembler. You will need to write some small parts in assembler. To create bootable multiboot USB disk image you'll need to use `grub-mkrescue` and `dd` commands. https://wiki.osdev.org/Bare_bones describes how to use them.
I've just cobbled together some very basic bare bones kernel stub for x86. I was about to do it anyway. So feel free to make use of it.
https://github.com/pvc988/bare-bare-i386 It does not need any cross compiler in most cases.
My favorite combination is GRUB(loader) + YASM(assembler) + GCC(compiler) + Qt Creator(IDE) + GNU LD(linker) + GNU Make (build system) + QEMU(VM) + GDB(debugger).
Re: Where to start and questions
I started with a boot loader, so I could learn the hoops you have to jump through to get an intel to boot into 64bit mode.
I wrote it in NASM (using notepad++) learned how to turn it into a raw disk image that I then ran on BOCHS (an intel emulator).
That took many weeks - I had to learn a LOT on the way.
Develop on Windows and I wanted a native scripting language that would handle the build steps. After trying batch, PowerShell, and other obscurities, I now use a bit of batch and mostly nodejs to:
1. Build the .asm files into a boot loader binary.
2. Create my own file system as raw disks and inject the boot loader (plus signature and number of sectors it occupies)
3. Build the kernel binary from assembly (its still more of a private than a kernel, but I am optimistic)
4. Have a boot loader that:
- loads from the first sector and loads the remainder of itself into contiguous ram from subsequent disk sectors.
- Initializes memory and changes the CPU to 32 bit mode.
- initializes again and changes the CPU to 64 bit mode.
- initializes interrupts and exceptions and loads a rudimentary (not fully complete) keyboard driver
- Outputs messages and debugging information to the console
- Locates the file system descriptors on the disk, searches for, and loads the kernel binary.
- Loads a nic driver and send an ARP packet (relocating the the kernel)
- Runs a bunch of regression tests on the memory manager (just scrapped in favor of a simpler system)
5. Have a kernel that doesn't do much of anything right now except scan the PCI bus for NIC drivers and say, "hello I am a kernel"
(Although I did have fun learning to write it as relocatable code. Critics, hush!)
6. Get the code running consistently on BOCHS, QEMU, VirtualBox, VMWare, and HyperV.
For me the most important step was having a coherent repeatable build-to-test pipeline. It meant I could make a change in assembler in notepad++, run the script and see the results in about 20 seconds. Of course, as my OS grows that will get longer, and i still have to figure out how to automate testing the VM from outside the VM. And I plan to write some tools to scan the file system for errors, memory dump extractors, etc.
Not sure if that helps or overwhelms. I started three years ago, but in real effort I have only spent about 500 hours on the project. Work comes first, of course!
Bottom line, try starting with a boot loader. It worked for me, and things naturally build on it, along with your understanding. I'm talking Intel/AMD - others will have to comment on other processors, where I have no knowledge whatsoever. Prior to this I had about 3 months' experience in 8 bit machine code and a 2 week course in Z80. That helped, but not very much - post Pentium intel technology is as massive beast by comparison.
Whatever else, don't be put off by those that say you shouldn't try, or should learn everything you need to know up front. They are not correct - learning on the job is what versatile software developers do best.
I wrote it in NASM (using notepad++) learned how to turn it into a raw disk image that I then ran on BOCHS (an intel emulator).
That took many weeks - I had to learn a LOT on the way.
Develop on Windows and I wanted a native scripting language that would handle the build steps. After trying batch, PowerShell, and other obscurities, I now use a bit of batch and mostly nodejs to:
1. Build the .asm files into a boot loader binary.
2. Create my own file system as raw disks and inject the boot loader (plus signature and number of sectors it occupies)
3. Build the kernel binary from assembly (its still more of a private than a kernel, but I am optimistic)
4. Have a boot loader that:
- loads from the first sector and loads the remainder of itself into contiguous ram from subsequent disk sectors.
- Initializes memory and changes the CPU to 32 bit mode.
- initializes again and changes the CPU to 64 bit mode.
- initializes interrupts and exceptions and loads a rudimentary (not fully complete) keyboard driver
- Outputs messages and debugging information to the console
- Locates the file system descriptors on the disk, searches for, and loads the kernel binary.
- Loads a nic driver and send an ARP packet (relocating the the kernel)
- Runs a bunch of regression tests on the memory manager (just scrapped in favor of a simpler system)
5. Have a kernel that doesn't do much of anything right now except scan the PCI bus for NIC drivers and say, "hello I am a kernel"
(Although I did have fun learning to write it as relocatable code. Critics, hush!)
6. Get the code running consistently on BOCHS, QEMU, VirtualBox, VMWare, and HyperV.
For me the most important step was having a coherent repeatable build-to-test pipeline. It meant I could make a change in assembler in notepad++, run the script and see the results in about 20 seconds. Of course, as my OS grows that will get longer, and i still have to figure out how to automate testing the VM from outside the VM. And I plan to write some tools to scan the file system for errors, memory dump extractors, etc.
Not sure if that helps or overwhelms. I started three years ago, but in real effort I have only spent about 500 hours on the project. Work comes first, of course!
Bottom line, try starting with a boot loader. It worked for me, and things naturally build on it, along with your understanding. I'm talking Intel/AMD - others will have to comment on other processors, where I have no knowledge whatsoever. Prior to this I had about 3 months' experience in 8 bit machine code and a 2 week course in Z80. That helped, but not very much - post Pentium intel technology is as massive beast by comparison.
Whatever else, don't be put off by those that say you shouldn't try, or should learn everything you need to know up front. They are not correct - learning on the job is what versatile software developers do best.
Code or code not. There is no try.
Re: Where to start and questions
There were some spam links in there? If I knew it was spam post I wouldn't bother replying. Guess I am getting more color blind than I already am
Re: Where to start and questions
No need to adjust your glasses, the links were colored black.pvc wrote:There were some spam links in there? If I knew it was spam post I wouldn't bother replying. Guess I am getting more color blind than I already am
Carpe diem!
-
- Member
- Posts: 5568
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Where to start and questions
...and they were edited into the post after it got a couple replies.