-
Notifications
You must be signed in to change notification settings - Fork 25
Add half-baked aarch64 support #73
Conversation
Now, the toolchain is located in a subdirectory according to architecture (toolchain/tools/[arch]), as are the builds (build/[arch]). The instructions have been updated accordingly.
Hi Aroon, Just for curiosity: I'm following you very interested |
I'm gonna be honest - I haven't done a ton of research into specifics yet. I'm going to start with a generic qemu aarch64 target, and if I can, I'd love to get it running on a Pi 4. My method is to learn by doing, so I'm just crossing bridges as I get to them - my new job will involve lots of arm64 kernel work, so I suppose this is my way of giving myself a crash course :) |
Mmmh, aarch64 kernel as a job... Good job man! |
It doesn't do anything or work at all on aarch64 though :)
Targeting the raspi3b, the kernel can now boot, drop to el1, and output through MiniUART and access the framebuffer.
It lives! (Sort of). We can boot, initialize MiniUART for output, drop to el1, and access the framebuffer. Still not even close to functional yet - still no MMU, interrupts, exceptions, kbd/mouse, tasking, etc. Most of the work so far has been refactoring architecture-dependent stuff in the kernel and getting the dang thing to compile :) I have decided to start with targeting the RPi 3b since qemu has a machine preset for it, there's tons of documentation, and I already have one. From there, targeting the Pi4 should be pretty simple since it uses a similar Broadcom SOC I believe. |
Also splits up a lot of paging logic to be per-architecture. We can now map pages in the kernel through the usual mechanisms, and as a result, use the MM.alloc family of functions.
Also don't use sdl display for aarch64 because it doesn't work properly for some reason
Turns out qemu doesn't emulate most of those hardware quirks ;) After tearing my hair out for days, it finally boots!
After days of agony, it boots on real hardware! Turns out QEMU doesn't emulate a lot of the fun hardware quirks, but armed with nothing but a UART cable and time for lots of trial and error, I eventually got it working on a real RPi 3b. We can now use memory management through the normal mechanisms, meaning the way is paved to start getting the fun stuff going! Up next are interrupts and tasking. |
Hi Aroon, Great Work! |
I should be able to - I haven't looked much into it yet, but I assume doing so will involve setting up a USB stack. It's simple on the PC platform because you can use the PS/2 controller as a fallback mode even if the M/K are USB, but I don't believe the RPi has any sort of equivalent, so I'll need to implement a USB stack and a USB HID driver. I could be wrong though. |
...And, this is me signing out for a while. It's been fun :)
Unfortunately, life has been pretty busy with moving and all sorts of other stuff, and I've run out of time for now. I'll merge what I have so far, just so it's there :) I'm at least glad I was able to get some basics done. |
I've wanted to port duckOS to another architecture besides outdated 32-bit x86 for a while now - and I've settled on starting with aarch64 for the ultimate challenge :)
I'm on a bit of a deadline here in terms of when I start my new job and thus have to stop working on duckOS, so this'll be fun.
Don't expect anything to compile or run yet, this is extremely WIP.