The ARM port============Note: there are in fact two ports to the ARM architecture, one for 32-bit, and one for 64-bitsystems. They don't have a lot of shared code as the two architectures are very different fromone another.ARM devices are very popular, and especially since the release of the Raspberry Pi, people havebeen requesting that Haiku is ported to it. Unfortunately, limitations in the architecture itselfand the wide diversity of hardware have made this task more complicated, and progress has beenslow. For example, ARM has no standard like the PC is for x86, so concepts as basic as a systemtimer, a bootloader, or a serial port, are different from one machine to another. The situationhas improved with the later generations, as more things were integrated in the CPU core, and u-bootis now well established as the main bootloader for ARM devices.Limitations-----------There will be no support for hardware using architectures older than ARMv5. There will probably beno support for architectures before ARMv7, which require more work on the compiler and OS, forexample due to lack of atomic instructions.Support for high vectors (interrupt vectors stored at the end of the memory space) is required.Information about specific hardware targets-------------------------------------------Over the years, various possible ARM targets have been considered for the Haiku ARM port.We have accumulated some notes and documentation on some of them... toctree::/kernel/arch/arm/allwinner_a10/kernel/arch/arm/beagle/kernel/arch/arm/efikamx/kernel/arch/arm/ipaq/kernel/arch/arm/rpi1/kernel/arch/arm/rpi2/kernel/arch/arm/rpi3/kernel/arch/arm/rpi4TODO list---------Fix pre-ARMv7 support*********************The ARM instruction set has evolved a lot over time, and we have to make a choice: use the oldestversions of the instruction set gives us maximal compatibility, but at the cost of a largeperformance hit on newer systems, as well as extra code being needed in the OS to compensate forthe missing instructions.Currently the cross-tools are compiled to default to ARMv7, Cortex-A8, andhardware floating point. This works around the missing atomic support, seebelow. This should be done by setting the -mcpu,-march and -mfloat-abiswitches at build time, however, they aren't passed on to haikuporterduring the bootstrap build, leading to the ports failing to find thegcc atomic ops again.Determine how to handle atomic functions on ARM***********************************************GCC inlines are not supported, since the instructionset is ill-equiped forthis on older (pre-ARMv7) architectures. We possibly have to do somethingsimilar to the linux kernel helper functions for this....On ARMv7 and later, this is not an issue. Not sure about ARMv6, we may getit going there. ARMv5 definitely needs us to write some code, but is itworth the trouble?Fix multilib support********************ARM-targetting versions of gcc are usually built with multilib support, toallow targetting architectures with or without FPU, and using either ARMor 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 sometricks to get a separate libgcc and libstdc++ for the kernel (without C++11threads support, as that would not build in the kernel). Building this libis not done in a multilib-aware way, so you get one only for the defaultarch/cpu/abi the compiler is targetting. This is good enough, as long as thatarch is the one we want to use for the kernel...Later on, the bootstrap build of the native gcc compiler will fail, becauseit tries to build its multilib library set by linking against the differentversions of libroot (with and without fpu, etc). We only build one libroot,so this also fails.The current version of the x86_64 compiler appears is using multilib (to build for both 32 and 64bit targets) and is working fine, so it's possible that most of the issues in this area havealready been fixed.Seperate ARM architecture/System-On-Chip IP code************************************************The early work on the ARM port resulted in lots of board specific code being added to early stagesof the kernel. Ideally, this would not be needed, the kernel would manage to initialize itselfmostly in a platform independant way, and get the needed information from the FDT passed by thebootloader. The difficulty is that on older ARM versions, even the interrupt controller and timerscan be different on each machine.KDL disasm module*****************Currently it is not possible to disassemble code in the kernel debugger.The `NetBSD disassembler <http://fxr.watson.org/fxr/source/arch/arm/arm/disassem.c?v=NETBSD>`_ could be ported and used for this.Userland********Even if poking around in the kernel debugger is fun, users will want to run real applications someday.Other resources---------------About flatenned device trees***************************** http://www.denx.de/wiki/U-Boot/UBootFdtInfo* http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29* http://elinux.org/images/4/4e/Glikely-powerpc-porting-guide.pdf* http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf* http://www.bsdcan.org/2010/schedule/events/171.en.html* http://www.devicetree.org/ (unofficial bindings)* http://www.devicetree.org/Device_Tree_Usage* http://elinux.org/Device_TreesAbout openfirmware******************http://www.openfirmware.info/BindingsAbout floating point numbers handling on ARM********************************************https://wiki.debian.org/ArmHardFloatPort/VfpComparison