haiku/docs/develop/ports/arm/todo.txt
Adrien Destugues 5b172de123 Update some docs for the ARM port.
* Add info on Allwinner A10 SOCs, which may be a worthwile target.
* Add info about the Linaro QEmu for emulating the BeagleBoard.
* Add more TODOs for PM aftermath.
2014-04-28 22:24:04 +02:00

60 lines
3.0 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).
* Research stack unwinding to implement backtrace support for KDL & friends.
* B_MAX_CPU_COUNT should be fixed to be a more sensible future-proof value then 1
* 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...........