At the time of its inception (1983), ARM stood for “Acorn RISC Machine”, referencing the Cambridge, England based company, Acorn Computers. Their Acorn Archimedes was one of the first personal computers (PC) to use a RISC processor. Later in 1990, ARM Ltd. was founded as a joint venture between Acorn Computers, VLSI Technology and Apple. The meaning of the acronym ARM changed to “Advanced RISC Machines” at Apple's request, them not wanting to advertise any ties with their former competitor.

Today, ARM Ltd. owns the rights to the ARM instruction set architecture (ISA) and to individual components used in processor implementations. These Intellectual Properties (IPs) are leased to other companies such as NXP and Microchip for them to develop their own implementation of the ARM standard (e.g.: the i.MX8M SoC that we are working on). While certain elements such as the Generic Interrupt Controller (GIC) are almost guaranteed to be found in each CPU implementation, other such as the Memory Controllers are often vendor specific. Meanwhile, components such as the System MMU (commonly known as IOMMU on x86) may be absent altogether.

ARM processors can usually be classified according to type and generation. The type refers to their intended use:

• Cortex-A (Applications): Focused on performance and capable of running an Operating System; this has been the architecture to go for mobile devices and, as of very recent times, it has become an important contender in the personal computing (laptops & workstations) and even the servers market!
• Cortex-M (Microcontrollers): Focused on simplicity, reduced power consumption and, of course, small prices! Used for accomplishing simple automation tasks in all sorts of electronic equipment (e.g., coffee machines and all sort of appliances, Internet of Things devices like smart lightbulbs etc.);
• Cortex-R (Realtime): Focused on real-time applications. Needs to guarantee a bounded reponse time and, msot importantly, fault tolerance (with important applicability in cars, medical devices, oh, and let's not forget: space!).

In terms of generational versioning, we will only present the three most recent:

• ARMv7: Older, 32-bit architecture. Still possible to encounter it;
• ARMv8: Introduced in 2011, it is 64-bit but has a 32-bit compatiblity mode; most common today.
• ARMv9: A very recent (2021) addition, not yet widely used; introduces some interesting security & tracing features.

In terms of software support, although traditional Operating Systems (Windows), programs and games written for the x86 ISA will not run as-is on a ARM device, as both architectures mostly implement the same features (all can do arithmetic/logic operations, memory read/write, even cryptographic and graphic accelerations) and given that modern compilers (GCC, CLang) have extensive support for almost all of them, an application may be ported to another platform using a simple re-compilation (there are, of course, exceptions in some code bases). Additionally, if this is not feasible (no access to the source code), emulator software can be employed to automatically translate instructions between different ISAs (with some – more or less – performance hit; see Apple's Rosetta for a nice example).

Recall earlier that a CPU's ISA will make sure that applications remain compatible with newer models. For x86, this holds even for low-level software such as entire Operating Systems being able to run unchanged across tens of years of CPU model advances. This is so because not only the ISA was standardized, but the entire System Architecture (which is amazing in its own right)!

Unfortunately, this is the most important shortcoming of the ARM platform: every System-on-Chip manufacturer changes the inner workings of a system – the set of components, their behaviour and the addresses they are mapped to – even between versions and very small variations of a model! Although compiled programs will still run on the CPU, those that use hardcoded addresses for a specific peripheral will often crash when trying to communicate with it. This issue is somewhat eased by a well-designed software architecture and development model for low-level components (firmware, bootloader, OS kernel), of which you will see examples throughout the labs.