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 40TODO list 41--------- 42 43Fix pre-ARMv7 support 44********************* 45 46The ARM instruction set has evolved a lot over time, and we have to make a choice: use the oldest 47versions of the instruction set gives us maximal compatibility, but at the cost of a large 48performance hit on newer systems, as well as extra code being needed in the OS to compensate for 49the missing instructions. 50 51Currently the cross-tools are compiled to default to ARMv7, Cortex-A8, and 52hardware floating point. This works around the missing atomic support, see 53below. This should be done by setting the -mcpu,-march and -mfloat-abi 54switches at build time, however, they aren't passed on to haikuporter 55during the bootstrap build, leading to the ports failing to find the 56gcc atomic ops again. 57 58It seems this create other problems, mainly because the UEFI environment for ARM is not supposed to 59handle floating point registers. So, the softfloat ABI should be used there instead. To be able 60to build both "soft float" and "hard float" code, we need multilib support, see below. 61 62Determine how to handle atomic functions on ARM 63*********************************************** 64 65GCC inlines are not supported, since the instructionset is ill-equiped for 66this on older (pre-ARMv7) architectures. We possibly have to do something 67similar to the linux kernel helper functions for this.... 68 69On ARMv7 and later, this is not an issue. Not sure about ARMv6, we may get 70it going there. ARMv5 definitely needs us to write some code, but is it 71worth the trouble? 72 73Fix multilib support 74******************** 75 76ARM-targetting versions of gcc are usually built with multilib support, to 77allow targetting architectures with or without FPU, and using either ARM 78or Thumb instructions. This bascally means a different libgcc and libstdc++ 79are built for each combination. 80 81The cross-tools can be built with multilib support. However, we do some 82tricks to get a separate libgcc and libstdc++ for the kernel (without C++11 83threads support, as that would not build in the kernel). Building this lib 84is not done in a multilib-aware way, so you get one only for the default 85arch/cpu/abi the compiler is targetting. This is good enough, as long as that 86arch is the one we want to use for the kernel... 87 88Later on, the bootstrap build of the native gcc compiler will fail, because 89it tries to build its multilib library set by linking against the different 90versions of libroot (with and without fpu, etc). We only build one libroot, 91so this also fails. 92 93The current version of the x86_64 compiler appears is using multilib (to build for both 32 and 64 94bit targets) and is working fine, so it's possible that most of the issues in this area have 95already been fixed. 96 97Figure out how to get page flags (modified/accessed) and implement it 98********************************************************************* 99 100use unmapped/read-only mappings to trigger soft faults for tracking used/modified flags for ARMv5 and ARMv6 101 102Fix serial port mapping 103*********************** 104 105Currently kernel uses the haiku_loader identity 106mapping for it, but this lives in user virtual address space... 107(Need to not use identity mapping in haiku_loader but just 108map_physical_memory() there too so it can be handed over without issues). 109 110Seperate ARM architecture/System-On-Chip IP code 111************************************************ 112 113The early work on the ARM port resulted in lots of board specific code being added to early stages 114of the kernel. Ideally, this would not be needed, the kernel would manage to initialize itself 115mostly in a platform independant way, and get the needed information from the FDT passed by the 116bootloader. The difficulty is that on older ARM versions, even the interrupt controller and timers 117can be different on each machine. 118 119KDL disasm module 120***************** 121 122Currently it is not possible to disassemble code in the kernel debugger. 123 124The `NetBSD disassembler <http://fxr.watson.org/fxr/source/arch/arm/arm/disassem.c?v=NETBSD>`_ could be ported and used for this. 125 126Add KDL hangman to the boot image 127********************************* 128 129for more enjoyment during porting.... 130 131Userland 132******** 133 134Even if KDL hangman is fun, users will want to run real applications someday. 135 136Bootloader TODOs 137**************** 138 139- Better handling of memory ranges. Currently no checks are done, and 140 memory is assumed to be a single contiguous range, and the "input" 141 ranges for mmu_init are setup, but never considered. 142- Allocate the pagetable range using mmu_allocate() instead of identity 143 mapping it. That way, there's a bit more flexibility in where to place 144 it both physically and virtually. This will need a minor change on the 145 kernel side too (in the early pagetable allocator). 146 147Other resources 148--------------- 149 150About flatenned device trees 151**************************** 152 153* http://www.denx.de/wiki/U-Boot/UBootFdtInfo 154* http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29 155* http://elinux.org/images/4/4e/Glikely-powerpc-porting-guide.pdf 156* http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf 157* http://www.bsdcan.org/2010/schedule/events/171.en.html 158* http://www.devicetree.org/ (unofficial bindings) 159* http://www.devicetree.org/Device_Tree_Usage 160* http://elinux.org/Device_Trees 161 162About openfirmware 163****************** 164 165http://www.openfirmware.info/Bindings 166 167About floating point numbers handling on ARM 168******************************************** 169 170https://wiki.debian.org/ArmHardFloatPort/VfpComparison 171