Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-08 05:43:53 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

doc: Set correct syntax highlighting style

Browse source 
Several code blocks do not specify a language for syntax
highlighting. This results in Sphinx using a default highlighter
which is Python.

This patch adds the correct language to each code block that doesn't
already specify it.

Change-Id: Icce1949aabfdc11a334a42d49edf55fa673cddc3
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
This commit is contained in:
Paul Beesley 2019-03-13 15:11:04 +00:00
parent 8f62ca7b30
commit 29c0252959
17 changed files with 71 additions and 71 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/components/romlib-design.rst
View file

@ -106,7 +106,7 @@ The environment variable ``CROSS_COMPILE`` must be set as per the user guide.
In the below example the usage of ROMLIB together with mbed TLS is demonstrated
to showcase the benefits of library at ROM - it's not mandatory.
::
.. code:: shell
make PLAT=fvp \
MBEDTLS_DIR=</path/to/mbedtls/> \

2
docs/components/sdei.rst
View file

@ -224,7 +224,7 @@ activity, such as receiving a Secure interrupt or an exception.
The SDEI dispatcher implementation provides ``sdei_dispatch_event()`` API for
this purpose. The API has the following signature:
::
.. code:: c
int sdei_dispatch_event(int ev_num);

2
docs/components/secure-partition-manager-design.rst
View file

@ -130,7 +130,7 @@ First, build the Standalone MM Secure Partition. To build it, refer to the
Then build TF-A with SPM support and include the Standalone MM Secure Partition
image in the FIP:
::
.. code:: shell
BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \
make PLAT=fvp ENABLE_SPM=1 ARM_BL31_IN_DRAM=1 fip all

2
docs/design/auth-framework.rst
View file

@ -408,7 +408,7 @@ An IPL must provide functions with the following prototypes:
An IPL for each type must be registered using the following macro:
::
.. code:: c
REGISTER_IMG_PARSER_LIB(_type, _name, _init, _check_int, _get_param)

8
docs/design/firmware-design.rst
View file

@ -2304,7 +2304,7 @@ result in build error. Subscribing to an undefined event however won't.
Subscribed handlers must be of type ``pubsub_cb_t``, with following function
signature:
::
.. code:: c
typedef void* (*pubsub_cb_t)(const void *arg);
@ -2331,7 +2331,7 @@ A publisher that wants to publish event ``foo`` would:
- Define the event ``foo`` in the ``pubsub_events.h``.
::
.. code:: c
REGISTER_PUBSUB_EVENT(foo);
@ -2467,7 +2467,7 @@ respectively.
From outside TF-A, timestamps for individual CPUs can be retrieved by calling
into ``pmf_smc_handler()``.
.. code:: c
::
Interface : pmf_smc_handler()
Argument : unsigned int smc_fid, u_register_t x1,
@ -2597,7 +2597,7 @@ Platform may choose to not define straight the toolchain target architecture
directive by defining ``MARCH32_DIRECTIVE``.
I.e:
::
.. code:: make
MARCH32_DIRECTIVE := -mach=armv7-a

2
docs/design/interrupt-framework-design.rst
View file

@ -48,7 +48,7 @@ the exception level(s) it is handled in.
The following constants define the various interrupt types in the framework
implementation.
::
.. code:: c
#define INTR_TYPE_S_EL1 0
#define INTR_TYPE_EL3 1

4
docs/design/psci-pd-tree.rst
View file

@ -109,7 +109,7 @@ separately.
This tree is defined by the platform as the array described above as follows:
::
.. code:: c
#define PLAT_NUM_POWER_DOMAINS 20
#define PLATFORM_CORE_COUNT 13
@ -219,7 +219,7 @@ to represent leaf and non-leaf power domain nodes in the tree.
The power domain tree is implemented as a combination of the following data
structures.
::
.. code:: c
non_cpu_pd_node_t psci_non_cpu_pd_nodes[PSCI_NUM_NON_CPU_PWR_DOMAINS];
cpu_pd_node_t psci_cpu_pd_nodes[PLATFORM_CORE_COUNT];

2
docs/getting_started/rt-svc-writers-guide.rst
View file

@ -92,7 +92,7 @@ A runtime service is registered using the ``DECLARE_RT_SVC()`` macro, specifying
the name of the service, the range of OENs covered, the type of service and
initialization and call handler functions.
::
.. code:: c
#define DECLARE_RT_SVC(_name, _start, _end, _type, _setup, _smch)

98
docs/getting_started/user-guide.rst
View file

@ -44,7 +44,7 @@ Tools
Install the required packages to build TF-A with the following command:
::
.. code:: shell
sudo apt-get install device-tree-compiler build-essential gcc make git libssl-dev
@ -106,14 +106,14 @@ in the `Linux master tree`_ *scripts* directory, then set the ``CHECKPATCH``
environment variable to point to ``checkpatch.pl`` (with the other 2 files in
the same directory) and build the `checkcodebase` target:
::
.. code:: shell
make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkcodebase
To just check the style on the files that differ between your local branch and
the remote master, use:
::
.. code:: shell
make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkpatch
@ -129,13 +129,13 @@ Building TF-A
For AArch64:
::
.. code:: shell
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
For AArch32:
::
.. code:: shell
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
@ -153,7 +153,7 @@ Building TF-A
For AArch64 using Arm Compiler 6:
::
.. code:: shell
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all
@ -164,7 +164,7 @@ Building TF-A
For AArch64 using clang:
::
.. code:: shell
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
make CC=<path-to-clang>/bin/clang PLAT=<platform> all
@ -173,13 +173,13 @@ Building TF-A
For AArch64:
::
.. code:: shell
make PLAT=<platform> all
For AArch32:
::
.. code:: shell
make PLAT=<platform> ARCH=aarch32 AARCH32_SP=sp_min all
@ -222,7 +222,7 @@ Building TF-A
- Build products for a specific build variant can be removed using:
::
.. code:: shell
make DEBUG=<D> PLAT=<platform> clean
@ -230,7 +230,7 @@ Building TF-A
The build tree can be removed completely using:
::
.. code:: shell
make realclean
@ -935,7 +935,7 @@ Debugging options
To compile a debug version and make the build more verbose use
::
.. code:: shell
make PLAT=<platform> DEBUG=1 V=1 all
@ -955,7 +955,7 @@ platforms** section in the `Firmware Design`_).
Extra debug options can be passed to the build system by setting ``CFLAGS`` or
``LDFLAGS``:
.. code:: makefile
.. code:: shell
CFLAGS='-O0 -gdwarf-2' \
make PLAT=<platform> DEBUG=1 V=1 all
@ -996,7 +996,7 @@ must be recompiled as well. For more information on SPs and SPDs, see the
First clean the TF-A build directory to get rid of any previous BL31 binary.
Then to build the TSP image use:
::
.. code:: shell
make PLAT=<platform> SPD=tspd all
@ -1024,13 +1024,13 @@ and BL33 images.
For AArch64:
::
.. code:: shell
make PLAT=fvp BL33=<path-to>/bl33.bin fip
For AArch32:
::
.. code:: shell
make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=<path-to>/bl33.bin fip
@ -1046,13 +1046,13 @@ steps:
It is recommended to remove old artifacts before building the tool:
::
.. code:: shell
make -C tools/fiptool clean
Build the tool:
::
.. code:: shell
make [DEBUG=1] [V=1] fiptool
@ -1067,7 +1067,7 @@ options.
Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:
::
.. code:: shell
./tools/fiptool/fiptool create \
--tb-fw build/<platform>/<build-type>/bl2.bin \
@ -1076,13 +1076,13 @@ Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:
Example 2: view the contents of an existing Firmware package:
::
.. code:: shell
./tools/fiptool/fiptool info <path-to>/fip.bin
Example 3: update the entries of an existing Firmware package:
::
.. code:: shell
# Change the BL2 from Debug to Release version
./tools/fiptool/fiptool update \
@ -1091,14 +1091,14 @@ Example 3: update the entries of an existing Firmware package:
Example 4: unpack all entries from an existing Firmware package:
::
.. code:: shell
# Images will be unpacked to the working directory
./tools/fiptool/fiptool unpack <path-to>/fip.bin
Example 5: remove an entry from an existing Firmware package:
::
.. code:: shell
./tools/fiptool/fiptool remove \
--tb-fw build/<platform>/debug/fip.bin
@ -1168,7 +1168,7 @@ images with support for these features:
Example of command line using RSA development keys:
::
.. code:: shell
MBEDTLS_DIR=<path of the directory containing mbed TLS sources> \
make PLAT=<platform> TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 \
@ -1225,7 +1225,7 @@ The ``cert_create`` tool is built as part of the TF-A build process when the
previous section), but it can also be built separately with the following
command:
::
.. code:: shell
make PLAT=<platform> [DEBUG=1] [V=1] certtool
@ -1234,14 +1234,14 @@ For platforms that require their own IDs in certificate files, the generic
platform must define its IDs within a ``platform_oid.h`` header file for the
build to succeed.
::
.. code:: shell
make PLAT=<platform> USE_TBBR_DEFS=0 [DEBUG=1] [V=1] certtool
``DEBUG=1`` builds the tool in debug mode. ``V=1`` makes the build process more
verbose. The following command should be used to obtain help about the tool:
::
.. code:: shell
./tools/cert_create/cert_create -h
@ -1270,7 +1270,7 @@ section for more info on selecting the right FDT to use.
#. Clean the working directory
::
.. code:: shell
make realclean
@ -1279,7 +1279,7 @@ section for more info on selecting the right FDT to use.
Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
package included in the Linaro release:
::
.. code:: shell
# Build the fiptool
make [DEBUG=1] [V=1] fiptool
@ -1300,7 +1300,7 @@ section for more info on selecting the right FDT to use.
#. Build TF-A images and create a new FIP for FVP
::
.. code:: shell
# AArch64
make PLAT=fvp BL33=nt-fw.bin all fip
@ -1315,7 +1315,7 @@ section for more info on selecting the right FDT to use.
Building for AArch64 on Juno simply requires the addition of ``SCP_BL2``
as a build parameter.
::
.. code:: shell
make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp-fw.bin all fip
@ -1328,13 +1328,13 @@ section for more info on selecting the right FDT to use.
- Before building BL32, the environment variable ``CROSS_COMPILE`` must point
to the AArch32 Linaro cross compiler.
::
.. code:: shell
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
- Build BL32 in AArch32.
::
.. code:: shell
make ARCH=aarch32 PLAT=juno AARCH32_SP=sp_min \
RESET_TO_SP_MIN=1 JUNO_AARCH32_EL3_RUNTIME=1 bl32
@ -1349,14 +1349,14 @@ section for more info on selecting the right FDT to use.
- Before building BL1 and BL2, the environment variable ``CROSS_COMPILE``
must point to the AArch64 Linaro cross compiler.
::
.. code:: shell
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
- The following parameters should be used to build BL1 and BL2 in AArch64
and point to the BL32 file.
::
.. code:: shell
make ARCH=aarch64 PLAT=juno JUNO_AARCH32_EL3_RUNTIME=1 \
BL33=nt-fw.bin SCP_BL2=scp-fw.bin \
@ -1494,7 +1494,7 @@ clear the mailbox at start-up.
One way to do that is to create an 8-byte file containing all zero bytes using
the following command:
::
.. code:: shell
dd if=/dev/zero of=mailbox.dat bs=1 count=8
@ -1564,7 +1564,7 @@ used when compiling TF-A. For example, the following command will create a FIP
without a BL33 and prepare to jump to a BL33 image loaded at address
0x80000000:
::
.. code:: shell
make PRELOADED_BL33_BASE=0x80000000 PLAT=fvp all fip
@ -1579,7 +1579,7 @@ memory (like in FVP).
For example, if the kernel is loaded at ``0x80080000`` and the DTB is loaded at
address ``0x82000000``, the firmware can be built like this:
::
.. code:: shell
CROSS_COMPILE=aarch64-linux-gnu- \
make PLAT=fvp DEBUG=1 \
@ -1627,7 +1627,7 @@ offset in ``INITRD_START`` has to be removed.
And the FVP binary can be run with the following command:
::
.. code:: shell
<path-to>/FVP_Base_AEMv8A-AEMv8A \
-C pctl.startup=0.0.0.0 \
@ -1801,7 +1801,7 @@ Running on the Foundation FVP with reset to BL1 entrypoint
The following ``Foundation_Platform`` parameters should be used to boot Linux with
4 CPUs using the AArch64 build of TF-A.
::
.. code:: shell
<path-to>/Foundation_Platform \
--cores=4 \
@ -1837,7 +1837,7 @@ Running on the AEMv8 Base FVP with reset to BL1 entrypoint
The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch64 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_RevC-2xAEMv8A \
-C pctl.startup=0.0.0.0 \
@ -1860,7 +1860,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch32 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_AEMv8A-AEMv8A \
-C pctl.startup=0.0.0.0 \
@ -1888,7 +1888,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
boot Linux with 8 CPUs using the AArch64 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_Cortex-A57x4-A53x4 \
-C pctl.startup=0.0.0.0 \
@ -1906,7 +1906,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
boot Linux with 4 CPUs using the AArch32 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_Cortex-A32x4 \
-C pctl.startup=0.0.0.0 \
@ -1924,7 +1924,7 @@ Running on the AEMv8 Base FVP with reset to BL31 entrypoint
The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch64 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_RevC-2xAEMv8A \
-C pctl.startup=0.0.0.0 \
@ -1979,7 +1979,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to SP_MIN entrypoint
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch32 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_AEMv8A-AEMv8A \
-C pctl.startup=0.0.0.0 \
@ -2019,7 +2019,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
boot Linux with 8 CPUs using the AArch64 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_Cortex-A57x4-A53x4 \
-C pctl.startup=0.0.0.0 \
@ -2047,7 +2047,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to SP_MIN entrypoint
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
boot Linux with 4 CPUs using the AArch32 build of TF-A.
::
.. code:: shell
<path-to>/FVP_Base_Cortex-A32x4 \
-C pctl.startup=0.0.0.0 \
@ -2096,7 +2096,7 @@ The SYSTEM SUSPEND is a PSCI API which can be used to implement system suspend
to RAM. For more details refer to section 5.16 of `PSCI`_. To test system suspend
on Juno, at the linux shell prompt, issue the following command:
::
.. code:: shell
echo +10 > /sys/class/rtc/rtc0/wakealarm
echo -n mem > /sys/power/state

2
docs/perf/psci-performance-juno.rst
View file

@ -28,7 +28,7 @@ levels 0, 1 and 2 respectively. It does not support any retention states.
We used the upstream `TF master as of 31/01/2017`_, building the platform using
the ``ENABLE_RUNTIME_INSTRUMENTATION`` option:
::
.. code:: shell
make PLAT=juno ENABLE_RUNTIME_INSTRUMENTATION=1 \
SCP_BL2=<path/to/scp-fw.bin> \

4
docs/plat/allwinner.rst
View file

@ -24,13 +24,13 @@ See the respective `U-Boot documentation`_ for more details.
To build for machines with an A64 or H5 SoC:
::
.. code:: shell
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1 bl31
To build for machines with an H6 SoC:
::
.. code:: shell
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 DEBUG=1 bl31

2
docs/plat/meson-gxbb.rst
View file

@ -15,7 +15,7 @@ and Linux:
In order to build it:
::
.. code:: shell
CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxbb bl31

2
docs/plat/meson-gxl.rst
View file

@ -15,7 +15,7 @@ and Linux:
In order to build it:
::
.. code:: shell
CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxl

4
docs/plat/qemu.rst
View file

@ -33,13 +33,13 @@ is conveniently achieved with symlinks the local names as:
To build:
::
.. code:: shell
make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu
To start (QEMU v2.6.0):
::
.. code:: shell
qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 \
-kernel Image \

2
docs/process/coding-guidelines.rst
View file

@ -292,7 +292,7 @@ of the size of an array is the same.
If ``MY_STRUCT_SIZE`` in the above example were wrong then the compiler would
emit an error like this:
.. code:: c
::
my_struct.h:10:1: error: size of array ‘assert_my_struct_size_mismatch’ is negative

2
docs/security_advisories/security-advisory-tfv-3.rst
View file

@ -68,7 +68,7 @@ The vulnerability is mitigated by the following factors:
of the ``XN``, ``UXN`` or ``PXN`` bits in the translation tables. See the
``enable_mmu()`` function:
.. code:: c
::
sctlr = read_sctlr_el##_el(); \
sctlr |= SCTLR_WXN_BIT | SCTLR_M_BIT; \

2
docs/security_advisories/security-advisory-tfv-8.rst
View file

@ -39,7 +39,7 @@ CPU context stored on the stack. This includes registers ``x0`` to ``x3``, as
can be seen in the ``lib/el3_runtime/aarch64/context.S`` file at line 339
(referring to the version of the code as of `commit c385955`_):
.. code:: c
::
/*
* This function restores all general purpose registers except x30 from the