1,885
edits
Changes
no edit summary
ARMv8 has two execution states which support 3 [[Instruction Set Architecture|Instruction Set Architectures]]:
=== AArch32 === AArch32 is a 32-bit execution state which supports these instruction sets:* A32 (often just called "ARM") - the traditional 32-bit instruction set used in ARMv7 (with minor differences).* T32 (Thumb) - a mixed 16- and 32-bit fixed-length instruction set for increased code density, previously referred to as Thumb2. === AArch64 ==AArch64 is a 64-bit execution state which supports these instruction sets:* A64 - a 64-bit capable instruction set encoded into 32-bit fixed-length instructions. == ARMv8 Profiles == There are different ''profiles'' for ARMv8 devices, including:
* ARMv8A - ''Application'' - For user-level application processors, i.e., servers, smartphones, tablets. ARMv8-A devices support the AArch64 instruction state, and may optionally support the AArch32 instruction state.
* ARMv8R - ''Real-time'' - For real-time applications, which require that hardware events (such as interrupts) receive a response within a (short) hard deadline, such as a fuel injection system. ARMv8-R devices support only the AArch32 execution state, and do not support the AArch64 execution state.
Although most 32-bit development boards and general devices (such as the Beagle Bone, Wanda Board, Panda Board, CubieBoard, CubieTruck, Radaxa Rock, Utilite, TrimSlice, and so forth) use a version of the U-Boot bootloader, these are almost always customized and operate in a way that is unique to the device. For example, some U-Boot versions boot only from some combination of NAND/NOR SPI-connected flash memory, eMMC, SD card, or disk; some load the kernel using a configuration stored on the boot device, while others store the boot configuration in the device that holds the U-Boot bootloader (which may be different); some load the U-Boot software itself directly from a particular block offset or FAT slot number, while others load it by name, or load it from SPI-connected flash; and so forth.
Dennis Gilmore of Red Hat and some others have attempted to unify the U-Boot situation; however, this has been an uphill battle, as new 32-bit ARM devices have continued to flood onto the market.
In addition to the boot environment, the machine description (describing the devices which make up the system in addition to the CPU) was originally done using a "machine number" passed in from the boot environment. This led to the creation of incompatible patch sets for the kernel, such that the kernel could not be built so that it would work on a variety of devices - it had to be built for a specific machine.
* Development boards / hackable devices
Development boards will probably initially ship with u-Boot based systemswith or without UEFI, but it is hoped that SBSA will become simple and straightforward enough that it will eventually gain a footing in this area too/or EBBR lead to unification of these approaches. The [http://96boards.org 96boards] project is having a significant impact in bringing under-$100 ARMv8 Consumer Edition (mobile processor-based) and under-$500 Enterprise Edition (enterprise server processor-based) development boards to market; while the Consumer Edition (CE) boards ship with u-boot and/or uefi and/or the Android bootloader, the Enterprise Edition (EE) boards are expected to conform to SBSA.
== Implementations of ARMv8 ==
== Confusing Numbering Schemes ==
The ARM space is littered with really awful very confusing (and conflicting ) numbering schemes.
* Early ARM chips had numbers that were different from the corresponding architecture levels. For example, the ARM11 processor is an ARMv6 chip, which is much lower-performing than other parts with lower numbers, including the ARMv7-level Cortex-A5, -A7, -A8, and -A9 devices.
* Cortex designations are not in order of release date, features, or power consumption, and are only loosely in order by performance. Cortex-A8 (single-core only) and Cortex-A9 (available in single- and multi-core) are some of the older designs in the series; Cortex-A15 chips add hardware virtualization support. The ARMv7 (32 bit) Cortex-A12, Cortex-A7, and Cortex-A5 designs followed, with varying power/performance profiles. Cortex-A35, -A53, -A55, -A57, -A72, -A73, -A75, and -A75 A76 chips are ARMv8ARMv8A.* Other companies have introduced chips with confusingly similar designations. The Apple A7 chip is not an ARM design and has nothing to do with the Cortex-A7 (or any other Cortex core); it is roughly in the same performance category as a dual-core Cortex-A53. Allwinner and AMD have also used chip designations starting with A (Allwinner A10, A20, and A80, and AMD Opteron A1100, for example); these are unrelated to the Apple A-series chips and to the Cortex A designations. Likewise, the Nvidia K1 is unrelated to the AMD K12.
== big.LITTLE ==
Typical pairings are:
* Cortex-A17 and Cortex-A7
* (Cortex-A76, -A75, -A73, -A72 , or Cortex-A57) and (Cortex-A35 or Cortex-A53)
The advantage to big.LITTLE lies in the ability to turn off cores that are not needed. Thus, when a device such as a cellphone is performing background tasks (screen off), one little core may be used; when the device is performing basic tasks, a couple of little cores or one big core may be used; and when very demanding tasks are performed, several big cores (or all of the cores) may be turned on.
Wikipedia has a [http://en.wikipedia.org/wiki/ARM_big.LITTLE page on big.LITTLE] that includes a list of known implementations.
Arm's dyanamIQ technology is an evolution of the big.LITTLE concept.