docs: Be consistent about capitalization of 'Arm'

The company 'Arm' went through a rebranding some years back
involving a recapitalization from 'ARM' to 'Arm'. As a result
our documentation is a bit inconsistent between the two forms.
It's not worth trying to update everywhere in QEMU, but it's
easy enough to make docs/ consistent.

Note that "ARMv8" and similar architecture names, and
older CPU names like "ARM926" still retain all-caps.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-id: 20200309215818.2021-6-peter.maydell@linaro.org

docs/can.txt

@@ -13,7 +13,7 @@ controller is implemented.
 
 The PCI addon card hardware has been selected as the first CAN
 interface to implement because such device can be easily connected
-to systems with different CPU architectures (x86, PowerPC, ARM, etc.).
+to systems with different CPU architectures (x86, PowerPC, Arm, etc.).
 
 The project has been initially started in frame of RTEMS GSoC 2013
 slot by Jin Yang under our mentoring  The initial idea was to provide generic

docs/devel/atomics.txt

@@ -87,7 +87,7 @@ Sequentially consistent loads and stores can be done using:
     atomic_xchg(ptr, val) for stores
 
 However, they are quite expensive on some platforms, notably POWER and
-ARM.  Therefore, qemu/atomic.h provides two primitives with slightly
+Arm.  Therefore, qemu/atomic.h provides two primitives with slightly
 weaker constraints:
 
     typeof(*ptr) atomic_mb_read(ptr)

docs/devel/kconfig.rst

@@ -8,7 +8,7 @@ time different targets can share large amounts of code.  For example,
 a POWER and an x86 board can run the same code to emulate a PCI network
 card, even though the boards use different PCI host bridges, and they
 can run the same code to emulate a SCSI disk while using different
-SCSI adapters.  ARM, s390 and x86 boards can all present a virtio-blk
+SCSI adapters.  Arm, s390 and x86 boards can all present a virtio-blk
 disk to their guests, but with three different virtio guest interfaces.
 
 Each QEMU target enables a subset of the boards, devices and buses that

docs/devel/loads-stores.rst

@@ -302,7 +302,7 @@ way QEMU defines the view of memory that a device or CPU has.
 or bus fabric.)
 
 Each CPU has an AddressSpace. Some kinds of CPU have more than
-one AddressSpace (for instance ARM guest CPUs have an AddressSpace
+one AddressSpace (for instance Arm guest CPUs have an AddressSpace
 for the Secure world and one for NonSecure if they implement TrustZone).
 Devices which can do DMA-type operations should generally have an
 AddressSpace. There is also a "system address space" which typically

docs/devel/multi-thread-tcg.txt

@@ -227,7 +227,7 @@ minimise contention.
 (Current solution)
 
 MMIO access automatically serialises hardware emulation by way of the
-BQL. Currently ARM targets serialise all ARM_CP_IO register accesses
+BQL. Currently Arm targets serialise all ARM_CP_IO register accesses
 and also defer the reset/startup of vCPUs to the vCPU context by way
 of async_run_on_cpu().
 
@@ -268,7 +268,7 @@ ordered backends this could become a NOP.
 Aside from explicit standalone memory barrier instructions there are
 also implicit memory ordering semantics which comes with each guest
 memory access instruction. For example all x86 load/stores come with
-fairly strong guarantees of sequential consistency where as ARM has
+fairly strong guarantees of sequential consistency whereas Arm has
 special variants of load/store instructions that imply acquire/release
 semantics.
 
@@ -317,7 +317,7 @@ x86 cmpxchg instruction.
 
 The second type offer a pair of load/store instructions which offer a
 guarantee that a region of memory has not been touched between the
-load and store instructions. An example of this is ARM's ldrex/strex
+load and store instructions. An example of this is Arm's ldrex/strex
 pair where the strex instruction will return a flag indicating a
 successful store only if no other CPU has accessed the memory region
 since the ldrex.
@@ -339,7 +339,7 @@ CURRENT OPEN QUESTIONS:
 
 The TCG provides a number of atomic helpers (tcg_gen_atomic_*) which
 can be used directly or combined to emulate other instructions like
-ARM's ldrex/strex instructions. While they are susceptible to the ABA
+Arm's ldrex/strex instructions. While they are susceptible to the ABA
 problem so far common guests have not implemented patterns where
 this may be a problem - typically presenting a locking ABI which
 assumes cmpxchg like semantics.

docs/devel/tcg.rst

@@ -83,7 +83,7 @@ memory until the end of the translation block.  This is done for internal
 emulation state that is rarely accessed directly by the program and/or changes
 very often throughout the execution of a translation block---this includes
 condition codes on x86, delay slots on SPARC, conditional execution on
-ARM, and so on.  This state is stored for each target instruction, and
+Arm, and so on.  This state is stored for each target instruction, and
 looked up on exceptions.
 
 MMU emulation

docs/replay.txt

@@ -19,7 +19,7 @@ Deterministic replay has the following features:
    the memory, state of the hardware devices, clocks, and screen of the VM.
  * Writes execution log into the file for later replaying for multiple times
    on different machines.
- * Supports i386, x86_64, and ARM hardware platforms.
+ * Supports i386, x86_64, and Arm hardware platforms.
  * Performs deterministic replay of all operations with keyboard and mouse
    input devices.
 

docs/specs/fw_cfg.txt

@@ -82,7 +82,7 @@ Selector Register IOport: 0x510
 Data Register IOport:     0x511
 DMA Address IOport:       0x514
 
-=== ARM Register Locations ===
+=== Arm Register Locations ===
 
 Selector Register address: Base + 8 (2 bytes)
 Data Register address:     Base + 0 (8 bytes)

docs/specs/tpm.rst

@@ -25,7 +25,7 @@ QEMU files related to TPM TIS interface:
 
 Both an ISA device and a sysbus device are available. The former is
 used with pc/q35 machine while the latter can be instantiated in the
-ARM virt machine.
+Arm virt machine.
 
 CRB interface
 -------------
@@ -331,7 +331,7 @@ In case a pSeries machine is emulated, use the following command line:
     -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0 \
     -drive file=test.img,format=raw,if=none,id=drive-virtio-disk0
 
-In case an ARM virt machine is emulated, use the following command line:
+In case an Arm virt machine is emulated, use the following command line:
 
 .. code-block:: console
 
@@ -346,7 +346,7 @@ In case an ARM virt machine is emulated, use the following command line:
     -drive if=pflash,format=raw,file=flash0.img,readonly \
     -drive if=pflash,format=raw,file=flash1.img
 
-  On ARM, ACPI boot with TPM is not yet supported.
+  On Arm, ACPI boot with TPM is not yet supported.
 
 In case SeaBIOS is used as firmware, it should show the TPM menu item
 after entering the menu with 'ESC'.

docs/system/arm/cpu-features.rst

@@ -5,9 +5,9 @@ CPU features are optional features that a CPU of supporting type may
 choose to implement or not.  In QEMU, optional CPU features have
 corresponding boolean CPU proprieties that, when enabled, indicate
 that the feature is implemented, and, conversely, when disabled,
-indicate that it is not implemented. An example of an ARM CPU feature
+indicate that it is not implemented. An example of an Arm CPU feature
 is the Performance Monitoring Unit (PMU).  CPU types such as the
-Cortex-A15 and the Cortex-A57, which respectively implement ARM
+Cortex-A15 and the Cortex-A57, which respectively implement Arm
 architecture reference manuals ARMv7-A and ARMv8-A, may both optionally
 implement PMUs.  For example, if a user wants to use a Cortex-A15 without
 a PMU, then the `-cpu` parameter should contain `pmu=off` on the QEMU

docs/system/arm/integratorcp.rst

@@ -1,7 +1,7 @@
 Integrator/CP (``integratorcp``)
 ================================
 
-The ARM Integrator/CP board is emulated with the following devices:
+The Arm Integrator/CP board is emulated with the following devices:
 
 -  ARM926E, ARM1026E, ARM946E, ARM1136 or Cortex-A8 CPU
 

docs/system/arm/musicpal.rst

@@ -4,7 +4,7 @@ Freecom MusicPal (``musicpal``)
 The Freecom MusicPal internet radio emulation includes the following
 elements:
 
--  Marvell MV88W8618 ARM core.
+-  Marvell MV88W8618 Arm core.
 
 -  32 MB RAM, 256 KB SRAM, 8 MB flash.
 

docs/system/arm/nseries.rst

@@ -4,7 +4,7 @@ Nokia N800 and N810 tablets (``n800``, ``n810``)
 Nokia N800 and N810 internet tablets (known also as RX-34 and RX-44 /
 48) emulation supports the following elements:
 
--  Texas Instruments OMAP2420 System-on-chip (ARM 1136 core)
+-  Texas Instruments OMAP2420 System-on-chip (ARM1136 core)
 
 -  RAM and non-volatile OneNAND Flash memories
 

docs/system/arm/palm.rst

@@ -4,7 +4,7 @@ Palm Tungsten|E PDA (``cheetah``)
 The Palm Tungsten|E PDA (codename \"Cheetah\") emulation includes the
 following elements:
 
--  Texas Instruments OMAP310 System-on-chip (ARM 925T core)
+-  Texas Instruments OMAP310 System-on-chip (ARM925T core)
 
 -  ROM and RAM memories (ROM firmware image can be loaded with
    -option-rom)

docs/system/arm/realview.rst

@@ -1,7 +1,7 @@
 Arm Realview boards (``realview-eb``, ``realview-eb-mpcore``, ``realview-pb-a8``, ``realview-pbx-a9``)
 ======================================================================================================
 
-Several variants of the ARM RealView baseboard are emulated, including
+Several variants of the Arm RealView baseboard are emulated, including
 the EB, PB-A8 and PBX-A9. Due to interactions with the bootloader, only
 certain Linux kernel configurations work out of the box on these boards.
 
@@ -14,7 +14,7 @@ The following devices are emulated:
 
 -  ARM926E, ARM1136, ARM11MPCore, Cortex-A8 or Cortex-A9 MPCore CPU
 
--  ARM AMBA Generic/Distributed Interrupt Controller
+-  Arm AMBA Generic/Distributed Interrupt Controller
 
 -  Four PL011 UARTs
 

docs/system/arm/sx1.rst

@@ -4,7 +4,7 @@ Siemens SX1 (``sx1``, ``sx1-v1``)
 The Siemens SX1 models v1 and v2 (default) basic emulation. The
 emulation includes the following elements:
 
--  Texas Instruments OMAP310 System-on-chip (ARM 925T core)
+-  Texas Instruments OMAP310 System-on-chip (ARM925T core)
 
 -  ROM and RAM memories (ROM firmware image can be loaded with
    -pflash) V1 1 Flash of 16MB and 1 Flash of 8MB V2 1 Flash of 32MB

docs/system/arm/versatile.rst

@@ -1,7 +1,7 @@
 Arm Versatile boards (``versatileab``, ``versatilepb``)
 =======================================================
 
-The ARM Versatile baseboard is emulated with the following devices:
+The Arm Versatile baseboard is emulated with the following devices:
 
 -  ARM926E, ARM1136 or Cortex-A8 CPU
 

docs/system/arm/xscale.rst

@@ -4,7 +4,7 @@ Sharp XScale-based PDA models (``akita``, ``borzoi``, ``spitz``, ``terrier``)
 The XScale-based clamshell PDA models (\"Spitz\", \"Akita\", \"Borzoi\"
 and \"Terrier\") emulation includes the following peripherals:
 
--  Intel PXA270 System-on-chip (ARM V5TE core)
+-  Intel PXA270 System-on-chip (ARMv5TE core)
 
 -  NAND Flash memory
 

docs/user/main.rst

@@ -35,7 +35,7 @@ QEMU user space emulation has the following notable features:
    On Linux, QEMU can emulate the ``clone`` syscall and create a real
    host thread (with a separate virtual CPU) for each emulated thread.
    Note that not all targets currently emulate atomic operations
-   correctly. x86 and ARM use a global lock in order to preserve their
+   correctly. x86 and Arm use a global lock in order to preserve their
    semantics.
 
 QEMU was conceived so that ultimately it can emulate itself. Although it
@@ -173,11 +173,11 @@ Other binaries
 user mode (Alpha)
 ``qemu-alpha`` TODO.
 
-user mode (ARM)
+user mode (Arm)
 ``qemu-armeb`` TODO.
 
-user mode (ARM)
-``qemu-arm`` is also capable of running ARM \"Angel\" semihosted ELF
+user mode (Arm)
+``qemu-arm`` is also capable of running Arm \"Angel\" semihosted ELF
 binaries (as implemented by the arm-elf and arm-eabi Newlib/GDB
 configurations), and arm-uclinux bFLT format binaries.