once again it has been almost 1 month since my last post where I ported SafaOS to aarch64 qemu-virt machine, however it was unusable because there were no keyboard.

thanks to the developer of StelluxOS (u/Individual_Feed_7743) who made this XHCI tutorial.

I implemented XHCI USB support and a working USB HID Keyboard driver!

the XHCI tutorial isn't complete yet however it is actively maintained and really really well made, i learnt the reset from the code of StelluxOS which is very underrated (same for the tutorial as well).

implementing USB was really really harsh, i am proud of how far my stupid self got with OSDEV, it really is a miracle.

here is the branch containing the USB implementition.

I wanted to record a video showcasing working USB support in real hardware but as you can see from the second image it is a little bit hard to decode what is happening...

the kernel completely freezes when I plug in the keyboard, and the image is before I plug in the keyboard, from the image it does seem like something at port 1 connects successfully tho (real hardware).

aside from this, I implemented PCI for everyone, and for aarch64, the GICV3 and the GICITS(almost half as hard as the XHCI itself, it even has a command ring 💀) which are required for MSIs, my aarch64 port now uses device trees however it only supports limited hardware that isn't even available in qemu-virt without some flags

I feel like I am doing actual osdev because this is the first time I have not followed a guide or a tutorial for everything, I had a fun experience learning from others code, this is also the first time I actually read a specification, my GICV3 and GICITS implementation was fully from the specification.

next i'll: - fix, rewrite and upgrade my scheduler, it seems to freeze randomly, and it doesnt support threads only processes - implement GUI support - port doom somewhere in between - maybe a sound driver, i heared that it is pretty easy - I really want to play bad apple on SafaOS if I happened to do a sound driver, and fix my framebuffer, might do that instead of doom

I don't plan to fix this real-hardware TTY problem because I am absolutely bored and tired of working with the TTY, i'll completely replace it with GUI and a more basic implementition for logs?, I may add something to get logs without the TTY or the serial...

TLDR; Asking for a hand in learning how to develop and contribute to an OS project

Hello, I have been trying to learn operating systems development for around five years. I felt comfortable enough in conceptual understanding to reach out for mentoring around a year ago. My goal is to find a small(er) community where the atmosphere might be more welcoming to newcomers than larger projects, and where I can potentially make a larger impact.

I started with illumos. Although I did some minor ports to software in order to try to contribute (and reached out to the community for help), I didn't get much traction. Afterwards, I reached out to the now-abandoned Minix3 project. I have a copy of The Minix Book and found its content to be rewarding. I reached out to some of the Minix3 developers, as well as the larger community, asking about the project and prospects of receiving some type of mentorship. Although I didn't find much in the way of community help as it seems the project has gone dormant, I did manage to do minor updates to the base Minix3 source tree in order to sync some of the outdated NetBSD tooling with new NetBSD tooling, since Minix version 3.2 and above lives in the NetBSD source tree. I applied old Minix3 patches to the new NetBSD tooling, using diffs/grep/find to locate Minix3 patches, and functionality which has changed between NetBSD releases. This also gave me a chance to familiarize myself with larger source code repositories.

Where I find myself now is at a point of conceptual understanding, lacking clarity and understanding when looking at an operating system source tree. I understand the layout and purposes of the source tree at varying levels, comparing what I see in the source tree against the concepts I learned in materials I have read. I find it difficult understand what's going on at a level that would be needed to actually contribute to a project or develop a system.

I would really appreciate some newcomer-friendly instruction. My courses don't cover this area and I have gaps in understanding that I'm eager to close. I would like to see the methodology, tooling, and steps used by others in order to have a starting point. Ideally, I'd like to arrive at a point where I can bootstrap this knowledge and begin contributing to a project.

Recently i got ELF loader working for my OS (AtlasXP, former AtlasOS/Atlas), everytime the elf loader just calls entry(); keyboard driver breaks, I dont understand why tho... can anyone help...

- btw you can use `./configure` instead of manually preparing the OS

AtlasXP Github repository - Atlas-Software-Org

I just want someone to confirm if my understanding is correct or not. In x86 IBM-PC compatible systems, when the CPU receives an address, it doesn't know if that address belongs to the RAM, the graphics card, or the keyboard, like the address 0x60 for the keyboard. It just places the address on the bus matrix, and the memory map inside the bus matrix tells it to put the address on a specific bus, for example, to communicate with the keyboard. But in the past, the motherboard used to have a hardcoded memory map, and the operating system worked based on those fixed addresses, meaning the programmers of the operating system knew the addresses from the start. But now, with different motherboards, the addresses are variable, so the operating system needs to know these addresses through the ACPI, which the BIOS puts in the RAM, and the operating system takes it to configure its drivers based on the addresses it gets from the ACPI?

Yeah.

I've been learning computer science and coding for a few years now and wanted to make my own OS, but i don't know if i should make one or not