* [PATCH 1/2] Documentation: don't highlight literal blocks as shell script @ 2018-07-25 14:18 Roland Hieber 2018-07-25 14:18 ` [PATCH 2/2] Documentation: fix code block and literal block highlighting Roland Hieber 0 siblings, 1 reply; 6+ messages in thread From: Roland Hieber @ 2018-07-25 14:18 UTC (permalink / raw) To: barebox; +Cc: Roland Hieber There are multiple cases in the documentation where literal blocks are used for literal, preformatted text. Although it is possible to use `.. code-block: none` in these cases instead of literal `::` blocks, follow the principle of least surprise and don't apply any syntax highlighting at all for literal blocks. Signed-off-by: Roland Hieber <r.hieber@pengutronix.de> --- Documentation/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/conf.py b/Documentation/conf.py index dbd4a80caa..ec6ec0470b 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -259,4 +259,4 @@ texinfo_documents = [ # If true, do not generate a @detailmenu in the "Top" node's menu. #texinfo_no_detailmenu = False -highlight_language = 'sh' +highlight_language = 'none' -- 2.18.0 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 2/2] Documentation: fix code block and literal block highlighting 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 2018-08-08 7:00 ` Sascha Hauer 2018-08-09 22:22 ` [PATCH v2 " Roland Hieber 0 siblings, 2 replies; 6+ messages in thread From: Roland Hieber @ 2018-07-25 14:18 UTC (permalink / raw) To: barebox; +Cc: Roland Hieber 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] Documentation: fix code block and literal block highlighting 2018-07-25 14:18 ` [PATCH 2/2] Documentation: fix code block and literal block highlighting Roland Hieber @ 2018-08-08 7:00 ` Sascha Hauer 2018-08-09 12:01 ` Roland Hieber 2018-08-09 22:22 ` [PATCH v2 " Roland Hieber 1 sibling, 1 reply; 6+ messages in thread From: Sascha Hauer @ 2018-08-08 7:00 UTC (permalink / raw) To: Roland Hieber; +Cc: barebox On Wed, Jul 25, 2018 at 04:18:11PM +0200, Roland Hieber wrote: > 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 +++- This patch does not apply. In my tree the filenames are all different, for example this one is Documentation/boards/imx/wandboard.rst (with a lowercase 'w') in my tree. However, applied 1/2. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] Documentation: fix code block and literal block highlighting 2018-08-08 7:00 ` Sascha Hauer @ 2018-08-09 12:01 ` Roland Hieber 0 siblings, 0 replies; 6+ messages in thread From: Roland Hieber @ 2018-08-09 12:01 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox On Wed, Aug 08, 2018 at 09:00:18AM +0200, Sascha Hauer wrote: > On Wed, Jul 25, 2018 at 04:18:11PM +0200, Roland Hieber wrote: > > 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 +++- > > This patch does not apply. In my tree the filenames are all different, > for example this one is Documentation/boards/imx/wandboard.rst (with a > lowercase 'w') in my tree. You're right, I didn't build on top of my own patches from my previous doc series… Will send v2 shortly. - Roland -- Roland Hieber | r.hieber@pengutronix.de | Pengutronix e.K. | https://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2 2/2] Documentation: fix code block and literal block highlighting 2018-07-25 14:18 ` [PATCH 2/2] Documentation: fix code block and literal block highlighting Roland Hieber 2018-08-08 7:00 ` Sascha Hauer @ 2018-08-09 22:22 ` Roland Hieber 2018-08-10 6:41 ` Sascha Hauer 1 sibling, 1 reply; 6+ messages in thread From: Roland Hieber @ 2018-08-09 22:22 UTC (permalink / raw) To: barebox; +Cc: Roland Hieber 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> --- v1 -> v2: - patch should now apply to next - drop first patch, which was already applied --- Documentation/boards/imx.rst | 8 +++++-- Documentation/boards/imx/amazon-kindle-3.rst | 6 +++-- .../boards/imx/garz-fricke-vincell.rst | 4 +++- .../boards/imx/phytec-phycore-i.mx31.rst | 8 +++++-- 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 +++++++---- 33 files changed, 200 insertions(+), 71 deletions(-) diff --git a/Documentation/boards/imx.rst b/Documentation/boards/imx.rst index db889ee702..56fd3ab41c 100644 --- a/Documentation/boards/imx.rst +++ b/Documentation/boards/imx.rst @@ -32,7 +32,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 @@ -152,7 +154,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/amazon-kindle-3.rst b/Documentation/boards/imx/amazon-kindle-3.rst index dffb7efb2d..6b5d9fe535 100644 --- a/Documentation/boards/imx/amazon-kindle-3.rst +++ b/Documentation/boards/imx/amazon-kindle-3.rst @@ -15,7 +15,7 @@ To upload and run a new bootloader the device can be put into USB-downloader mode by the SOC microcode when Vol+ is pressed during startup. A new USB device "SE Blank RINGO" should appear, barebox may be uploaded using -:: +.. code-block:: console $ scripts/imx/imx-usb-loader barebox.imximg @@ -26,7 +26,9 @@ imx-usb-loader) 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:: +e.g. just write the imx-header and the application section: + +.. 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/imx/garz-fricke-vincell.rst b/Documentation/boards/imx/garz-fricke-vincell.rst index 09d87d67c3..4127c8bc8c 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 d9a981b998..0feb22257a 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/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 82a33a3219..026ed1b9c0 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 7502d3de10..a79ae83d56 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 f0598bc2b5..5651569dc2 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: https://git.pengutronix.de/cgit/tools/microcom -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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 2/2] Documentation: fix code block and literal block highlighting 2018-08-09 22:22 ` [PATCH v2 " Roland Hieber @ 2018-08-10 6:41 ` Sascha Hauer 0 siblings, 0 replies; 6+ messages in thread From: Sascha Hauer @ 2018-08-10 6:41 UTC (permalink / raw) To: Roland Hieber; +Cc: barebox On Fri, Aug 10, 2018 at 12:22:59AM +0200, Roland Hieber wrote: > 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> > --- > v1 -> v2: > - patch should now apply to next > - drop first patch, which was already applied Applied, thanks Sascha > > --- > Documentation/boards/imx.rst | 8 +++++-- > Documentation/boards/imx/amazon-kindle-3.rst | 6 +++-- > .../boards/imx/garz-fricke-vincell.rst | 4 +++- > .../boards/imx/phytec-phycore-i.mx31.rst | 8 +++++-- > 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 +++++++---- > 33 files changed, 200 insertions(+), 71 deletions(-) > > diff --git a/Documentation/boards/imx.rst b/Documentation/boards/imx.rst > index db889ee702..56fd3ab41c 100644 > --- a/Documentation/boards/imx.rst > +++ b/Documentation/boards/imx.rst > @@ -32,7 +32,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 > @@ -152,7 +154,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/amazon-kindle-3.rst b/Documentation/boards/imx/amazon-kindle-3.rst > index dffb7efb2d..6b5d9fe535 100644 > --- a/Documentation/boards/imx/amazon-kindle-3.rst > +++ b/Documentation/boards/imx/amazon-kindle-3.rst > @@ -15,7 +15,7 @@ To upload and run a new bootloader the device can be put into USB-downloader > mode by the SOC microcode when Vol+ is pressed during startup. A new USB > device "SE Blank RINGO" should appear, barebox may be uploaded using > > -:: > +.. code-block:: console > > $ scripts/imx/imx-usb-loader barebox.imximg > > @@ -26,7 +26,9 @@ imx-usb-loader) > 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:: > +e.g. just write the imx-header and the application section: > + > +.. 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/imx/garz-fricke-vincell.rst b/Documentation/boards/imx/garz-fricke-vincell.rst > index 09d87d67c3..4127c8bc8c 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 d9a981b998..0feb22257a 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/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 82a33a3219..026ed1b9c0 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 7502d3de10..a79ae83d56 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 f0598bc2b5..5651569dc2 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: > > https://git.pengutronix.de/cgit/tools/microcom > > -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 > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-08-10 6:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-25 14:18 [PATCH 1/2] Documentation: don't highlight literal blocks as shell script Roland Hieber 2018-07-25 14:18 ` [PATCH 2/2] Documentation: fix code block and literal block highlighting Roland Hieber 2018-08-08 7:00 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox