haiku/docs/develop/kernel/arch/arm/todo.txt
Augustin Cavalier 18a8edbf0e docs/develop: More reorganization.
* There is now a 'busses' folder, and the extant USB/SDHCI/Bluetooth/etc.
   docs now live in it, instead of various other places.
 * kernel/ports is now kernel/arch, like it is in src/system.
   SPARC documentation is now in there, too.
 * VM files (these are rather outdated) are now in kernel/vm.
 * SCSI ASC info removed, this is easily available online and
   it doesn't seem to be very relevant.
2019-03-30 18:00:46 -04:00

65 lines
3.3 KiB
Plaintext

* Fix pre-ARMv7 support
Currently the cross-tools are compiled to default to ARMv7, Cortex-A8, and
hardware floating point. This works around the missing atomic support, see
below. This should be done by setting the -mcpu,-march and -mfloat-abi
switches at build time, however, they aren't passed on to haikuporter
during the bootstrap build, leading to the ports failing to find the
gcc atomic ops again.
* Determine how to handle atomic functions on ARM.
GCC inlines are not supported, since the instructionset is ill-equiped for
this on older (pre-ARMv7) architectures. We possibly have to do something
similar to the linux kernel helper functions for this....
On ARMv7 and later, this is not an issue. Not sure about ARMv6, we may get
it going there. ARMv5 definitely needs us to write some code, but is it
worth the trouble?
* Fix multilib support
ARM-targetting versions of gcc are usually built with multilib support, to
allow targetting architectures with or without FPU, and using either ARM
or Thumb instructions. This bascally means a different libgcc and libstdc++
are built for each combination.
The cross-tools can be built with multilib support. However, we do some
tricks to get a separate libgcc and libstdc++ for the kernel (without C++11
threads support, as that would not build in the kernel). Building this lib
is not done in a multilib-aware way, so you get one only for the default
arch/cpu/abi the compiler is targetting. This is good enough, as long as that
arch is the one we want to use for the kernel...
Later on, the bootstrap build of the native gcc compiler will fail, because
it tries to build its multilib library set by linking against the different
versions of libroot (with and without fpu, etc). We only build one libroot,
so this also fails.
* Figure out how to get page flags (modified/accessed) and implement it ;)
use unmapped/read-only mappings to trigger soft faults
for tracking used/modified flags for ARMv5 and ARMv6
* Fix serial port mapping. Currently kernel uses the haiku_loader identity
mapping for it, but this lives in user virtual address space...
(Need to not use identity mapping in haiku_loader but just
map_physical_memory() there too so it can be handed over without issues).
* Seperate ARM architecture/System-On-Chip IP code. Needed very early on
(Interrupt Controller, Timer IP block). Should use FDT for this too.
* Use FDT to remove all the seperate board definitions in the build. Use a
"minimal ARM architecture version" as the compile flag for ARM support.
This to be able to optimize a kernel build for a specific SoC (or family).
* KDL disasm module.
cf.
http://fxr.watson.org/fxr/source/arch/arm/arm/disassem.c?v=NETBSD
* Add KDL hangman to the boot floppy image for more enjoyment during porting....
* Userland...........
* Bootloader TODOs:
- Better handling of memory ranges. Currently no checks are done, and
memory is assumed to be a single contiguous range, and the "input"
ranges for mmu_init are setup, but never considered.
- Allocate the pagetable range using mmu_allocate() instead of identity
mapping it. That way, there's a bit more flexibility in where to place
it both physically and virtually. This will need a minor change on the
kernel side too (in the early pagetable allocator).