Re: [PATCH 5/5] docs: Be consistent about capitalization of 'Arm'

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> 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 <address@hidden>

Reviewed-by: Alex Bennée <address@hidden>

> ---
> I don't feel very strongly about this change, but it
> looked a bit odd where earlier rearrangements in this
> series meant that some documents had a mix of both styles,
> so I thought I might as well fix all of docs/.
> ---
>  docs/can.txt                     | 2 +-
>  docs/devel/atomics.txt           | 2 +-
>  docs/devel/multi-thread-tcg.txt  | 8 ++++----
>  docs/replay.txt                  | 2 +-
>  docs/specs/fw_cfg.txt            | 2 +-
>  docs/devel/kconfig.rst           | 2 +-
>  docs/devel/loads-stores.rst      | 2 +-
>  docs/devel/tcg.rst               | 2 +-
>  docs/specs/tpm.rst               | 6 +++---
>  docs/system/arm/cpu-features.rst | 4 ++--
>  docs/system/arm/integratorcp.rst | 2 +-
>  docs/system/arm/musicpal.rst     | 2 +-
>  docs/system/arm/nseries.rst      | 2 +-
>  docs/system/arm/palm.rst         | 2 +-
>  docs/system/arm/realview.rst     | 4 ++--
>  docs/system/arm/sx1.rst          | 2 +-
>  docs/system/arm/versatile.rst    | 2 +-
>  docs/system/arm/xscale.rst       | 2 +-
>  docs/user/main.rst               | 8 ++++----
>  19 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/docs/can.txt b/docs/can.txt
> index 9fa6ed51c82..11ed8f2d68b 100644
> --- a/docs/can.txt
> +++ b/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
> diff --git a/docs/devel/atomics.txt b/docs/devel/atomics.txt
> index a4db3a4aaad..67bdf826280 100644
> --- a/docs/devel/atomics.txt
> +++ b/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)
> diff --git a/docs/devel/multi-thread-tcg.txt b/docs/devel/multi-thread-tcg.txt
> index 782bebc28b4..3c85ac0eab9 100644
> --- a/docs/devel/multi-thread-tcg.txt
> +++ b/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.
> diff --git a/docs/replay.txt b/docs/replay.txt
> index f4619a62a3d..70c27edb362 100644
> --- a/docs/replay.txt
> +++ b/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.
>  
> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
> index 08c00bdf44a..8f1ebc66fa4 100644
> --- a/docs/specs/fw_cfg.txt
> +++ b/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)
> diff --git a/docs/devel/kconfig.rst b/docs/devel/kconfig.rst
> index b7bca447046..e5df72b3422 100644
> --- a/docs/devel/kconfig.rst
> +++ b/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
> diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
> index 03aa9e7ff80..0d99eb24c1b 100644
> --- a/docs/devel/loads-stores.rst
> +++ b/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
> diff --git a/docs/devel/tcg.rst b/docs/devel/tcg.rst
> index 4956a30a4e6..4ebde44b9d7 100644
> --- a/docs/devel/tcg.rst
> +++ b/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
> diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst
> index da9eb39ca97..5e61238bc5f 100644
> --- a/docs/specs/tpm.rst
> +++ b/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'.
> diff --git a/docs/system/arm/cpu-features.rst 
> b/docs/system/arm/cpu-features.rst
> index 7495b7b672b..2d5c06cd016 100644
> --- a/docs/system/arm/cpu-features.rst
> +++ b/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
> diff --git a/docs/system/arm/integratorcp.rst 
> b/docs/system/arm/integratorcp.rst
> index 3232b43a08b..e6f050f602b 100644
> --- a/docs/system/arm/integratorcp.rst
> +++ b/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
>  
> diff --git a/docs/system/arm/musicpal.rst b/docs/system/arm/musicpal.rst
> index 35c22212486..9de380edf81 100644
> --- a/docs/system/arm/musicpal.rst
> +++ b/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.
>  
> diff --git a/docs/system/arm/nseries.rst b/docs/system/arm/nseries.rst
> index b000b6d13bb..cd9edf5d88b 100644
> --- a/docs/system/arm/nseries.rst
> +++ b/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
>  
> diff --git a/docs/system/arm/palm.rst b/docs/system/arm/palm.rst
> index 0eabf63e0e7..47ff9b36d46 100644
> --- a/docs/system/arm/palm.rst
> +++ b/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)
> diff --git a/docs/system/arm/realview.rst b/docs/system/arm/realview.rst
> index 8e08eb5da16..65f5be346b1 100644
> --- a/docs/system/arm/realview.rst
> +++ b/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
>  
> diff --git a/docs/system/arm/sx1.rst b/docs/system/arm/sx1.rst
> index 321993bc098..8bce30d4b25 100644
> --- a/docs/system/arm/sx1.rst
> +++ b/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
> diff --git a/docs/system/arm/versatile.rst b/docs/system/arm/versatile.rst
> index 48b6ca0a020..51221c30a48 100644
> --- a/docs/system/arm/versatile.rst
> +++ b/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
>  
> diff --git a/docs/system/arm/xscale.rst b/docs/system/arm/xscale.rst
> index 19da2eff352..89ec93e904e 100644
> --- a/docs/system/arm/xscale.rst
> +++ b/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
>  
> diff --git a/docs/user/main.rst b/docs/user/main.rst
> index ca69f7727d5..bd99b0fdbe9 100644
> --- a/docs/user/main.rst
> +++ b/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.


-- 
Alex Bennée