doc: board: ti: Use prompt prompt_style to simplify documentation

The sphinx-prompt documentation[0] provides examples on how we can use
prompt as a parameter to simplify the description. Use the same.

While at it, ensure to make all relevant prompts clarified such as gdb
prompts.

[0] http://sbrunner.github.io/sphinx-prompt/

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst
index 4627da3..7a3125d 100644
--- a/doc/board/ti/am335x_evm.rst
+++ b/doc/board/ti/am335x_evm.rst
@@ -84,8 +84,7 @@
 
 Within the SECDEV package exists an image creation script:
 
-.. prompt:: bash
-   :prompts: $
+.. prompt:: bash $
 
    ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
 
@@ -97,8 +96,7 @@
 The script is basically the only required interface to the TI SECDEV
 package for creating a bootable SPL image for secure TI devices.
 
-.. prompt:: bash
-   :prompts: $
+.. prompt:: bash $
 
    create-boot-image.sh \
 		<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
@@ -184,8 +182,7 @@
 SECDEV package. Within the SECDEV package exists a script to process
 an input binary image:
 
-.. prompt:: bash
-   :prompts: $
+.. prompt:: bash $
 
    ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
 
@@ -206,8 +203,7 @@
 Invoking the secure-binary-image script for Secure Devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. prompt:: bash
-   :prompts: $
+.. prompt:: bash $
 
    secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
 
@@ -247,8 +243,7 @@
 
 2. Flashing NAND via MMC/SD
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
    mmc rescan
@@ -334,8 +329,7 @@
 write garbage into the area, you must delete it from the partition table
 first.
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    # Ensure we are able to talk with this mmc device
    mmc rescan
@@ -366,8 +360,7 @@
 afterwards) along with a Falcon Mode aware MLO and the FAT partition has
 already been created and marked bootable:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    mmc rescan
    # Load kernel and device tree into memory, perform export
@@ -386,8 +379,7 @@
 
 So then you:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    fatwrite mmc 0:1 0x80f80000 args 8928
 
@@ -400,8 +392,7 @@
 along with a Falcon Mode aware MLO written to the correct locations for
 booting and mtdparts have been configured correctly for the board:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    nand read ${loadaddr} kernel
    load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
@@ -425,8 +416,7 @@
 device, so the user can easily configure their platform differently from
 the command line:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    dm tree
 
@@ -444,8 +434,7 @@
 Typically here any network command performed using the usb_ether
 interface would work, while using other gadgets would fail:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    fastboot usb 0
 
@@ -462,8 +451,7 @@
 use the unbind command specifying the class and index parameters (as
 shown above in the 'dm tree' output) to target the driver to unbind:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    unbind ethernet 1
 
@@ -471,8 +459,7 @@
 first USB device controller, the fastboot gadget will now be able to
 bind with it:
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    dm tree
 
diff --git a/doc/board/ti/dra7xx_evm.rst b/doc/board/ti/dra7xx_evm.rst
index 4503b5e..8e5d955 100644
--- a/doc/board/ti/dra7xx_evm.rst
+++ b/doc/board/ti/dra7xx_evm.rst
@@ -71,8 +71,7 @@
 'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to
 set boot0 as the boot device.
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    setenv autoload no
    usb start
diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 1629d3b..5167925 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -197,7 +197,7 @@
 .. k3_rst_include_end_common_env_vars_desc
 
 .. k3_rst_include_start_common_env_vars_defn
-.. prompt:: bash
+.. prompt:: bash $
 
  export CC32=arm-linux-gnueabihf-
  export CC64=aarch64-linux-gnu-
@@ -247,7 +247,7 @@
    uses the split binary flow)
 
 .. k3_rst_include_start_build_steps_spl_r5
-.. prompt:: bash
+.. prompt:: bash $
 
  # inside u-boot source
  make $UBOOT_CFG_CORTEXR
@@ -283,7 +283,7 @@
    application cores on the main domain.
 
 .. k3_rst_include_start_build_steps_tfa
-.. prompt:: bash
+.. prompt:: bash $
 
  # inside trusted-firmware-a source
  make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
@@ -299,7 +299,7 @@
    using the TrustZone technology built into the core.
 
 .. k3_rst_include_start_build_steps_optee
-.. prompt:: bash
+.. prompt:: bash $
 
  # inside optee_os source
  make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
@@ -311,7 +311,7 @@
    64bit core in the main domain.
 
 .. k3_rst_include_start_build_steps_uboot
-.. prompt:: bash
+.. prompt:: bash $
 
  # inside u-boot source
  make $UBOOT_CFG_CORTEXA
@@ -410,14 +410,14 @@
   be passing to mkimage for signing the fitImage and embedding the key in
   the u-boot dtb.
 
-  .. prompt:: bash
+  .. prompt:: bash $
 
     mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
     $UBOOT_PATH/build/a72/dts/dt.dtb
 
   For signing a secondary platform, pass the -K parameter to that DTB
 
-  .. prompt:: bash
+  .. prompt:: bash $
 
     mkimage -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
     $UBOOT_PATH/build/a72/arch/arm/dts/k3-j721e-sk.dtb
@@ -476,8 +476,7 @@
 
 **Writing to MMC/EMMC**
 
-.. prompt:: bash
-  :prompts: =>
+.. prompt:: bash =>
 
   env export -t $loadaddr <list of variables>
   fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize}
@@ -490,8 +489,7 @@
 If manually needs to be done then the environment can be read from the
 filesystem and then imported
 
-.. prompt:: bash
-  :prompts: =>
+.. prompt:: bash =>
 
   fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
   env import -t ${loadaddr} ${filesize}
@@ -551,7 +549,7 @@
   box support by OpenOCD. The board-specific documentation will
   cover the details and any adapter/dongle recommendations.
 
-.. prompt:: bash
+.. prompt:: bash $
 
  openocd -v
 
@@ -569,7 +567,7 @@
 other package managers. Please refer to the `OpenOCD Documentation
 <https://openocd.org/>`_ for more recent installation steps.
 
-.. prompt:: bash
+.. prompt:: bash $
 
   # Check the packages to be installed: needs deb-src in sources.list
   sudo apt build-dep openocd
@@ -599,7 +597,7 @@
 if building from a source, ensure that the udev rules are installed
 correctly to ensure a sane system.
 
-.. prompt:: bash
+.. prompt:: bash $
 
   # Go to the OpenOCD source directory
   cd openocd
@@ -617,7 +615,7 @@
 
 Most systems come with gdb-multiarch package.
 
-.. prompt:: bash
+.. prompt:: bash $
 
   # Install gdb-multiarch package
   sudo apt-get install gdb-multiarch
@@ -833,7 +831,7 @@
 
 .. k3_rst_include_start_openocd_cfg_XDS110
 
-.. prompt:: bash
+.. prompt:: bash $
 
   openocd -f board/{board_of_choice}.cfg
 
@@ -847,7 +845,7 @@
   <https://github.com/openocd-org/openocd/blob/master/tcl/target/ti_k3.cfg#L59>`_
   to decide if the SoC is supported or not.
 
-.. prompt:: bash
+.. prompt:: bash $
 
   openocd -f openocd_connect.cfg
 
@@ -922,13 +920,13 @@
 GDB-based IDE. To start up GDB in the terminal, run the following
 command.
 
-.. prompt:: bash
+.. prompt:: bash $
 
   gdb-multiarch
 
 To connect to your desired core, run the following command within GDB:
 
-.. code-block:: bash
+.. prompt:: bash (gdb)
 
   target extended-remote localhost:{port for desired core}
 
@@ -945,13 +943,13 @@
 
 * Prior to relocation:
 
-.. code-block:: bash
+.. prompt:: bash (gdb)
 
   symbol-file {path to elf file}
 
 * After relocation:
 
-.. code-block:: bash
+.. prompt:: bash (gdb)
 
   # Drop old symbol file
   symbol-file
@@ -962,7 +960,7 @@
 
 In the above example of AM625,
 
-.. code-block:: bash
+.. prompt:: bash (gdb)
 
   target extended-remote localhost:3338     <- R5F (Wakeup Domain)
   target extended-remote localhost:3334     <- A53 (Main Domain)
@@ -982,7 +980,7 @@
 needed and run the following GDB commands to step out of the debug
 loop set in the ``board_init_f`` function.
 
-.. code-block:: bash
+.. prompt:: bash (gdb)
 
   set x = 0
   continue
diff --git a/doc/board/ti/ks2_evm.rst b/doc/board/ti/ks2_evm.rst
index 5e3ecad..16c2e57 100644
--- a/doc/board/ti/ks2_evm.rst
+++ b/doc/board/ti/ks2_evm.rst
@@ -122,8 +122,7 @@
 
 To build u-boot.bin, u-boot-spi.gph, MLO:
 
-.. prompt:: bash
-   :prompts: $
+.. prompt:: bash $
 
    make k2hk_evm_defconfig
    make
@@ -197,8 +196,7 @@
 4. Free Run the target as described earlier (step 4) to get U-Boot prompt
 5. At the U-Boot console type following to setup U-Boot environment variables.
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    setenv addr_uboot 0x87000000
    setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000>
@@ -226,8 +224,7 @@
 4. Free Run the target as described earlier (step 4) to get U-Boot prompt
 5. At the U-Boot console type following to setup U-Boot environment variables.
 
-.. prompt:: bash
-   :prompts: =>
+.. prompt:: bash =>
 
    setenv filesize <size in hex of MLO rounded to hex 0x10000>
    run burn_uboot_nand
@@ -249,10 +246,10 @@
 1. On the regular UART port start xmodem transfer of the u-boot.bin
 2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM
 
-.. prompt:: bash
+.. prompt:: bash BMC>
 
-   BMC> bootmode #4
-   MBC> reboot
+  bootmode #4
+  reboot
 
 3. When xmodem is complete you should see the U-Boot starts on the UART port