Skip to content
This repository has been archived by the owner on Mar 19, 2024. It is now read-only.

AArch64 TODO #232

Open
24 of 39 tasks
klange opened this issue Jan 29, 2022 · 0 comments
Open
24 of 39 tasks

AArch64 TODO #232

klange opened this issue Jan 29, 2022 · 0 comments
Assignees
Labels

Comments

@klange
Copy link
Owner

klange commented Jan 29, 2022

This ticket tracks the status of support for AArch64 in Misaka and the rest of ToaruOS.

As of 2022-02-09, most essential functionality is available. SMP, basic memory management, processes, threads, debug tracing, graphical output, and a set of input devices are available. ToaruOS boots to a full GUI in QEMU, including KVM and HVF hardware virtualization environments.

Remaining work is mostly focused on device support. Interrupt management is missing and there are no supported network or audio devices. No physical hardware platforms are supported at this time.

  • Build environment and toolchain
    • Still some quirks with how libgcc_s.so is getting linked in userspace, look into this.
      • Weird link script resulted in absolute path (from the host) as the NEEDED entry for libgcc_s.so. -l: fixed it.
  • Essential bringup
    • Stub loader for QEMU's -machine virt is ready.
    • Basic memory management API is implemented.
    • System timer is providing a clock source.
    • Ramdisk, filesystem, framebuffer access are working.
    • Userspace is reachable.
    • System call interface is functioning.
  • Kernel context switching
  • TLS relocations
  • sys_clone() ABI stuff
  • Interrupt management
    • Need a preempt source for timing functions to work.
    • Page fault handlers
    • CoW
      • Do we have any actual blockers for CoW? How big is our refcount table? I think it's still 1MiB/4GiB.
  • Basic device drivers
    • virtio-keyboard, virtio-tablet
    • USB is a necessary thing for real hardware targets.
    • virtio-net
    • virtio-gpu as the Bochs adapter has issues
  • SMP
    • Basic core bringup
    • Fix cache bugs
    • arch_fatal_prepare, arch_fatal need to stop other cores
      • Should we turn the other cores off with PSCI or send them an IPI like we do on x86-64?
  • Modules
    • Change module builds to use separate sources
    • Implement necessary static object relocations
    • Possibly move some things (virtio?) to modules
  • Clean up
    • Make sure build makes sense and we haven't broken x86-64.
    • Fix up memory discovery
    • procfs stuff
    • signal delivery
    • ptrace and debug functions; tracebacks
    • Fixup hardcoded virt-isms.
    • Implement stubbed libc functions: atan2, pow, fmod
  • Set up AArch64 builds in CI
    • Rebuild Docker image to add aarch64 toolchain
    • Add a new job
  • Other thoughts
    • Break out the PMM as it is, thus far, entirely generic.
    • Consider giving the PMM a base address so we can not waste a few kilobytes of bitmap space tracking the 1GiB of device memory in the virt machine.
    • Consider consolidating more of the VMM as it is astoundingly similar between x86-64 and AArch64 with 4K pages.
    • Port virtio input device drivers back to x86-64 (shared module between the two arches?)

Screenshot from 2022-01-29 07-56-03
Screenshot from 2022-01-29 10-23-19
Screenshot from 2022-01-29 19-15-17

@klange klange changed the title Port to AArch64 AArch64 TODO Feb 6, 2022
@klange klange added the kernel label Feb 9, 2022
@klange klange self-assigned this Feb 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant