This article is the tenth in a series going over the changes made in the UEFI 2.4 specification. This time we take a look at the ARM AArch64 processor bindings. AArch64 is the term used to describe the new 64-bit extensions to the ARM processor architecture. The first CPUs based on this architecture are expected to ship this year.
UEFI cares about processor bindings. Why? If all of the C code in your system was produced by the same compiler and linker (like GCC or Microsoft Visual Studio), then this would be less important. But since UEFI was designed to allow driver and application binaries written by one company to be called by the binaries written by another company. Those two companies might be using a different compiler and those compilers might use a different contract or convention or binding as to how parameters are passed. From personal experience, this leads to disastrous, hard-to-debug scenarios where you think you're passing A but the function thinks you passed B.
So section 126.96.36.199 statest explicitly that the calling convention must follow the one described in the Procedure Call Standard for the ARM 64-bit Architecture Version A-0.06 or later. It also lists some additional restrictions about usage of optional ARM instruction set features, it must operate in little-endian mode (UEFI is little endian) and the stack must be 16-byte aligned.
The UEFI specification further describes the operating environment of the UEFI drivers and applications (section 2.3.6): uniprocessor, highest-possible privilege level, unaligned memory access enabled, MMU enabled, cache enabled, floating point enabled, 4KB page tables, interrupts and generic timer enabled, 128KB stacks space. Finally, there are some rules detailing how ARM memory types map to UEFI memory types (188.8.131.52) and how pieces of code using from other operating environments can call into UEFI (184.108.40.206).
ARM AArch64 processors are fully supported in UEFI. For those of you following the tianocore.org progress, you can see that all of the information related to build tools and processor bindings is present. Love to play with a develop board, but all of the ARM v8 cores I know of still require an NDA even to talk about.