Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2025-02-26 04:17:09 +00:00
Code Issues Projects Releases Packages Wiki Activity

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

Browse source 
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>
This commit is contained in:
Nishanth Menon 2023-11-02 23:40:25 -05:00 • committed by Heinrich Schuchardt
parent bd00ef74f3
commit 81cf99e723
4 changed files with 41 additions and 60 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
doc/board/ti/am335x_evm.rst
View file

@ -84,8 +84,7 @@ bootable image was not created.
Within the SECDEV package exists an image creation script: Within the SECDEV package exists an image creation script:
.. prompt:: bash .. prompt:: bash $
:prompts: $
${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
@ -97,8 +96,7 @@ possible.
The script is basically the only required interface to the TI SECDEV The script is basically the only required interface to the TI SECDEV
package for creating a bootable SPL image for secure TI devices. package for creating a bootable SPL image for secure TI devices.
.. prompt:: bash .. prompt:: bash $
:prompts: $
create-boot-image.sh \ create-boot-image.sh \
<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR> <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
@ -184,8 +182,7 @@ The exact details of the how the images are secured is handled by the
SECDEV package. Within the SECDEV package exists a script to process SECDEV package. Within the SECDEV package exists a script to process
an input binary image: an input binary image:
.. prompt:: bash .. prompt:: bash $
:prompts: $
${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
@ -206,8 +203,7 @@ only accessible when the ARM core is operating in the secure mode).
Invoking the secure-binary-image script for Secure Devices Invoking the secure-binary-image script for Secure Devices
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. prompt:: bash .. prompt:: bash $
:prompts: $
secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE> secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
@ -247,8 +243,7 @@ into memory, then written to NAND.
2. Flashing NAND via MMC/SD 2. Flashing NAND via MMC/SD
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
# select BOOTSEL to MMC/SD boot and boot from MMC/SD card # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
mmc rescan mmc rescan
@ -334,8 +329,7 @@ had a FAT partition (such as on a Beaglebone Black) it is not enough to
write garbage into the area, you must delete it from the partition table write garbage into the area, you must delete it from the partition table
first. first.
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
# Ensure we are able to talk with this mmc device # Ensure we are able to talk with this mmc device
mmc rescan mmc rescan
@ -366,8 +360,7 @@ the FAT filesystem (only the uImage MUST be for this to function
afterwards) along with a Falcon Mode aware MLO and the FAT partition has afterwards) along with a Falcon Mode aware MLO and the FAT partition has
already been created and marked bootable: already been created and marked bootable:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
mmc rescan mmc rescan
# Load kernel and device tree into memory, perform export # Load kernel and device tree into memory, perform export
@ -386,8 +379,7 @@ This will print a number of lines and then end with something like:
So then you: So then you:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
fatwrite mmc 0:1 0x80f80000 args 8928 fatwrite mmc 0:1 0x80f80000 args 8928
@ -400,8 +392,7 @@ already located on the NAND somewhere (such as filesystem or mtd partition)
along with a Falcon Mode aware MLO written to the correct locations for along with a Falcon Mode aware MLO written to the correct locations for
booting and mtdparts have been configured correctly for the board: booting and mtdparts have been configured correctly for the board:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
nand read ${loadaddr} kernel nand read ${loadaddr} kernel
load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
@ -425,8 +416,7 @@ The output of the 'dm tree' command shows which driver is bound to which
device, so the user can easily configure their platform differently from device, so the user can easily configure their platform differently from
the command line: the command line:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
dm tree dm tree
@ -444,8 +434,7 @@ the command line:
Typically here any network command performed using the usb_ether Typically here any network command performed using the usb_ether
interface would work, while using other gadgets would fail: interface would work, while using other gadgets would fail:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
fastboot usb 0 fastboot usb 0
@ -462,8 +451,7 @@ least from a bootloader point of view). The solution here would be to
use the unbind command specifying the class and index parameters (as use the unbind command specifying the class and index parameters (as
shown above in the 'dm tree' output) to target the driver to unbind: shown above in the 'dm tree' output) to target the driver to unbind:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
unbind ethernet 1 unbind ethernet 1
@ -471,8 +459,7 @@ The output of the 'dm tree' command now shows the availability of the
first USB device controller, the fastboot gadget will now be able to first USB device controller, the fastboot gadget will now be able to
bind with it: bind with it:
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
dm tree dm tree

3
doc/board/ti/dra7xx_evm.rst
View file

@ -71,8 +71,7 @@ example we load MLO and u-boot.img from the build into DDR and then use
'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to 'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to
set boot0 as the boot device. set boot0 as the boot device.
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
setenv autoload no setenv autoload no
usb start usb start

44
doc/board/ti/k3.rst
View file

@ -197,7 +197,7 @@ All of that to say you will need both a 32bit and 64bit cross compiler
.. k3_rst_include_end_common_env_vars_desc .. k3_rst_include_end_common_env_vars_desc
.. k3_rst_include_start_common_env_vars_defn .. k3_rst_include_start_common_env_vars_defn
.. prompt:: bash .. prompt:: bash $
export CC32=arm-linux-gnueabihf- export CC32=arm-linux-gnueabihf-
export CC64=aarch64-linux-gnu- export CC64=aarch64-linux-gnu-
@ -247,7 +247,7 @@ Building tiboot3.bin
uses the split binary flow) uses the split binary flow)
.. k3_rst_include_start_build_steps_spl_r5 .. k3_rst_include_start_build_steps_spl_r5
.. prompt:: bash .. prompt:: bash $
# inside u-boot source # inside u-boot source
make $UBOOT_CFG_CORTEXR make $UBOOT_CFG_CORTEXR
@ -283,7 +283,7 @@ firmware if your device using a split firmware.
application cores on the main domain. application cores on the main domain.
.. k3_rst_include_start_build_steps_tfa .. k3_rst_include_start_build_steps_tfa
.. prompt:: bash .. prompt:: bash $
# inside trusted-firmware-a source # inside trusted-firmware-a source
make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \ make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
@ -299,7 +299,7 @@ use the `lite` option.
using the TrustZone technology built into the core. using the TrustZone technology built into the core.
.. k3_rst_include_start_build_steps_optee .. k3_rst_include_start_build_steps_optee
.. prompt:: bash .. prompt:: bash $
# inside optee_os source # inside optee_os source
make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \ make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
@ -311,7 +311,7 @@ use the `lite` option.
64bit core in the main domain. 64bit core in the main domain.
.. k3_rst_include_start_build_steps_uboot .. k3_rst_include_start_build_steps_uboot
.. prompt:: bash .. prompt:: bash $
# inside u-boot source # inside u-boot source
make $UBOOT_CFG_CORTEXA make $UBOOT_CFG_CORTEXA
@ -410,14 +410,14 @@ and the same can be extended to other platforms
be passing to mkimage for signing the fitImage and embedding the key in be passing to mkimage for signing the fitImage and embedding the key in
the u-boot dtb. the u-boot dtb.
.. prompt:: bash .. prompt:: bash $
mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
$UBOOT_PATH/build/a72/dts/dt.dtb $UBOOT_PATH/build/a72/dts/dt.dtb
For signing a secondary platform, pass the -K parameter to that 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 mkimage -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
$UBOOT_PATH/build/a72/arch/arm/dts/k3-j721e-sk.dtb $UBOOT_PATH/build/a72/arch/arm/dts/k3-j721e-sk.dtb
@ -476,8 +476,7 @@ then the saveenv command and can be used across various bootmodes too.
**Writing to MMC/EMMC** **Writing to MMC/EMMC**
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
env export -t $loadaddr <list of variables> env export -t $loadaddr <list of variables>
fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize} fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize}
@ -490,8 +489,7 @@ mmcdev) and set the environments.
If manually needs to be done then the environment can be read from the If manually needs to be done then the environment can be read from the
filesystem and then imported filesystem and then imported
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile} fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
env import -t ${loadaddr} ${filesize} env import -t ${loadaddr} ${filesize}
@ -551,7 +549,7 @@ Refer to the release notes corresponding to the `OpenOCD version
box support by OpenOCD. The board-specific documentation will box support by OpenOCD. The board-specific documentation will
cover the details and any adapter/dongle recommendations. cover the details and any adapter/dongle recommendations.
.. prompt:: bash .. prompt:: bash $
openocd -v openocd -v
@ -569,7 +567,7 @@ systems, but equivalent instructions should exist for systems with
other package managers. Please refer to the `OpenOCD Documentation other package managers. Please refer to the `OpenOCD Documentation
<https://openocd.org/>`_ for more recent installation steps. <https://openocd.org/>`_ for more recent installation steps.
.. prompt:: bash .. prompt:: bash $
# Check the packages to be installed: needs deb-src in sources.list # Check the packages to be installed: needs deb-src in sources.list
sudo apt build-dep openocd sudo apt build-dep openocd
@ -599,7 +597,7 @@ The step is not necessary if the distribution supports the OpenOCD, but
if building from a source, ensure that the udev rules are installed if building from a source, ensure that the udev rules are installed
correctly to ensure a sane system. correctly to ensure a sane system.
.. prompt:: bash .. prompt:: bash $
# Go to the OpenOCD source directory # Go to the OpenOCD source directory
cd openocd cd openocd
@ -617,7 +615,7 @@ Step 2: Setup GDB
Most systems come with gdb-multiarch package. Most systems come with gdb-multiarch package.
.. prompt:: bash .. prompt:: bash $
# Install gdb-multiarch package # Install gdb-multiarch package
sudo apt-get install gdb-multiarch sudo apt-get install gdb-multiarch
@ -833,7 +831,7 @@ Startup OpenOCD to debug the platform as follows:
.. k3_rst_include_start_openocd_cfg_XDS110 .. k3_rst_include_start_openocd_cfg_XDS110
.. prompt:: bash .. prompt:: bash $
openocd -f board/{board_of_choice}.cfg openocd -f board/{board_of_choice}.cfg
@ -847,7 +845,7 @@ Startup OpenOCD to debug the platform as follows:
<https://github.com/openocd-org/openocd/blob/master/tcl/target/ti_k3.cfg#L59>`_ <https://github.com/openocd-org/openocd/blob/master/tcl/target/ti_k3.cfg#L59>`_
to decide if the SoC is supported or not. to decide if the SoC is supported or not.
.. prompt:: bash .. prompt:: bash $
openocd -f openocd_connect.cfg openocd -f openocd_connect.cfg
@ -922,13 +920,13 @@ To debug using this server, use GDB directly or your preferred
GDB-based IDE. To start up GDB in the terminal, run the following GDB-based IDE. To start up GDB in the terminal, run the following
command. command.
.. prompt:: bash .. prompt:: bash $
gdb-multiarch gdb-multiarch
To connect to your desired core, run the following command within GDB: 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} target extended-remote localhost:{port for desired core}
@ -945,13 +943,13 @@ To load symbols:
* Prior to relocation: * Prior to relocation:
.. code-block:: bash .. prompt:: bash (gdb)
symbol-file {path to elf file} symbol-file {path to elf file}
* After relocation: * After relocation:
.. code-block:: bash .. prompt:: bash (gdb)
# Drop old symbol file # Drop old symbol file
symbol-file symbol-file
@ -962,7 +960,7 @@ To load symbols:
In the above example of AM625, In the above example of AM625,
.. code-block:: bash .. prompt:: bash (gdb)
target extended-remote localhost:3338 <- R5F (Wakeup Domain) target extended-remote localhost:3338 <- R5F (Wakeup Domain)
target extended-remote localhost:3334 <- A53 (Main Domain) target extended-remote localhost:3334 <- A53 (Main Domain)
@ -982,7 +980,7 @@ breakpoints. To exit the debug loop added above, add any breakpoints
needed and run the following GDB commands to step out of the debug needed and run the following GDB commands to step out of the debug
loop set in the ``board_init_f`` function. loop set in the ``board_init_f`` function.
.. code-block:: bash .. prompt:: bash (gdb)
set x = 0 set x = 0
continue continue

15
doc/board/ti/ks2_evm.rst
View file

@ -122,8 +122,7 @@ Don't forget to add CROSS_COMPILE.
To build u-boot.bin, u-boot-spi.gph, MLO: To build u-boot.bin, u-boot-spi.gph, MLO:
.. prompt:: bash .. prompt:: bash $
:prompts: $
make k2hk_evm_defconfig make k2hk_evm_defconfig
make make
@ -197,8 +196,7 @@ instructions:
4. Free Run the target as described earlier (step 4) to get U-Boot prompt 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. 5. At the U-Boot console type following to setup U-Boot environment variables.
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
setenv addr_uboot 0x87000000 setenv addr_uboot 0x87000000
setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000> setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000>
@ -226,8 +224,7 @@ instructions:
4. Free Run the target as described earlier (step 4) to get U-Boot prompt 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. 5. At the U-Boot console type following to setup U-Boot environment variables.
.. prompt:: bash .. prompt:: bash =>
:prompts: =>
setenv filesize <size in hex of MLO rounded to hex 0x10000> setenv filesize <size in hex of MLO rounded to hex 0x10000>
run burn_uboot_nand run burn_uboot_nand
@ -249,10 +246,10 @@ Open BMC and regular UART terminals.
1. On the regular UART port start xmodem transfer of the u-boot.bin 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 2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM
.. prompt:: bash .. prompt:: bash BMC>
BMC> bootmode #4 bootmode #4
MBC> reboot reboot
3. When xmodem is complete you should see the U-Boot starts on the UART port 3. When xmodem is complete you should see the U-Boot starts on the UART port