1The ARM port 2============ 3 4Note: there are in fact two ports to the ARM architecture, one for 32-bit, and one for 64-bit 5systems. They don't have a lot of shared code as the two architectures are very different from 6one another. 7 8ARM devices are very popular, and especially since the release of the Raspberry Pi, people have 9been requesting that Haiku is ported to it. Unfortunately, limitations in the architecture itself 10and the wide diversity of hardware have made this task more complicated, and progress has been 11slow. For example, ARM has no standard like the PC is for x86, so concepts as basic as a system 12timer, a bootloader, or a serial port, are different from one machine to another. The situation 13has improved with the later generations, as more things were integrated in the CPU core, and u-boot 14is now well established as the main bootloader for ARM devices. 15 16Limitations 17----------- 18 19There will be no support for hardware using architectures older than ARMv5. There will probably be 20no support for architectures before ARMv7, which require more work on the compiler and OS, for 21example due to lack of atomic instructions. 22 23Support for high vectors (interrupt vectors stored at the end of the memory space) is required. 24 25Information about specific hardware targets 26------------------------------------------- 27 28Over the years, various possible ARM targets have been considered for the Haiku ARM port. 29We have accumulated some notes and documentation on some of them. 30 31.. toctree:: 32 33 /kernel/arch/arm/allwinner_a10 34 /kernel/arch/arm/beagle 35 /kernel/arch/arm/efikamx 36 /kernel/arch/arm/ipaq 37 /kernel/arch/arm/rpi1 38 /kernel/arch/arm/rpi2 39 /kernel/arch/arm/rpi3 40 /kernel/arch/arm/rpi4 41 42TODO list 43--------- 44 45Fix pre-ARMv7 support 46********************* 47 48The ARM instruction set has evolved a lot over time, and we have to make a choice: use the oldest 49versions of the instruction set gives us maximal compatibility, but at the cost of a large 50performance hit on newer systems, as well as extra code being needed in the OS to compensate for 51the missing instructions. 52 53Currently the cross-tools are compiled to default to ARMv7, Cortex-A8, and 54hardware floating point. This works around the missing atomic support, see 55below. This should be done by setting the -mcpu,-march and -mfloat-abi 56switches at build time, however, they aren't passed on to haikuporter 57during the bootstrap build, leading to the ports failing to find the 58gcc atomic ops again. 59 60Determine how to handle atomic functions on ARM 61*********************************************** 62 63GCC inlines are not supported, since the instructionset is ill-equiped for 64this on older (pre-ARMv7) architectures. We possibly have to do something 65similar to the linux kernel helper functions for this.... 66 67On ARMv7 and later, this is not an issue. Not sure about ARMv6, we may get 68it going there. ARMv5 definitely needs us to write some code, but is it 69worth the trouble? 70 71Fix multilib support 72******************** 73 74ARM-targetting versions of gcc are usually built with multilib support, to 75allow targetting architectures with or without FPU, and using either ARM 76or Thumb instructions. This bascally means a different libgcc and libstdc++ 77are built for each combination. 78 79The cross-tools can be built with multilib support. However, we do some 80tricks to get a separate libgcc and libstdc++ for the kernel (without C++11 81threads support, as that would not build in the kernel). Building this lib 82is not done in a multilib-aware way, so you get one only for the default 83arch/cpu/abi the compiler is targetting. This is good enough, as long as that 84arch is the one we want to use for the kernel... 85 86Later on, the bootstrap build of the native gcc compiler will fail, because 87it tries to build its multilib library set by linking against the different 88versions of libroot (with and without fpu, etc). We only build one libroot, 89so this also fails. 90 91The current version of the x86_64 compiler appears is using multilib (to build for both 32 and 64 92bit targets) and is working fine, so it's possible that most of the issues in this area have 93already been fixed. 94 95Seperate ARM architecture/System-On-Chip IP code 96************************************************ 97 98The early work on the ARM port resulted in lots of board specific code being added to early stages 99of the kernel. Ideally, this would not be needed, the kernel would manage to initialize itself 100mostly in a platform independant way, and get the needed information from the FDT passed by the 101bootloader. The difficulty is that on older ARM versions, even the interrupt controller and timers 102can be different on each machine. 103 104KDL disasm module 105***************** 106 107Currently it is not possible to disassemble code in the kernel debugger. 108 109The `NetBSD disassembler <http://fxr.watson.org/fxr/source/arch/arm/arm/disassem.c?v=NETBSD>`_ could be ported and used for this. 110 111Userland 112******** 113 114Even if poking around in the kernel debugger is fun, users will want to run real applications someday. 115 116Other resources 117--------------- 118 119About flatenned device trees 120**************************** 121 122* http://www.denx.de/wiki/U-Boot/UBootFdtInfo 123* http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29 124* http://elinux.org/images/4/4e/Glikely-powerpc-porting-guide.pdf 125* http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf 126* http://www.bsdcan.org/2010/schedule/events/171.en.html 127* http://www.devicetree.org/ (unofficial bindings) 128* http://www.devicetree.org/Device_Tree_Usage 129* http://elinux.org/Device_Trees 130 131About openfirmware 132****************** 133 134http://www.openfirmware.info/Bindings 135 136About floating point numbers handling on ARM 137******************************************** 138 139https://wiki.debian.org/ArmHardFloatPort/VfpComparison 140