From: Roland Hieber <r.hieber@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Roland Hieber <r.hieber@pengutronix.de>
Subject: [PATCH 2/2] Documentation: fix code block and literal block highlighting
Date: Wed, 25 Jul 2018 16:18:11 +0200 [thread overview]
Message-ID: <20180725141811.25588-2-r.hieber@pengutronix.de> (raw)
In-Reply-To: <20180725141811.25588-1-r.hieber@pengutronix.de>
Use shell script highlighting where it is resonable, use console
highlighting for transcripts, and fix some of the few cases where the
syntax was broken, resulting in text not being rendered at all.
Signed-off-by: Roland Hieber <r.hieber@pengutronix.de>
---
Documentation/boards/imx.rst | 16 +++++++++----
.../boards/imx/Garz-Fricke-Vincell.rst | 4 +++-
.../boards/imx/Phytec-phyCORE-i.MX31.rst | 8 +++++--
Documentation/boards/imx/Wandboard.rst | 5 +++-
Documentation/boards/imx/amazon-kindle3.rst | 7 ++++--
Documentation/boards/mips/dlink-dir-320.rst | 4 +++-
Documentation/boards/mips/qemu-malta.rst | 16 +++++++++----
Documentation/boards/mvebu.rst | 4 +++-
.../boards/mxs/Chumby-Falconwing.rst | 8 +++++--
.../boards/mxs/Freescale-i.MX23-evk.rst | 8 +++++--
Documentation/boards/mxs/KaRo-TX28.rst | 8 +++++--
Documentation/boards/mxs/Olimex-olinuxino.rst | 8 +++++--
Documentation/boards/omap.rst | 4 +++-
Documentation/boards/openrisc.rst | 8 +++++--
Documentation/boards/s3c/Digi-a9m2440.rst | 8 +++++--
Documentation/boards/sandbox.rst | 6 ++++-
Documentation/boards/socfpga.rst | 24 ++++++++++++++-----
Documentation/boards/x86.rst | 3 ++-
Documentation/filesystems/fat.rst | 4 +++-
Documentation/filesystems/nfs.rst | 8 +++++--
Documentation/filesystems/pstore.rst | 2 +-
Documentation/filesystems/ramfs.rst | 4 +++-
Documentation/filesystems/smhfs.rst | 4 +++-
Documentation/filesystems/squashfs.rst | 4 +++-
Documentation/filesystems/tftp.rst | 4 +++-
Documentation/user/automount.rst | 12 +++++++---
Documentation/user/barebox.rst | 4 +---
Documentation/user/defaultenv-2.rst | 4 +++-
Documentation/user/driver-model.rst | 20 ++++++++++++----
Documentation/user/hush.rst | 24 ++++++++++++++-----
Documentation/user/memory-areas.rst | 8 +++++--
Documentation/user/system-setup.rst | 12 +++++++---
Documentation/user/updating.rst | 8 +++++--
Documentation/user/variables.rst | 14 +++++++----
34 files changed, 211 insertions(+), 74 deletions(-)
diff --git a/Documentation/boards/imx.rst b/Documentation/boards/imx.rst
index 9b1eb82d41..934ead4559 100644
--- a/Documentation/boards/imx.rst
+++ b/Documentation/boards/imx.rst
@@ -31,7 +31,9 @@ Normally it's not necessary to call this tool manually, it is executed
automatically at the end of the build process.
The images generated by the build process can be directly written to an
-SD card::
+SD card:
+
+.. code-block:: sh
# with Multi Image support:
cat images/barebox-freescale-imx51-babbage.img > /dev/sdd
@@ -40,11 +42,15 @@ SD card::
The above will overwrite the MBR (and consequently the partition table)
on the destination SD card. To preserve the MBR while writing the rest
-of the image to the card, use::
+of the image to the card, use:
+
+.. code-block:: sh
dd if=images/barebox-freescale-imx51-babbage.img of=/dev/sdd bs=512 skip=1 seek=1
-The images can also always be started second stage::
+The images can also always be started second stage:
+
+.. code-block:: sh
bootm /mnt/tftp/barebox-freescale-imx51-babbage.img
@@ -141,7 +147,9 @@ contains a USB upload tool. As it depends on the libusb development headers,
it is not built by default. Enable it explicitly in ``make menuconfig``
and install the libusb development package. On Debian, this can be done
with ``apt-get install libusb-dev``. After compilation, the tool can be used
-with only the image name as argument::
+with only the image name as argument:
+
+.. code-block:: sh
scripts/imx/imx-usb-loader images/barebox-freescale-imx51-babbage.img
diff --git a/Documentation/boards/imx/Garz-Fricke-Vincell.rst b/Documentation/boards/imx/Garz-Fricke-Vincell.rst
index 58ab0ab42f..f9c371b49c 100644
--- a/Documentation/boards/imx/Garz-Fricke-Vincell.rst
+++ b/Documentation/boards/imx/Garz-Fricke-Vincell.rst
@@ -38,6 +38,8 @@ If the network setup is working properly, barebox can be loaded into memory::
load -v -r -b 0x80100000 barebox-guf-vincell-lt.img
exec
-Once in barebox, the bootloader can now be persisted to NAND::
+Once in barebox, the bootloader can now be persisted to NAND:
+
+.. code-block:: sh
barebox_update -t nand /mnt/tftp/barebox-guf-vincell-lt.img``
diff --git a/Documentation/boards/imx/Phytec-phyCORE-i.MX31.rst b/Documentation/boards/imx/Phytec-phyCORE-i.MX31.rst
index 6c05bcdfdc..36df2bbf9f 100644
--- a/Documentation/boards/imx/Phytec-phyCORE-i.MX31.rst
+++ b/Documentation/boards/imx/Phytec-phyCORE-i.MX31.rst
@@ -26,11 +26,15 @@ Supported baseboards are:
How to get barebox for 'Phytec's phyCORE-i.MX31'
------------------------------------------------
-Using the default configuration::
+Using the default configuration:
+
+.. code-block:: sh
make ARCH=arm pcm037_defconfig
-Build the binary image::
+Build the binary image:
+
+.. code-block:: sh
make ARCH=arm CROSS_COMPILE=armv5compiler
diff --git a/Documentation/boards/imx/Wandboard.rst b/Documentation/boards/imx/Wandboard.rst
index 574318a009..818b9ef1cd 100644
--- a/Documentation/boards/imx/Wandboard.rst
+++ b/Documentation/boards/imx/Wandboard.rst
@@ -10,7 +10,10 @@ will not boot from the slot on the carrier board.
To boot barebox on any wandboard, build imx_v7_defconfig
and copy the barebox imx-image to the i.MX boot location of a SD card, e.g.
-dd bs=1024 skip=1 seek=1 if=images/barebox-imx6-wandboard.img of=/dev/mmcblk0
+
+.. code-block:: sh
+
+ dd bs=1024 skip=1 seek=1 if=images/barebox-imx6-wandboard.img of=/dev/mmcblk0
Only one image exists, supporting all three Wandboard variants, barebox will
detect the Wandboard variant depending on the SoC variant.
diff --git a/Documentation/boards/imx/amazon-kindle3.rst b/Documentation/boards/imx/amazon-kindle3.rst
index 50592f2cb9..dc0ba30cb1 100644
--- a/Documentation/boards/imx/amazon-kindle3.rst
+++ b/Documentation/boards/imx/amazon-kindle3.rst
@@ -24,5 +24,8 @@ Barebox may be used as drop-in replacement for the shipped bootloader.
When installing the barebox imximg on the eMMC take care not to overwrite
the partition table and vendor supplied serial numbers stored on the eMMC.
e.g. just write the imx-header and the application section:
-memcpy -b -s barebox.imximg -d /dev/disk0.imx_header 1024 0 1024
-memcpy -b -s barebox.imximg -d /dev/disk0.self 4096 0 195584
+
+.. code-block:: sh
+
+ memcpy -b -s barebox.imximg -d /dev/disk0.imx_header 1024 0 1024
+ memcpy -b -s barebox.imximg -d /dev/disk0.self 4096 0 195584
diff --git a/Documentation/boards/mips/dlink-dir-320.rst b/Documentation/boards/mips/dlink-dir-320.rst
index 74d11ffe59..7595381f55 100644
--- a/Documentation/boards/mips/dlink-dir-320.rst
+++ b/Documentation/boards/mips/dlink-dir-320.rst
@@ -26,7 +26,9 @@ Put your barebox.bin to tftp-server directory
Connect your DIR-320 to your tftp-server network via
one of four <LAN> sockets.
-Next, setup network on DIR-320 and run barebox.bin, e.g.::
+Next, setup network on DIR-320 and run barebox.bin, e.g.:
+
+.. code-block:: console
CFE> ifconfig eth0 -addr=192.168.0.99
CFE> boot -tftp -addr=a0800000 -raw 192.168.0.1:barebox.bin
diff --git a/Documentation/boards/mips/qemu-malta.rst b/Documentation/boards/mips/qemu-malta.rst
index 0c4d639194..2bb81350a1 100644
--- a/Documentation/boards/mips/qemu-malta.rst
+++ b/Documentation/boards/mips/qemu-malta.rst
@@ -4,7 +4,9 @@ QEMU Malta
Big-endian mode
---------------
-QEMU run string::
+QEMU run string:
+
+.. code-block:: sh
qemu-system-mips -nodefaults -M malta -m 256 \
-nographic -serial stdio -monitor null \
@@ -18,13 +20,17 @@ Running little-endian Malta is a bit tricky.
In little-endian mode the 32bit words in the boot flash image are swapped,
a neat trick which allows bi-endian firmware.
-You have to swap words of ``zbarebox.bin`` image, e.g.::
+You have to swap words of ``zbarebox.bin`` image, e.g.:
+
+.. code-block:: sh
echo arch/mips/pbl/zbarebox.bin \
| cpio --create \
| cpio --extract --swap --unconditional
-QEMU run string::
+QEMU run string:
+
+.. code-block:: sh
qemu-system-mipsel -nodefaults -M malta -m 256 \
-nographic -serial stdio -monitor null \
@@ -39,7 +45,9 @@ You can use GXemul to run little-endian barebox (use gxemul-malta_defconfig).
N.B. There is no need to swap words in ``zbarebox.bin`` for little-endian GXemul!
-GXemul run string::
+GXemul run string:
+
+.. code-block:: sh
gxemul -Q -e malta -M 256 0xbfc00000:barebox-flash-image
diff --git a/Documentation/boards/mvebu.rst b/Documentation/boards/mvebu.rst
index e27aa28306..9c99c815de 100644
--- a/Documentation/boards/mvebu.rst
+++ b/Documentation/boards/mvebu.rst
@@ -14,7 +14,9 @@ RAM initialisation
------------------
Traditionally the RAM initialisation happens with a binary blob that have to be
-extracted from the vendor U-Boot::
+extracted from the vendor U-Boot:
+
+.. code-block:: sh
scripts/kwbimage -x -i /dev/mtdblock0 -o .
diff --git a/Documentation/boards/mxs/Chumby-Falconwing.rst b/Documentation/boards/mxs/Chumby-Falconwing.rst
index 172d6840cf..690ccadf8c 100644
--- a/Documentation/boards/mxs/Chumby-Falconwing.rst
+++ b/Documentation/boards/mxs/Chumby-Falconwing.rst
@@ -20,11 +20,15 @@ Memory layout when barebox is running:
How to get the bootloader binary image
--------------------------------------
-Using the default configuration::
+Using the default configuration:
+
+.. code-block:: sh
make ARCH=arm chumbyone_defconfig
-Build the bootloader binary image::
+Build the bootloader binary image:
+
+.. code-block:: sh
make ARCH=arm CROSS_COMPILE=armv5compiler
diff --git a/Documentation/boards/mxs/Freescale-i.MX23-evk.rst b/Documentation/boards/mxs/Freescale-i.MX23-evk.rst
index cb73ec1279..077ab73bda 100644
--- a/Documentation/boards/mxs/Freescale-i.MX23-evk.rst
+++ b/Documentation/boards/mxs/Freescale-i.MX23-evk.rst
@@ -19,11 +19,15 @@ Memory layout when barebox is running:
How to get the bootloader binary image
--------------------------------------
-Using the default configuration::
+Using the default configuration:
+
+.. code-block:: sh
make ARCH=arm freescale-mx23-evk_defconfig
-Build the bootloader binary image::
+Build the bootloader binary image:
+
+.. code-block:: sh
make ARCH=arm CROSS_COMPILE=armv5compiler
diff --git a/Documentation/boards/mxs/KaRo-TX28.rst b/Documentation/boards/mxs/KaRo-TX28.rst
index 6cad5eb243..54b1ce71eb 100644
--- a/Documentation/boards/mxs/KaRo-TX28.rst
+++ b/Documentation/boards/mxs/KaRo-TX28.rst
@@ -24,11 +24,15 @@ Supported baseboards are:
How to get barebox for 'KARO's Starterkit 5'
--------------------------------------------
-Using the default configuration::
+Using the default configuration:
+
+.. code-block:: sh
make ARCH=arm tx28stk5_defconfig
-Build the binary image::
+Build the binary image:
+
+.. code-block:: sh
make ARCH=arm CROSS_COMPILE=armv5compiler
diff --git a/Documentation/boards/mxs/Olimex-olinuxino.rst b/Documentation/boards/mxs/Olimex-olinuxino.rst
index a06eb3309f..2080653887 100644
--- a/Documentation/boards/mxs/Olimex-olinuxino.rst
+++ b/Documentation/boards/mxs/Olimex-olinuxino.rst
@@ -9,11 +9,15 @@ This CPU module is based on a Freescale i.MX23 CPU.
How to get the bootloader binary image
--------------------------------------
-Using the default configuration::
+Using the default configuration:
+
+.. code-block:: sh
make ARCH=arm imx233-olinuxino_defconfig
-Build the binary image::
+Build the binary image:
+
+.. code-block:: sh
make ARCH=arm CROSS_COMPILE=armv5compiler
diff --git a/Documentation/boards/omap.rst b/Documentation/boards/omap.rst
index c2697510c5..717a38fe01 100644
--- a/Documentation/boards/omap.rst
+++ b/Documentation/boards/omap.rst
@@ -15,7 +15,9 @@ The PandaBoard boots from SD card. The OMAP Boot ROM code loads a file named
scripts on the net which describe how to prepare such a card (it needs
special partitioning). The same procedure can be used for barebox. With such a
card (assumed to be at /dev/sdc), the following can be used to build and install
-barebox::
+barebox:
+
+.. code-block:: console
# mount -t fat /dev/sdc1 /mnt
# make panda_xload_defconfig
diff --git a/Documentation/boards/openrisc.rst b/Documentation/boards/openrisc.rst
index fe6c48c958..f9d67f9650 100644
--- a/Documentation/boards/openrisc.rst
+++ b/Documentation/boards/openrisc.rst
@@ -4,7 +4,9 @@ OpenRISC
or1ksim
-------
-Compile or1ksim emulator::
+Compile or1ksim emulator:
+
+.. code-block:: console
$ cd ~/
$ git clone https://github.com/openrisc/or1ksim
@@ -48,6 +50,8 @@ Create minimal or1ksim.cfg file:
tap_dev = "tap0"
end
-Run or1ksim::
+Run or1ksim:
+
+.. code-block:: console
$ ~/or1ksim/sim -f or1ksim.cfg barebox
diff --git a/Documentation/boards/s3c/Digi-a9m2440.rst b/Documentation/boards/s3c/Digi-a9m2440.rst
index d01a001172..32d58b9a04 100644
--- a/Documentation/boards/s3c/Digi-a9m2440.rst
+++ b/Documentation/boards/s3c/Digi-a9m2440.rst
@@ -78,11 +78,15 @@ This CPU card is based on a Samsung S3C2440 CPU. The card is shipped with:
How to get the binary image
---------------------------
-Configure with the default configuration::
+Configure with the default configuration:
+
+.. code-block:: sh
make ARCH=arm a9m2440_defconfig
-Build the binary image::
+Build the binary image:
+
+.. code-block:: sh
make ARCH=arm CROSS_COMPILE=armv4compiler
diff --git a/Documentation/boards/sandbox.rst b/Documentation/boards/sandbox.rst
index 558f111697..85a54e6b04 100644
--- a/Documentation/boards/sandbox.rst
+++ b/Documentation/boards/sandbox.rst
@@ -7,7 +7,9 @@ hardware related features.
Building barebox for simulation
-------------------------------
-The barebox sandbox can be built with the host compiler::
+The barebox sandbox can be built with the host compiler:
+
+.. code-block:: sh
ARCH=sandbox make sandbox_defconfig
ARCH=sandbox make
@@ -17,6 +19,8 @@ Running the sandbox
Once you compile barebox for the sandbox, you can run it with::
+.. code-block:: console
+
$ barebox [<OPTIONS>]
Available sandbox invocation options include:
diff --git a/Documentation/boards/socfpga.rst b/Documentation/boards/socfpga.rst
index cd0fffa1ee..d73237491d 100644
--- a/Documentation/boards/socfpga.rst
+++ b/Documentation/boards/socfpga.rst
@@ -41,7 +41,9 @@ second partition of the SD card, which must be of type FAT32. On this partition
barebox searches for a file called barebox.bin.
To boot barebox on a Terasic SoCkit, the procedure is as follows (sdb1 is the A2 and
-sdb2 the FAT32 partition)::
+sdb2 the FAT32 partition):
+
+.. code-block:: sh
mount -t fat /dev/sdb2 /mnt
make socfpga-xload_defconfig
@@ -50,7 +52,9 @@ sdb2 the FAT32 partition)::
make
barebox has now generated multiple files in the images directory. So for the SoCkit
-proceed with::
+proceed with:
+
+.. code-block:: sh
cat images/barebox-socfpga-sockit-xload.img > /dev/sdb1
cp images/barebox-socfpga-sockit.img /mnt/barebox.bin
@@ -64,12 +68,16 @@ QSPI
The Boot ROM loads the preloader starting from address 0x0 on the QSPI flash.
barebox then searches for a barebox image at the 256K offset and loads it.
-The default bootsource is SD card, so to change that to QSPI, you have to::
+The default bootsource is SD card, so to change that to QSPI, you have to:
+
+.. code-block:: sh
make socfpga-xload_defconfig
make menuconfig
-And then select the options `MTD` and `SPI_CADENCE_QUADSPI`. Now::
+And then select the options `MTD` and `SPI_CADENCE_QUADSPI`. Now:
+
+.. code-block:: sh
make
cat images/barebox-socfpga-<board>-xload.img > /dev/mtd0
@@ -116,7 +124,9 @@ To update the handoff files, the following procedure is necessary:
preloader settings directory
7. Click ``Ok`` than ``Generate``
-Now run the command::
+Now run the command:
+
+.. code-block:: sh
scripts/socfpga_import_preloader <SPL_GENERATED_DIR> <ISW_HANDOFF> <BOARD_DIRECTORY>
@@ -141,7 +151,9 @@ tree:
* system.h
* tclrpt.h
-To add these files, run::
+To add these files, run:
+
+.. code-block:: sh
scripts/socfpga_get_sequencer <UBOOT-SRC> scripts/socfpga_sequencer_defines_defaults
diff --git a/Documentation/boards/x86.rst b/Documentation/boards/x86.rst
index d0528a3280..4514a766a2 100644
--- a/Documentation/boards/x86.rst
+++ b/Documentation/boards/x86.rst
@@ -50,7 +50,8 @@ sectors must be kept free after the MBR prior the first partition. Do this
simple calulation:
.. code-block:: none
- sectors = (\<size of barebox image\> + 511) / 512
+
+ sectors = (size of barebox image + 511) / 512
To be able to store the runtime configuration, further free sectors are
required. Its up to you and your requirements, how large this persistant
diff --git a/Documentation/filesystems/fat.rst b/Documentation/filesystems/fat.rst
index e39e34a0e9..138e69711f 100644
--- a/Documentation/filesystems/fat.rst
+++ b/Documentation/filesystems/fat.rst
@@ -5,7 +5,9 @@ FAT filesystem
barebox supports FAT filesystems in both read and write modes with optional
support for long filenames. A FAT filesystem can be mounted using the
-:ref:`command_mount` command::
+:ref:`command_mount` command:
+
+.. code-block:: console
barebox:/ mkdir /mnt
barebox:/ mount /dev/disk0.0 fat /mnt
diff --git a/Documentation/filesystems/nfs.rst b/Documentation/filesystems/nfs.rst
index ab51241549..3e40ae9767 100644
--- a/Documentation/filesystems/nfs.rst
+++ b/Documentation/filesystems/nfs.rst
@@ -7,7 +7,9 @@ NFS Support
barebox has readonly support for NFSv3 in UDP mode.
-Example::
+Example:
+
+.. code-block:: console
barebox:/ mount -t nfs 192.168.23.4:/home/user/nfsroot /mnt/nfs
@@ -15,7 +17,9 @@ The barebox NFS driver adds a ``linux.bootargs`` device parameter to the NFS dev
This parameter holds a Linux kernel commandline snippet containing a suitable root=
option for booting from exactly that NFS share.
-Example::
+Example:
+
+.. code-block:: console
barebox:/ devinfo nfs0
...
diff --git a/Documentation/filesystems/pstore.rst b/Documentation/filesystems/pstore.rst
index 8eee374bdd..22e89b3f1f 100644
--- a/Documentation/filesystems/pstore.rst
+++ b/Documentation/filesystems/pstore.rst
@@ -20,7 +20,7 @@ at boot:
none on /pstore type pstore
pstore may add additional warnings during boot due to wrong ECCs (no data
-written)::
+written):
.. code-block:: none
diff --git a/Documentation/filesystems/ramfs.rst b/Documentation/filesystems/ramfs.rst
index d27f88561f..e61505a5f9 100644
--- a/Documentation/filesystems/ramfs.rst
+++ b/Documentation/filesystems/ramfs.rst
@@ -7,6 +7,8 @@ ramfs is a simple malloc-based filesystem. An instance of ramfs is
mounted during startup on /. The filesystem type passed to ``mount``
is ``ramfs``.
-Example::
+Example:
+
+.. code-block:: console
barebox:/ mount none ramfs /somedir
diff --git a/Documentation/filesystems/smhfs.rst b/Documentation/filesystems/smhfs.rst
index 9e9993cb28..8f8a0ec6b7 100644
--- a/Documentation/filesystems/smhfs.rst
+++ b/Documentation/filesystems/smhfs.rst
@@ -18,7 +18,9 @@ not have support for listing directories. This means a
:ref:`command_ls` to a SMHFS-mounted path will show an empty
directory. Nevertheless, the files are there.
-Example::
+Example:
+
+.. code-block:: console
barebox:/ mount -t smhfs /dev/null /mnt/smhfs
diff --git a/Documentation/filesystems/squashfs.rst b/Documentation/filesystems/squashfs.rst
index 88c97ebbe8..a042f7b96b 100644
--- a/Documentation/filesystems/squashfs.rst
+++ b/Documentation/filesystems/squashfs.rst
@@ -6,7 +6,9 @@ SquashFS filesystem
SquashFS is a highly compressed read-only filesystem for Linux.
It uses zlib, lzo or xz compression to compress both files, inodes
and directories. A SquashFS filesystem can be mounted using the
-:ref:`command_mount` command::
+:ref:`command_mount` command:
+
+.. code-block:: console
barebox:/ mkdir /mnt
barebox:/ mount -t squashfs /dev/spiflash.FileSystem /mnt
diff --git a/Documentation/filesystems/tftp.rst b/Documentation/filesystems/tftp.rst
index eeb3fcb688..a292765e25 100644
--- a/Documentation/filesystems/tftp.rst
+++ b/Documentation/filesystems/tftp.rst
@@ -12,7 +12,9 @@ TFTP is not designed as a filesystem. It does not have support for listing
directories. This means a :ref:`ls <command_ls>` to a TFTP-mounted path will
show an empty directory. Nevertheless, the files are there.
-Example::
+Example:
+
+.. code-block:: console
barebox:/ mount -t tftp 192.168.23.4 /mnt/tftp
diff --git a/Documentation/user/automount.rst b/Documentation/user/automount.rst
index 7de8261354..1fdeffc663 100644
--- a/Documentation/user/automount.rst
+++ b/Documentation/user/automount.rst
@@ -10,7 +10,9 @@ filesystems. The filesystems (and the devices they are on) are only probed
when necessary, so barebox does not lose time probing unused devices.
Typical usage is for accessing the TFTP server. To set up an automount for a
-TFTP server, the following is required::
+TFTP server, the following is required:
+
+.. code-block:: sh
mkdir -p /mnt/tftp
automount /mnt/tftp 'ifup -a && mount -t tftp $global.net.server /mnt/tftp'
@@ -21,12 +23,16 @@ It will bring up the network device using :ref:`command_ifup` and mount a TFTP f
using :ref:`command_mount`.
Usually the above automount command is executed from an init script in ``/env/init/automount``.
-With the above, files on the TFTP server can be accessed without configuration::
+With the above, files on the TFTP server can be accessed without configuration:
+
+.. code-block:: sh
cp /mnt/tftp/linuximage /image
This automatically detects a USB mass storage device and mounts the first
-partition to ``/mnt/fat``::
+partition to ``/mnt/fat``:
+
+.. code-block:: sh
mkdir -p /mnt/fat
automount -d /mnt/fat 'usb && [ -e /dev/disk0.0 ] && mount /dev/disk0.0 /mnt/fat'
diff --git a/Documentation/user/barebox.rst b/Documentation/user/barebox.rst
index 1203c10cd1..88135225f3 100644
--- a/Documentation/user/barebox.rst
+++ b/Documentation/user/barebox.rst
@@ -181,9 +181,7 @@ simply with:
The resulting binary varies depending on the board barebox is compiled for.
Without :ref:`multi_image` support the ``barebox-flash-image`` link will point
to the binary for flashing/uploading to the board. With :ref:`multi_image` support
-the compilation process will finish with a list of images built under ``images/``:
-
-.. code-block:: sh
+the compilation process will finish with a list of images built under ``images/``::
images built:
barebox-freescale-imx51-babbage.img
diff --git a/Documentation/user/defaultenv-2.rst b/Documentation/user/defaultenv-2.rst
index db74176b03..e08fdf3feb 100644
--- a/Documentation/user/defaultenv-2.rst
+++ b/Documentation/user/defaultenv-2.rst
@@ -44,7 +44,9 @@ and their respective included directories in ``defaultenv/Makefile``:
This script is executed by the barebox startup code after initialization.
In defaultenv-2, this script will define and set a number of global
-variables, followed by sourcing all of the scripts in ``/env/init/`` with::
+variables, followed by sourcing all of the scripts in ``/env/init/`` with:
+
+.. code-block:: sh
for i in /env/init/*; do
. $i
diff --git a/Documentation/user/driver-model.rst b/Documentation/user/driver-model.rst
index ce7083589c..a0fd3e99b5 100644
--- a/Documentation/user/driver-model.rst
+++ b/Documentation/user/driver-model.rst
@@ -32,7 +32,9 @@ Some devices like USB or MMC may take a longer time to probe. Probing USB
devices should not delay booting when USB may not even be used. This case is
handled with device detection. The user visible interface to device detection
is the :ref:`command_detect` command. ``detect -l`` shows a list of detectable
-devices::
+devices:
+
+.. code-block:: console
barebox:/ detect -l
70004000.esdhc
@@ -46,7 +48,9 @@ devices::
mmc1
miibus0
-A particular device can be detected with ``detect <devname>``::
+A particular device can be detected with ``detect <devname>``:
+
+.. code-block:: console
barebox:/ detect 73f80200.usb
Found SMSC USB331x ULPI transceiver (0x0424:0x0006).
@@ -67,7 +71,9 @@ Device parameters
Devices can have parameters which can be used to configure devices or to provide
additional information for a device. The parameters can be listed with the
:ref:`command_devinfo` command. A ``devinfo <devicename>`` will print the parameters
-of a device::
+of a device:
+
+.. code-block:: console
barebox:/ devinfo eth0
Parameters:
@@ -77,12 +83,16 @@ of a device::
netmask: 255.255.0.0
ethaddr: 00:1c:49:01:03:4b
-The parameters can be used as shell variables::
+The parameters can be used as shell variables:
+
+.. code-block:: sh
eth0.ipaddr=192.168.23.15
echo "my current ip is: $eth0.ipaddr"
-device variables may have a type, so assigning wrong values may fail::
+device variables may have a type, so assigning wrong values may fail:
+
+.. code-block:: console
barebox:/ eth0.ipaddr="This is not an IP"
set parameter: Invalid argument
diff --git a/Documentation/user/hush.rst b/Documentation/user/hush.rst
index 00d4e2983e..a4d8688142 100644
--- a/Documentation/user/hush.rst
+++ b/Documentation/user/hush.rst
@@ -13,13 +13,17 @@ more flexible and also more robust than a complicated shell script.
Hush features
-------------
-variables::
+variables:
+
+.. code-block:: sh
a="Hello user"
echo $a
Hello user
-conditional execution ``if`` / ``elif`` / ``else`` / ``fi``::
+conditional execution ``if`` / ``elif`` / ``else`` / ``fi``:
+
+.. code-block:: sh
if [ ${foo} = ${bar} ]; then
echo "foo equals bar"
@@ -27,19 +31,25 @@ conditional execution ``if`` / ``elif`` / ``else`` / ``fi``::
echo "foo and bar differ"
fi
-``for`` loops::
+``for`` loops:
+
+.. code-block:: sh
for i in a b c; do
echo $i
done
-``while`` loops::
+``while`` loops:
+
+.. code-block:: sh
while true; do
echo "endless loop"
done
-wildcard globbing::
+wildcard globbing:
+
+.. code-block:: sh
ls d*
echo ???
@@ -53,7 +63,9 @@ stored.
**NOTE:** hush feels like a normal Unix shell, but it cannot calculate by
itself, i.e. $(($A/2)) won't work. Calculation can however be done
-with :ref:`command_let`::
+with :ref:`command_let`:
+
+.. code-block:: sh
A=10
let B=$A/2
diff --git a/Documentation/user/memory-areas.rst b/Documentation/user/memory-areas.rst
index 9654a99167..d673f6e1b1 100644
--- a/Documentation/user/memory-areas.rst
+++ b/Documentation/user/memory-areas.rst
@@ -17,11 +17,15 @@ gigabyte.
Examples
--------
-Display a hexdump from 0x80000000 to 0x80001000 (inclusive)::
+Display a hexdump from 0x80000000 to 0x80001000 (inclusive):
+
+.. code-block:: sh
md 0x80000000-0x80001000
-Display 1 kilobyte of memory starting at 0x80000000::
+Display 1 kilobyte of memory starting at 0x80000000:
+
+.. code-block:: sh
md 0x80000000+1k
diff --git a/Documentation/user/system-setup.rst b/Documentation/user/system-setup.rst
index 7e4a7669a8..9f4a79cb63 100644
--- a/Documentation/user/system-setup.rst
+++ b/Documentation/user/system-setup.rst
@@ -16,7 +16,9 @@ for root privileges.
Using the "screen" program
^^^^^^^^^^^^^^^^^^^^^^^^^^
-The terminal manager ``screen`` can also be used as a simple terminal emulator::
+The terminal manager ``screen`` can also be used as a simple terminal emulator:
+
+.. code-block:: sh
screen /dev/ttyUSB0 115200
@@ -31,7 +33,9 @@ from source:
http://git.pengutronix.de/?p=tools/microcom.git;a=summary
-Usage is simple::
+Usage is simple:
+
+.. code-block:: sh
microcom -p /dev/ttyUSB0
@@ -46,7 +50,9 @@ Configuration of dnsmasq for DHCP and TFTP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``dnsmasq`` program can be configured as a DHCP and TFTP server in addition
-to its original DNS functionality::
+to its original DNS functionality:
+
+.. code-block:: sh
sudo ip addr add 192.168.23.1/24 dev <interface>
sudo ip link set <interface> up
diff --git a/Documentation/user/updating.rst b/Documentation/user/updating.rst
index 7aac0a99d6..0555909aa1 100644
--- a/Documentation/user/updating.rst
+++ b/Documentation/user/updating.rst
@@ -11,12 +11,16 @@ A board can register an update handler to the update command. The handler can
do additional checks before trying an update, e.g. it's possible
to check whether the new image actually is a barebox image.
-Updating barebox can be as easy as::
+Updating barebox can be as easy as:
+
+.. code-block:: sh
barebox_update /path/to/new/barebox.img
Multiple handlers can be registered to the update mechanism. Usually the device
-barebox has been started from is registered as default (marked with a ``*``)::
+barebox has been started from is registered as default (marked with a ``*``):
+
+.. code-block:: console
barebox:/ barebox_update -l
registered update handlers:
diff --git a/Documentation/user/variables.rst b/Documentation/user/variables.rst
index e0a79416c6..ddfd485740 100644
--- a/Documentation/user/variables.rst
+++ b/Documentation/user/variables.rst
@@ -12,12 +12,16 @@ The ``global`` device
The ``global`` device is a special purpose device. It only exists as a
storage for global variables. Some global variables are created internally
in barebox (see :ref:`magicvars`). Additional variables can be created with
-the :ref:`command_global` command::
+the :ref:`command_global` command:
+
+.. code-block:: sh
global myvar
This creates the ``global.myvar`` variable which now can be used like any
-other variable. You can also directly assign a value during creation::
+other variable. You can also directly assign a value during creation:
+
+.. code-block:: sh
global myvar1=foobar
@@ -48,7 +52,7 @@ actual values.
examples:
-.. code-block:: sh
+.. code-block:: console
barebox@Phytec phyCARD-i.MX27:/ devinfo nv
barebox@Phytec phyCARD-i.MX27:/ nv model=myboard
@@ -94,7 +98,9 @@ Some variables have special meanings and influence the behaviour
of barebox. Most but not all of them are consolidated in the :ref:`global_device`.
Since it's hard to remember which variables these are and if the current
barebox has support for them the :ref:`command_magicvar` command can print a list
-of all variables with special meaning along with a short description::
+of all variables with special meaning along with a short description:
+
+.. code-block:: console
barebox:/ magicvar
OPTARG optarg for hush builtin getopt
--
2.18.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-07-25 14:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-25 14:18 [PATCH 1/2] Documentation: don't highlight literal blocks as shell script Roland Hieber
2018-07-25 14:18 ` Roland Hieber [this message]
2018-08-08 7:00 ` [PATCH 2/2] Documentation: fix code block and literal block highlighting Sascha Hauer
2018-08-09 12:01 ` Roland Hieber
2018-08-09 22:22 ` [PATCH v2 " Roland Hieber
2018-08-10 6:41 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180725141811.25588-2-r.hieber@pengutronix.de \
--to=r.hieber@pengutronix.de \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox