diff options
Diffstat (limited to 'doc')
57 files changed, 388 insertions, 282 deletions
diff --git a/doc/README.davinci b/doc/README.davinci index f368f99..ea81279 100644 --- a/doc/README.davinci +++ b/doc/README.davinci @@ -70,7 +70,7 @@ http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development- 2) TI OMAP-L138 LCDK http://focus.ti.com/docs/prod/folders/print/omap-l138.html -http://www.ti.com/tool/TMDXLCDK138 +https://www.ti.com/tool/TMDXLCDK138 Davinci special defines ======================= diff --git a/doc/README.omap3 b/doc/README.omap3 index 3a1ac81..d1e6be9 100644 --- a/doc/README.omap3 +++ b/doc/README.omap3 @@ -163,8 +163,8 @@ Links [1] OMAP3: -http://www.ti.com/omap3 (high volume) and -http://www.ti.com/omap35x (broad market) +https://www.ti.com/omap3 (high volume) and +https://www.ti.com/omap35x (broad market) [2] OMAP3530 BeagleBoard: diff --git a/doc/README.serial_dt_baud b/doc/README.serial_dt_baud new file mode 100644 index 0000000..f8768d0 --- /dev/null +++ b/doc/README.serial_dt_baud @@ -0,0 +1,41 @@ +Fetch serial baudrate from DT +----------------------------- + +To support fetching of baudrate from DT, the following is done:- + +The baudrate configured in Kconfig symbol CONFIG_BAUDRATE is taken by default by serial. +If change of baudrate is required then the Kconfig symbol CONFIG_BAUDRATE needs to +changed and U-Boot recompilation is required or the U-Boot environment needs to be updated. + +To avoid this, add support to fetch the baudrate directly from the device tree file and +update the environment. + +The default environment stores the default baudrate value. When default baudrate and dtb +baudrate are not same glitches are seen on the serial. +So, the environment also needs to be updated with the dtb baudrate to avoid the glitches on +the serial which is enabled by OF_SERIAL_BAUD. + +The Kconfig SPL_ENV_SUPPORT needs to be enabled to allow patching in SPL. + +The Kconfig DEFAULT_ENV_IS_RW which is enabled by OF_SERIAL_BAUD with making the environment +writable. + +The ofnode_read_baud() function parses and fetches the baudrate value from the DT. This value +is validated and updated to baudrate during serial init. Padding is added at the end of the +default environment and the dt baudrate is updated with the latest value. + +Example:- + +The serial port options are of the form "bbbbpnf", where "bbbb" is the baud rate, "p" is parity ("n", "o", or "e"), +"n" is number of bits, and "f" is flow control ("r" for RTS or omit it). Default is "115200n8". + +chosen { + bootargs = "earlycon console=ttyPS0,115200 clk_ignore_unused root=/dev/ram0 rw init_fatal_sh=1"; + stdout-path = "serial0:115200n8"; + }; + +From the chosen node, stdout-path property is obtained as string. + + stdout-path = "serial0:115200n8"; + +The string is parsed to get the baudrate 115200. This string is converted to integer and updated to the environment. diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst index 4ecdc31..f966f8b 100644 --- a/doc/arch/arm64.ffa.rst +++ b/doc/arch/arm64.ffa.rst @@ -40,7 +40,7 @@ The U-Boot FF-A support provides the following parts: - Sandbox FF-A test cases. FF-A and SMC specifications -------------------------------------------- +--------------------------- The current implementation of the U-Boot FF-A support relies on `FF-A v1.0 specification`_ and uses SMC32 calling convention which @@ -56,12 +56,12 @@ Hypervisors are supported if they are configured to trap SMC calls. The FF-A support uses 64-bit registers as per `SMC Calling Convention v1.2 specification`_. Supported hardware --------------------------------- +------------------ Aarch64 plaforms Configuration ----------------------- +------------- CONFIG_ARM_FFA_TRANSPORT Enables the FF-A support. Turn this on if you want to use FF-A @@ -70,7 +70,7 @@ CONFIG_ARM_FFA_TRANSPORT When using sandbox, the sandbox FF-A emulator and FF-A sandbox driver will be used. FF-A ABIs under the hood ---------------------------------------- +------------------------ Invoking an FF-A ABI involves providing to the secure world/hypervisor the expected arguments from the ABI. @@ -89,7 +89,7 @@ The driver reads the response and processes it accordingly. This methodology applies to all the FF-A ABIs. FF-A bus discovery on Arm 64-bit platforms ---------------------------------------------- +------------------------------------------ When CONFIG_ARM_FFA_TRANSPORT is enabled, the FF-A bus is considered as an architecture feature and discovered using ARM_SMCCC_FEATURES mechanism. @@ -136,7 +136,7 @@ When one of the above actions fails, probing fails and the driver stays not acti and can be probed again if needed. Requirements for clients -------------------------------------- +------------------------ When using the FF-A bus with EFI, clients must query the SPs they are looking for during EFI boot-time mode using the service UUID. @@ -159,13 +159,13 @@ the 32-bit or 64-bit version of FFA_MSG_SEND_DIRECT_{REQ, RESP}. The calling convention between U-Boot and the secure world stays the same: SMC32. Requirements for user drivers -------------------------------------- +----------------------------- Users who want to implement their custom FF-A device driver while reusing the FF-A Uclass can do so by implementing their own invoke_ffa_fn() in the user driver. The bus driver layer ------------------------------- +-------------------- FF-A support comes on top of the SMCCC layer and is implemented by the FF-A Uclass drivers/firmware/arm-ffa/arm-ffa-uclass.c @@ -210,7 +210,7 @@ The following features are provided: - FF-A bus can be compiled and used without EFI Relationship between the sandbox emulator and the FF-A device ---------------------------------------------------------------- +------------------------------------------------------------- :: @@ -222,7 +222,7 @@ Relationship between the sandbox emulator and the FF-A device ffa 0 [ ] sandbox_arm_ffa `-- sandbox-arm-ffa The armffa command ------------------------------------ +------------------ armffa is a command showcasing how to use the FF-A bus and how to invoke the driver operations. diff --git a/doc/board/AndesTech/ae350.rst b/doc/board/AndesTech/ae350.rst index 42a2b4d..99622fd 100644 --- a/doc/board/AndesTech/ae350.rst +++ b/doc/board/AndesTech/ae350.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ AE350 -====== +===== AE350 is the mainline SoC produced by Andes Technology using AndesV5 CPU core based on RISC-V architecture. diff --git a/doc/board/actions/cubieboard7.rst b/doc/board/actions/cubieboard7.rst index 74f2b12..1f73fc4 100644 --- a/doc/board/actions/cubieboard7.rst +++ b/doc/board/actions/cubieboard7.rst @@ -20,7 +20,7 @@ Though, one can enter ADFU mode and flash debian image(from host machine) where getting into u-boot prompt is easy. Enter ADFU Mode ----------------- +--------------- Before write the firmware, let the development board entering the ADFU mode: insert one end of the USB cable to the PC, press and hold the ADFU button, and then connect @@ -28,7 +28,7 @@ the other end of the USB cable to the Mini USB port of the development board, re the ADFU button, after connecting it will enter the ADFU mode. Check whether entered ADFU Mode --------------------------------- +------------------------------- The user needs to run the following command on the PC side to check if the ADFU device is detected. ID realted to "Actions Semiconductor Co., Ltd" means that diff --git a/doc/board/actions/index.rst b/doc/board/actions/index.rst index c596879..e925fcd 100644 --- a/doc/board/actions/index.rst +++ b/doc/board/actions/index.rst @@ -2,7 +2,7 @@ .. Copyright (C) 2020 Amit Singh Tomar <amittomer25@gmail.com> Actions -======== +======= .. toctree:: :maxdepth: 2 diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst index fc1d75a..052a969 100644 --- a/doc/board/armltd/index.rst +++ b/doc/board/armltd/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 Arm Ltd -============= +======= .. toctree:: :maxdepth: 2 diff --git a/doc/board/mediatek/index.rst b/doc/board/mediatek/index.rst index 38cd8cb..c55d5ae 100644 --- a/doc/board/mediatek/index.rst +++ b/doc/board/mediatek/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ Mediatek -========= +======== .. toctree:: :maxdepth: 2 diff --git a/doc/board/nxp/imx8mm_evk.rst b/doc/board/nxp/imx8mm_evk.rst index 327ce6e..bb11029 100644 --- a/doc/board/nxp/imx8mm_evk.rst +++ b/doc/board/nxp/imx8mm_evk.rst @@ -36,7 +36,7 @@ Get the ddr firmware $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir) Build U-Boot for sd card --------------------------- +------------------------ .. code-block:: bash @@ -54,8 +54,8 @@ Boot ---- Set Boot switch to SD boot -Build U-Boot for qspi flash card ------------------------------------- +Build U-Boot for qspi flash card +-------------------------------- .. code-block:: bash @@ -81,7 +81,8 @@ From sd card to memory $ sf write $loadaddr 0x00 <size_of_flash.bin_in_hex> Boot from QSPI Flash ------------------------ +-------------------- + Set Boot Switch to QSPI Flash Pin configuration for imx8mm_revC evk to boot from qspi flash diff --git a/doc/board/nxp/ls1046ardb.rst b/doc/board/nxp/ls1046ardb.rst index 49b4842..8c0bc82 100644 --- a/doc/board/nxp/ls1046ardb.rst +++ b/doc/board/nxp/ls1046ardb.rst @@ -54,7 +54,7 @@ LS1046ARDB board Overview - ARM JTAG support Memory map from core's view ----------------------------- +--------------------------- ================== ================== ================ ===== Start Address End Address Description Size diff --git a/doc/board/nxp/mx6ul_14x14_evk.rst b/doc/board/nxp/mx6ul_14x14_evk.rst index 3e57ba1..c135a21 100644 --- a/doc/board/nxp/mx6ul_14x14_evk.rst +++ b/doc/board/nxp/mx6ul_14x14_evk.rst @@ -4,7 +4,7 @@ mx6ul_14x14_evk =============== How to use U-Boot on Freescale MX6UL 14x14 EVK ------------------------------------------------ +---------------------------------------------- - Build U-Boot for MX6UL 14x14 EVK: diff --git a/doc/board/openpiton/riscv64.rst b/doc/board/openpiton/riscv64.rst index 3a97793..c379fbf 100644 --- a/doc/board/openpiton/riscv64.rst +++ b/doc/board/openpiton/riscv64.rst @@ -11,14 +11,14 @@ OpenPiton has been verified in both ASIC and multiple Xilinx FPGA prototypes running full-stack Debian linux. RISC-V Standard Bootflow -------------------------- +------------------------ Currently, OpenPiton implements RISC-V standard bootflow in the following steps mover.S -> u-boot-spl -> opensbi -> u-boot -> Linux This board supports S-mode u-boot as well as M-mode SPL Building OpenPition ---------------------- +------------------- If you'd like to build OpenPiton, please go to OpenPiton github repo (at https://github.com/PrincetonUniversity/openpiton) to build from the latest diff --git a/doc/board/purism/librem5.rst b/doc/board/purism/librem5.rst index fb050c6..a7975e1 100644 --- a/doc/board/purism/librem5.rst +++ b/doc/board/purism/librem5.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ Librem5 -========== +======= U-Boot for the Purism Librem5 phone diff --git a/doc/board/qualcomm/sdm845.rst b/doc/board/qualcomm/sdm845.rst index d3f218e..a65f00d 100644 --- a/doc/board/qualcomm/sdm845.rst +++ b/doc/board/qualcomm/sdm845.rst @@ -2,10 +2,11 @@ .. sectionauthor:: Dzmitry Sankouski <dsankouski@gmail.com> Snapdragon 845 -================ +============== About this ---------- + This document describes the information about Qualcomm Snapdragon 845 supported boards and it's usage steps. @@ -17,8 +18,10 @@ Qualcomm's UEFI-based ABL (Android) Bootloader. Installation ------------ + Build ^^^^^ + Setup ``CROSS_COMPILE`` for aarch64 and build U-Boot for your board:: $ export CROSS_COMPILE=<aarch64 toolchain prefix> @@ -29,10 +32,12 @@ This will build ``u-boot.bin`` in the configured output directory. Generate FIT image ^^^^^^^^^^^^^^^^^^ + See doc/uImage.FIT for more details Pack android boot image ^^^^^^^^^^^^^^^^^^^^^^^ + We'll assemble android boot image with ``u-boot.bin`` instead of linux kernel, and FIT image instead of ``initramfs``. Android bootloader expect gzipped kernel with appended dtb, so let's mimic linux to satisfy stock bootloader. diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index ffbebd0..18d0b6f 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -116,6 +116,7 @@ List of mainline supported Rockchip boards: - Edgeble Neural Compute Module 6A SoM - Neu6a (neu6a-io-rk3588) - Edgeble Neural Compute Module 6B SoM - Neu6b (neu6b-io-rk3588) - FriendlyElec NanoPC-T6 (nanopc-t6-rk3588) + - Pine64 QuartzPro64 (quartzpro64-rk3588) - Radxa ROCK 5A (rock5a-rk3588s) - Radxa ROCK 5B (rock5b-rk3588) - Xunlong Orange Pi 5 (orangepi-5-rk3588s) diff --git a/doc/board/samsung/index.rst b/doc/board/samsung/index.rst index c904372..971805e 100644 --- a/doc/board/samsung/index.rst +++ b/doc/board/samsung/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ Samsung -======== +======= .. toctree:: :maxdepth: 2 diff --git a/doc/board/st/st-dt.rst b/doc/board/st/st-dt.rst index 67e16ef..2a285c8 100644 --- a/doc/board/st/st-dt.rst +++ b/doc/board/st/st-dt.rst @@ -2,7 +2,7 @@ .. sectionauthor:: Patrick Delaunay <patrick.delaunay@foss.st.com> U-Boot device tree bindings ----------------------------- +--------------------------- The U-Boot specific bindings are defined in the U-Boot directory: doc/device-tree-bindings diff --git a/doc/board/st/stm32_MCU.rst b/doc/board/st/stm32_MCU.rst index 7ff7c73..61650bc 100644 --- a/doc/board/st/stm32_MCU.rst +++ b/doc/board/st/stm32_MCU.rst @@ -2,7 +2,7 @@ .. sectionauthor:: Patrice Chotard <patrice.chotardy@foss.st.com> STM32 MCU boards -================= +================ This is a quick instruction for setup STM32 MCU boards. diff --git a/doc/board/starfive/visionfive2.rst b/doc/board/starfive/visionfive2.rst index 9ee758e..6cb033e 100644 --- a/doc/board/starfive/visionfive2.rst +++ b/doc/board/starfive/visionfive2.rst @@ -4,7 +4,8 @@ StarFive VisionFive2 ==================== JH7110 RISC-V SoC ---------------------- +----------------- + The JH7110 is 4+1 64-bit RISC-V SoC from StarFive. The StarFive VisionFive2 development platform is based on JH7110 and capable diff --git a/doc/board/thead/index.rst b/doc/board/thead/index.rst index 41566d3..2c4b3fb 100644 --- a/doc/board/thead/index.rst +++ b/doc/board/thead/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ T-HEAD -======== +====== .. toctree:: :maxdepth: 1 diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst index 2ba651e..7a3125d 100644 --- a/doc/board/ti/am335x_evm.rst +++ b/doc/board/ti/am335x_evm.rst @@ -59,7 +59,7 @@ from Texas Instruments. The tools used to generate boot images for secure devices are part of a secure development package (SECDEV) that can be downloaded from: - http://www.ti.com/mysecuresoftware (login required) + https://www.ti.com/mysecuresoftware (login required) The secure development package is access controlled due to NDA and export control restrictions. Access must be requested and granted by TI before the @@ -84,8 +84,7 @@ bootable image was not created. 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 @@ possible. 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 @@ 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 an input binary image: -.. prompt:: bash - :prompts: $ +.. prompt:: bash $ ${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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. prompt:: bash - :prompts: $ +.. prompt:: bash $ secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE> @@ -247,8 +243,7 @@ into memory, then written to NAND. 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 @@ 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 first. -.. prompt:: bash - :prompts: => +.. prompt:: bash => # Ensure we are able to talk with this mmc device 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 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 @@ This will print a number of lines and then end with something like: So then you: -.. prompt:: bash - :prompts: => +.. prompt:: bash => 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 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 @@ 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 the command line: -.. prompt:: bash - :prompts: => +.. prompt:: bash => dm tree @@ -444,8 +434,7 @@ the command line: 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 @@ least from a bootloader point of view). The solution here would be to 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 @@ 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 bind with it: -.. prompt:: bash - :prompts: => +.. prompt:: bash => dm tree diff --git a/doc/board/ti/am62x_beagleplay.rst b/doc/board/ti/am62x_beagleplay.rst index 39913b2..44e728d 100644 --- a/doc/board/ti/am62x_beagleplay.rst +++ b/doc/board/ti/am62x_beagleplay.rst @@ -55,22 +55,22 @@ Set the variables corresponding to this platform: .. include:: k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config" - $ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config" - $ export TFA_BOARD=lite - $ # we dont use any extra TFA parameters - $ unset TFA_EXTRA_ARGS - $ export OPTEE_PLATFORM=k3-am62x - $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y" + export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config" + export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config" + export TFA_BOARD=lite + # we dont use any extra TFA parameters + unset TFA_EXTRA_ARGS + export OPTEE_PLATFORM=k3-am62x + export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y" .. include:: am62x_sk.rst :start-after: .. am62x_evm_rst_include_start_build_steps :end-before: .. am62x_evm_rst_include_end_build_steps Target Images --------------- +------------- Copy the below images to an SD card and boot: * tiboot3-am62x-gp-evm.bin from R5 build as tiboot3.bin @@ -109,7 +109,7 @@ There are multiple storage media options on BeaglePlay, but primarily: depends on the SD card quality. Flash to uSD card or how to deal with "bricked" Board --------------------------------------------------------- +----------------------------------------------------- When deploying or working on Linux, it's common to use the onboard eMMC. However, avoiding the eMMC and using the uSD card is safer when @@ -174,24 +174,24 @@ boot1 partition depends on A/B update requirements. The following are the steps from Linux shell to program eMMC: -.. code-block:: bash +.. prompt:: bash # - # # Enable Boot0 boot - # mmc bootpart enable 1 2 /dev/mmcblk0 - # mmc bootbus set single_backward x1 x8 /dev/mmcblk0 - # mmc hwreset enable /dev/mmcblk0 + # Enable Boot0 boot + mmc bootpart enable 1 2 /dev/mmcblk0 + mmc bootbus set single_backward x1 x8 /dev/mmcblk0 + mmc hwreset enable /dev/mmcblk0 - # # Clear eMMC boot0 - # echo '0' >> /sys/class/block/mmcblk0boot0/force_ro - # dd if=/dev/zero of=/dev/mmcblk0boot0 count=32 bs=128k - # # Write tiboot3.bin - # dd if=tiboot3.bin of=/dev/mmcblk0boot0 bs=128k + # Clear eMMC boot0 + echo '0' >> /sys/class/block/mmcblk0boot0/force_ro + dd if=/dev/zero of=/dev/mmcblk0boot0 count=32 bs=128k + # Write tiboot3.bin + dd if=tiboot3.bin of=/dev/mmcblk0boot0 bs=128k - # # Copy the rest of the boot binaries - # mount /dev/mmcblk0p1 /boot/firmware - # cp tispl.bin /boot/firmware - # cp u-boot.img /boot/firmware - # sync + # Copy the rest of the boot binaries + mount /dev/mmcblk0p1 /boot/firmware + cp tispl.bin /boot/firmware + cp u-boot.img /boot/firmware + sync .. warning :: diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index d7437c6..b12dc85 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -2,7 +2,7 @@ .. sectionauthor:: Vignesh Raghavendra <vigneshr@ti.com> AM62 Platforms -=============== +============== Introduction: ------------- @@ -76,15 +76,15 @@ Set the variables corresponding to this platform: .. include:: ../ti/k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR=am62x_evm_r5_defconfig - $ export UBOOT_CFG_CORTEXA=am62x_evm_a53_defconfig - $ export TFA_BOARD=lite - $ # we dont use any extra TFA parameters - $ unset TFA_EXTRA_ARGS - $ export OPTEE_PLATFORM=k3-am62x - $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y" + export UBOOT_CFG_CORTEXR=am62x_evm_r5_defconfig + export UBOOT_CFG_CORTEXA=am62x_evm_a53_defconfig + export TFA_BOARD=lite + # we dont use any extra TFA parameters + unset TFA_EXTRA_ARGS + export OPTEE_PLATFORM=k3-am62x + export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y" .. am62x_evm_rst_include_start_build_steps @@ -117,7 +117,8 @@ Set the variables corresponding to this platform: .. am62x_evm_rst_include_end_build_steps Target Images --------------- +------------- + In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC variant (GP, HS-FS, HS-SE) requires a different source for these files. @@ -270,6 +271,6 @@ detailed setup information. To start OpenOCD and connect to the board -.. code-block:: bash +.. prompt:: bash $ openocd -f board/ti_am625evm.cfg diff --git a/doc/board/ti/am64x_evm.rst b/doc/board/ti/am64x_evm.rst index db27461..6ae35b3 100644 --- a/doc/board/ti/am64x_evm.rst +++ b/doc/board/ti/am64x_evm.rst @@ -65,16 +65,16 @@ Set the variables corresponding to this platform: .. include:: k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR=am64x_evm_r5_defconfig - $ export UBOOT_CFG_CORTEXA=am64x_evm_a53_defconfig - $ export TFA_BOARD=lite - $ # we dont use any extra TFA parameters - $ unset TFA_EXTRA_ARGS - $ export OPTEE_PLATFORM=k3-am64x - $ # we dont use any extra TFA parameters - $ unset OPTEE_EXTRA_ARGS + export UBOOT_CFG_CORTEXR=am64x_evm_r5_defconfig + export UBOOT_CFG_CORTEXA=am64x_evm_a53_defconfig + export TFA_BOARD=lite + # we dont use any extra TFA parameters + unset TFA_EXTRA_ARGS + export OPTEE_PLATFORM=k3-am64x + # we dont use any extra TFA parameters + unset OPTEE_EXTRA_ARGS .. am64x_evm_rst_include_start_build_steps @@ -107,7 +107,8 @@ Set the variables corresponding to this platform: .. am64x_evm_rst_include_end_build_steps Target Images --------------- +------------- + In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC variant (GP, HS-FS, HS-SE) requires a different source for these files. diff --git a/doc/board/ti/am65x_evm.rst b/doc/board/ti/am65x_evm.rst index 7cebb1c..89011c0 100644 --- a/doc/board/ti/am65x_evm.rst +++ b/doc/board/ti/am65x_evm.rst @@ -22,7 +22,7 @@ cores, voltage domains and peripherals: 3. MAIN domain: * Quad core 64-bit ARM Cortex-A53 -More info can be found in TRM: http://www.ti.com/lit/pdf/spruid7 +More info can be found in TRM: https://www.ti.com/lit/pdf/spruid7 Platform information: @@ -75,16 +75,16 @@ Set the variables corresponding to this platform: .. include:: k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR=am65x_evm_r5_defconfig - $ export UBOOT_CFG_CORTEXA=am65x_evm_a53_defconfig - $ export TFA_BOARD=generic - $ # we dont use any extra TFA parameters - $ unset TFA_EXTRA_ARGS - $ export OPTEE_PLATFORM=k3-am65x - $ # we dont use any extra OP-TEE parameters - $ unset OPTEE_EXTRA_ARGS + export UBOOT_CFG_CORTEXR=am65x_evm_r5_defconfig + export UBOOT_CFG_CORTEXA=am65x_evm_a53_defconfig + export TFA_BOARD=generic + # we dont use any extra TFA parameters + unset TFA_EXTRA_ARGS + export OPTEE_PLATFORM=k3-am65x + # we dont use any extra OP-TEE parameters + unset OPTEE_EXTRA_ARGS .. am65x_evm_rst_include_start_build_steps @@ -117,7 +117,8 @@ Set the variables corresponding to this platform: .. am65x_evm_rst_include_end_build_steps Target Images --------------- +------------- + In order to boot we need tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img. Each SoC variant (GP and HS) requires a different source for these files. @@ -159,32 +160,32 @@ The following commands can be used to download tiboot3.bin, tispl.bin, u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0 partition at respective addresses. -.. code-block:: text +.. prompt:: bash => - => mmc dev 0 1 - => fatload mmc 1 ${loadaddr} tiboot3.bin - => mmc write ${loadaddr} 0x0 0x400 - => fatload mmc 1 ${loadaddr} tispl.bin - => mmc write ${loadaddr} 0x400 0x1000 - => fatload mmc 1 ${loadaddr} u-boot.img - => mmc write ${loadaddr} 0x1400 0x2000 - => fatload mmc 1 ${loadaddr} sysfw.itb - => mmc write ${loadaddr} 0x3600 0x800 + mmc dev 0 1 + fatload mmc 1 ${loadaddr} tiboot3.bin + mmc write ${loadaddr} 0x0 0x400 + fatload mmc 1 ${loadaddr} tispl.bin + mmc write ${loadaddr} 0x400 0x1000 + fatload mmc 1 ${loadaddr} u-boot.img + mmc write ${loadaddr} 0x1400 0x2000 + fatload mmc 1 ${loadaddr} sysfw.itb + mmc write ${loadaddr} 0x3600 0x800 To give the ROM access to the boot partition, the following commands must be used for the first time: -.. code-block:: text +.. prompt:: bash => - => mmc partconf 0 1 1 1 - => mmc bootbus 0 1 0 0 + mmc partconf 0 1 1 1 + mmc bootbus 0 1 0 0 To create a software partition for the rootfs, the following command can be used: -.. code-block:: text +.. prompt:: bash => - => gpt write mmc 0 ${partitions} + gpt write mmc 0 ${partitions} eMMC layout: @@ -194,11 +195,11 @@ eMMC layout: Kernel image and DT are expected to be present in the /boot folder of rootfs. To boot kernel from eMMC, use the following commands: -.. code-block:: text +.. prompt:: bash => - => setenv mmcdev 0 - => setenv bootpart 0 - => boot + setenv mmcdev 0 + setenv bootpart 0 + boot OSPI: ----- @@ -210,17 +211,17 @@ Below commands can be used to download tiboot3.bin, tispl.bin, u-boot.img, and sysfw.itb over tftp and then flash those to OSPI at their respective addresses. -.. code-block:: text +.. prompt:: bash => - => sf probe - => tftp ${loadaddr} tiboot3.bin - => sf update $loadaddr 0x0 $filesize - => tftp ${loadaddr} tispl.bin - => sf update $loadaddr 0x80000 $filesize - => tftp ${loadaddr} u-boot.img - => sf update $loadaddr 0x280000 $filesize - => tftp ${loadaddr} sysfw.itb - => sf update $loadaddr 0x6C0000 $filesize + sf probe + tftp ${loadaddr} tiboot3.bin + sf update $loadaddr 0x0 $filesize + tftp ${loadaddr} tispl.bin + sf update $loadaddr 0x80000 $filesize + tftp ${loadaddr} u-boot.img + sf update $loadaddr 0x280000 $filesize + tftp ${loadaddr} sysfw.itb + sf update $loadaddr 0x6C0000 $filesize Flash layout for OSPI: @@ -233,10 +234,10 @@ ospi.rootfs just like in SD card case. U-Boot looks for UBI volume named To boot kernel from OSPI, at the U-Boot prompt: -.. code-block:: text +.. prompt:: bash => - => setenv boot ubi - => boot + setenv boot ubi + boot UART: ----- @@ -280,19 +281,19 @@ is fully loaded (from sysfw.itb) and started. Example bash script sequence for running on a Linux host PC feeding all boot artifacts needed to the device: -.. code-block:: text +.. prompt:: bash $ - MCU_DEV=/dev/ttyUSB1 - MAIN_DEV=/dev/ttyUSB0 + MCU_DEV=/dev/ttyUSB1 + MAIN_DEV=/dev/ttyUSB0 - stty -F $MCU_DEV 115200 cs8 -cstopb -parenb - stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb + stty -F $MCU_DEV 115200 cs8 -cstopb -parenb + stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb - sb --xmodem tiboot3.bin > $MCU_DEV < $MCU_DEV - sb --ymodem sysfw.itb > $MCU_DEV < $MCU_DEV - sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV - sleep 1 - sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV + sb --xmodem tiboot3.bin > $MCU_DEV < $MCU_DEV + sb --ymodem sysfw.itb > $MCU_DEV < $MCU_DEV + sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV + sleep 1 + sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV Debugging U-Boot ---------------- @@ -314,6 +315,6 @@ detailed setup information. To start OpenOCD and connect to the board -.. code-block:: bash +.. prompt:: bash $ openocd -f board/ti_am654evm.cfg 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 @@ 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 set boot0 as the boot device. -.. prompt:: bash - :prompts: => +.. prompt:: bash => setenv autoload no usb start diff --git a/doc/board/ti/j7200_evm.rst b/doc/board/ti/j7200_evm.rst index bcf8dc1..d4a823f 100644 --- a/doc/board/ti/j7200_evm.rst +++ b/doc/board/ti/j7200_evm.rst @@ -64,16 +64,16 @@ Set the variables corresponding to this platform: .. include:: k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR=j7200_evm_r5_defconfig - $ export UBOOT_CFG_CORTEXA=j7200_evm_a72_defconfig - $ export TFA_BOARD=generic - $ # we dont use any extra TFA parameters - $ unset TFA_EXTRA_ARGS - $ export OPTEE_PLATFORM=k3-j7200 - $ # we dont use any extra OP-TEE parameters - $ unset OPTEE_EXTRA_ARGS + export UBOOT_CFG_CORTEXR=j7200_evm_r5_defconfig + export UBOOT_CFG_CORTEXA=j7200_evm_a72_defconfig + export TFA_BOARD=generic + # we dont use any extra TFA parameters + unset TFA_EXTRA_ARGS + export OPTEE_PLATFORM=k3-j7200 + # we dont use any extra OP-TEE parameters + unset OPTEE_EXTRA_ARGS .. j7200_evm_rst_include_start_build_steps @@ -106,7 +106,8 @@ Set the variables corresponding to this platform: .. j7200_evm_rst_include_end_build_steps Target Images --------------- +------------- + In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC variant (GP, HS-FS, HS-SE) requires a different source for these files. @@ -225,6 +226,6 @@ detailed setup information. To start OpenOCD and connect to the board -.. code-block:: bash +.. prompt:: bash $ openocd -f board/ti_j7200evm.cfg diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst index cadaac0..113475d 100644 --- a/doc/board/ti/j721e_evm.rst +++ b/doc/board/ti/j721e_evm.rst @@ -27,7 +27,7 @@ specific processing cores and peripherals: * 2 x C66x Digital signal processor sub system * C71x Digital signal processor sub-system with MMA. -More info can be found in TRM: http://www.ti.com/lit/pdf/spruil1 +More info can be found in TRM: https://www.ti.com/lit/pdf/spruil1 Platform information: @@ -69,16 +69,16 @@ Set the variables corresponding to this platform: .. include:: k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR=j721e_evm_r5_defconfig - $ export UBOOT_CFG_CORTEXA=j721e_evm_a72_defconfig - $ export TFA_BOARD=generic - $ # we dont use any extra TFA parameters - $ unset TFA_EXTRA_ARGS - $ export OPTEE_PLATFORM=k3-j721e - $ # we dont use any extra OP-TEE parameters - $ unset OPTEE_EXTRA_ARGS + export UBOOT_CFG_CORTEXR=j721e_evm_r5_defconfig + export UBOOT_CFG_CORTEXA=j721e_evm_a72_defconfig + export TFA_BOARD=generic + # we dont use any extra TFA parameters + unset TFA_EXTRA_ARGS + export OPTEE_PLATFORM=k3-j721e + # we dont use any extra OP-TEE parameters + unset OPTEE_EXTRA_ARGS .. j721e_evm_rst_include_start_build_steps @@ -111,7 +111,8 @@ Set the variables corresponding to this platform: .. j721e_evm_rst_include_end_build_steps Target Images --------------- +------------- + In order to boot we need tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img. Each SoC variant (GP, HS-FS and HS-SE) requires a different source for these files. @@ -202,17 +203,17 @@ Below commands can be used to download tiboot3.bin, tispl.bin, u-boot.img, and sysfw.itb over tftp and then flash those to OSPI at their respective addresses. -.. code-block:: text +.. prompt:: bash => - => sf probe - => tftp ${loadaddr} tiboot3.bin - => sf update $loadaddr 0x0 $filesize - => tftp ${loadaddr} tispl.bin - => sf update $loadaddr 0x80000 $filesize - => tftp ${loadaddr} u-boot.img - => sf update $loadaddr 0x280000 $filesize - => tftp ${loadaddr} sysfw.itb - => sf update $loadaddr 0x6C0000 $filesize + sf probe + tftp ${loadaddr} tiboot3.bin + sf update $loadaddr 0x0 $filesize + tftp ${loadaddr} tispl.bin + sf update $loadaddr 0x80000 $filesize + tftp ${loadaddr} u-boot.img + sf update $loadaddr 0x280000 $filesize + tftp ${loadaddr} sysfw.itb + sf update $loadaddr 0x6C0000 $filesize Flash layout for OSPI: @@ -254,6 +255,6 @@ detailed setup information. To start OpenOCD and connect to the board -.. code-block:: bash +.. prompt:: bash $ openocd -f board/ti_j721eevm.cfg diff --git a/doc/board/ti/j721s2_evm.rst b/doc/board/ti/j721s2_evm.rst index fec2aca..f5c48c9 100644 --- a/doc/board/ti/j721s2_evm.rst +++ b/doc/board/ti/j721s2_evm.rst @@ -6,6 +6,7 @@ J721S2 and AM68 Platforms Introduction: ------------- + The J721S2 family of SoCs are part of K3 Multicore SoC architecture platform targeting automotive applications. They are designed as a low power, high performance and highly integrated device architecture, adding significant @@ -38,6 +39,7 @@ Platform information: Boot Flow: ---------- + Below is the pictorial representation of boot flow: .. image:: img/boot_diagram_k3_current.svg @@ -60,6 +62,7 @@ Sources: Build procedure: ---------------- + 0. Setup the environment variables: .. include:: k3.rst @@ -75,15 +78,15 @@ Set the variables corresponding to this platform: .. include:: k3.rst :start-after: .. k3_rst_include_start_common_env_vars_defn :end-before: .. k3_rst_include_end_common_env_vars_defn -.. code-block:: bash +.. prompt:: bash $ - $ export UBOOT_CFG_CORTEXR=j721s2_evm_r5_defconfig - $ export UBOOT_CFG_CORTEXA=j721s2_evm_a72_defconfig - $ export TFA_BOARD=generic - $ export TFA_EXTRA_ARGS="K3_USART=0x8" - $ # The following is not a typo, j784s4 is the OP-TEE platform for j721s2 - $ export OPTEE_PLATFORM=k3-j784s4 - $ export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8" + export UBOOT_CFG_CORTEXR=j721s2_evm_r5_defconfig + export UBOOT_CFG_CORTEXA=j721s2_evm_a72_defconfig + export TFA_BOARD=generic + export TFA_EXTRA_ARGS="K3_USART=0x8" + # The following is not a typo, j784s4 is the OP-TEE platform for j721s2 + export OPTEE_PLATFORM=k3-j784s4 + export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8" .. j721s2_evm_rst_include_start_build_steps @@ -120,7 +123,8 @@ Set the variables corresponding to this platform: .. j721s2_evm_rst_include_end_build_steps Target Images --------------- +------------- + In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC variant (GP, HS-FS, HS-SE) requires a different source for these files. @@ -296,7 +300,7 @@ Debugging U-Boot on J721S2-EVM To start OpenOCD and connect to the board -.. code-block:: bash +.. prompt:: bash $ openocd -f board/ti_j721s2evm.cfg diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index 89d70db..5167925 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -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_start_common_env_vars_defn -.. prompt:: bash +.. prompt:: bash $ export CC32=arm-linux-gnueabihf- export CC64=aarch64-linux-gnu- @@ -238,7 +238,7 @@ other build sources. we shall use the following, in the build descriptions below .. k3_rst_include_end_board_env_vars_desc Building tiboot3.bin -^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^ 1. To generate the U-Boot SPL for the wakeup domain, use the following commands, substituting :code:`{SOC}` for the name of your device (eg: @@ -247,7 +247,7 @@ Building tiboot3.bin 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 @@ -273,7 +273,7 @@ domain of your K3 SoC. UBoot SPL will only look for and load the files with these names. Building tispl.bin -^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^ The `tispl.bin` is a standard fitImage combining the firmware need for the main domain to function properly as well as Device Management (DM) @@ -283,7 +283,7 @@ firmware if your device using a split firmware. 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 @@ use the `lite` option. 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 @@ use the `lite` option. 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 @@ and the same can be extended to other platforms 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 @@ then the saveenv command and can be used across various bootmodes too. **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 @@ mmcdev) and set the environments. 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 @@ Refer to the release notes corresponding to the `OpenOCD version 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 @@ systems, but equivalent instructions should exist for systems with 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 @@ The step is not necessary if the distribution supports the OpenOCD, but 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 @@ Step 2: Setup GDB 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 @@ Startup OpenOCD to debug the platform as follows: .. k3_rst_include_start_openocd_cfg_XDS110 -.. prompt:: bash +.. prompt:: bash $ 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>`_ to decide if the SoC is supported or not. -.. prompt:: bash +.. prompt:: bash $ 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 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 @@ To load symbols: * 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 @@ To load symbols: 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 @@ breakpoints. To exit the debug loop added above, add any breakpoints 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 0a78903..16c2e57 100644 --- a/doc/board/ti/ks2_evm.rst +++ b/doc/board/ti/ks2_evm.rst @@ -17,17 +17,17 @@ Documentation for this board can be found at: The K2HK board is based on Texas Instruments Keystone2 family of SoCs: K2H, K2K. More details on these SoCs are available at company websites: -K2K: http://www.ti.com/product/tci6638k2k -K2H: http://www.ti.com/product/tci6638k2h +K2K: https://www.ti.com/product/tci6638k2k +K2H: https://www.ti.com/product/tci6638k2h The K2E SoC details are available at - http://www.ti.com/lit/ds/symlink/66ak2e05.pdf + https://www.ti.com/lit/ds/symlink/66ak2e05.pdf The K2L SoC details are available at - http://www.ti.com/lit/ds/symlink/tci6630k2l.pdf + https://www.ti.com/lit/ds/symlink/tci6630k2l.pdf The K2G SoC details are available at - http://www.ti.com/lit/ds/symlink/66ak2g02.pdf + https://www.ti.com/lit/ds/symlink/66ak2g02.pdf Board Configuration ------------------- @@ -122,8 +122,7 @@ Don't forget to add CROSS_COMPILE. To build u-boot.bin, u-boot-spi.gph, MLO: -.. prompt:: bash - :prompts: $ +.. prompt:: bash $ make k2hk_evm_defconfig make @@ -197,8 +196,7 @@ instructions: 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 @@ instructions: 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 @@ Open BMC and regular UART terminals. 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 diff --git a/doc/board/xilinx/xilinx.rst b/doc/board/xilinx/xilinx.rst index 8c9afb4..5464625 100644 --- a/doc/board/xilinx/xilinx.rst +++ b/doc/board/xilinx/xilinx.rst @@ -2,7 +2,7 @@ .. (C) Copyright 2019 Xilinx, Inc. U-Boot device tree bindings ----------------------------- +--------------------------- All the device tree bindings used in U-Boot are specified in Linux kernel. Please refer dt bindings from below specified paths in Linux diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst index 23501de..3c64657 100644 --- a/doc/build/gcc.rst +++ b/doc/build/gcc.rst @@ -66,7 +66,7 @@ For building U-Boot on Alpine Linux at least the following packages are needed: Depending on the build target further packages may be needed: * sandbox with lcd: sdl2-dev -* riscv64 S-mode targests: opensbi +* riscv64 S-mode targets: opensbi * some arm64 targets: arm-trusted-firmware Prerequisites diff --git a/doc/build/source.rst b/doc/build/source.rst index 470f793..d21ee05 100644 --- a/doc/build/source.rst +++ b/doc/build/source.rst @@ -1,5 +1,5 @@ Obtaining the source -===================== +==================== The source of the U-Boot project is maintained in a Git repository. diff --git a/doc/develop/driver-model/ethernet.rst b/doc/develop/driver-model/ethernet.rst index cdbccca..73c3a72 100644 --- a/doc/develop/driver-model/ethernet.rst +++ b/doc/develop/driver-model/ethernet.rst @@ -1,5 +1,5 @@ Ethernet Driver Guide -======================= +===================== The networking stack in Das U-Boot is designed for multiple network devices to be easily added and controlled at runtime. This guide is meant for people @@ -14,7 +14,7 @@ Some drivers are still using the old Ethernet interface, differences between the two and hints about porting will be handled at the end. Driver framework ------------------- +---------------- A network driver following the driver model must declare itself using the UCLASS_ETH .id field in the U-Boot driver struct: @@ -67,7 +67,7 @@ bus. Also it would take care of any special PHY setup (power rails, enable bits for internal PHYs, etc.). Driver methods ----------------- +-------------- The real work will be done in the driver method functions the driver provides by defining the members of struct eth_ops: @@ -158,7 +158,7 @@ So the call graph at this stage would look something like: CONFIG_PHYLIB / CONFIG_CMD_MII --------------------------------- +------------------------------ If your device supports banging arbitrary values on the MII bus (pretty much every device does), you should add support for the mii command. Doing so is @@ -193,7 +193,7 @@ should logically follow. ................................................................ Legacy network drivers ------------------------- +---------------------- !!! WARNING !!! @@ -221,7 +221,7 @@ instructions on how to port this over. For the records, the old way of initialising a network driver is as follows: Old network driver registration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When U-Boot initializes, it will call the common function eth_initialize(). This will in turn call the board-specific board_eth_init() (or if that fails, diff --git a/doc/develop/driver-model/migration.rst b/doc/develop/driver-model/migration.rst index fe1ae21..03fea94 100644 --- a/doc/develop/driver-model/migration.rst +++ b/doc/develop/driver-model/migration.rst @@ -100,7 +100,7 @@ Maintainers should submit patches switching over to using CONFIG_DM_I2C and other base driver model options in time for inclusion in the 2021.10 release. CFG_SYS_TIMER_RATE and CFG_SYS_TIMER_COUNTER --------------------------------------------------- +-------------------------------------------- Deadline: 2023.01 These are legacy options which have been replaced by driver model. diff --git a/doc/develop/driver-model/nvmxip.rst b/doc/develop/driver-model/nvmxip.rst index e85dc22..4a7650c 100644 --- a/doc/develop/driver-model/nvmxip.rst +++ b/doc/develop/driver-model/nvmxip.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ NVM XIP Block Storage Emulation Driver -======================================= +====================================== Summary ------- @@ -54,12 +54,12 @@ The NVMXIP Uclass provides the following drivers: The implementation is generic and can be used by different platforms. Supported hardware --------------------------------- +------------------ Any plaform supporting readq(). Configuration ----------------------- +------------- config NVMXIP This option allows the emulation of a block storage device @@ -77,7 +77,7 @@ config NVMXIP_QSPI write their own driver (same as nvmxip_qspi in addition to the custom settings). Device Tree nodes --------------------- +----------------- Multiple QSPI XIP flash devices can be used at the same time by describing them through DT nodes. diff --git a/doc/develop/driver-model/remoteproc-framework.rst b/doc/develop/driver-model/remoteproc-framework.rst index 566495a..03a0bd0 100644 --- a/doc/develop/driver-model/remoteproc-framework.rst +++ b/doc/develop/driver-model/remoteproc-framework.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. (C) Copyright 2015 -.. Texas Instruments Incorporated - http://www.ti.com/ +.. Texas Instruments Incorporated - https://www.ti.com/ Remote Processor Framework ========================== diff --git a/doc/develop/driver-model/soc-framework.rst b/doc/develop/driver-model/soc-framework.rst index 2609fda..357e7fc 100644 --- a/doc/develop/driver-model/soc-framework.rst +++ b/doc/develop/driver-model/soc-framework.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. (C) Copyright 2020 -.. Texas Instruments Incorporated - http://www.ti.com/ +.. Texas Instruments Incorporated - https://www.ti.com/ SOC ID Framework ================ diff --git a/doc/develop/driver-model/spi-howto.rst b/doc/develop/driver-model/spi-howto.rst index 97fbf75..9dc3b9b 100644 --- a/doc/develop/driver-model/spi-howto.rst +++ b/doc/develop/driver-model/spi-howto.rst @@ -218,7 +218,7 @@ DM tells you. The name is not quite right. So in this case we would use: Write of_to_plat() [for device tree only] -------------------------------------------------- +----------------------------------------- This method will convert information in the device tree node into a C structure in your driver (called platform data). If you are not using diff --git a/doc/develop/falcon.rst b/doc/develop/falcon.rst index 2f25fc8..8a46c0e 100644 --- a/doc/develop/falcon.rst +++ b/doc/develop/falcon.rst @@ -220,7 +220,7 @@ setting the GPIO (on twister GPIO 55 is used) to kernel mode. The kernel is loaded directly by the SPL without passing through U-Boot. Example with FDT: a3m071 board -------------------------------- +------------------------------ To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get prepared/patched first. U-Boot usually inserts some dynamic values into diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index 0e75345..600bf62 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -68,7 +68,7 @@ For the next scheduled release, release candidates were made on:: * U-Boot v2024.01-rc2 was released on Mon 06 November 2023. -.. * U-Boot v2024.01-rc3 was released on Mon 20 November 2023. +* U-Boot v2024.01-rc3 was released on Mon 20 November 2023. .. * U-Boot v2024.01-rc4 was released on Mon 04 December 2023. diff --git a/doc/device-tree-bindings/clock/ti,cdce9xx.txt b/doc/device-tree-bindings/clock/ti,cdce9xx.txt index 0d01f2d..62701d2 100644 --- a/doc/device-tree-bindings/clock/ti,cdce9xx.txt +++ b/doc/device-tree-bindings/clock/ti,cdce9xx.txt @@ -4,10 +4,10 @@ Reference This binding uses the common clock binding[1]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] http://www.ti.com/product/cdce913 -[3] http://www.ti.com/product/cdce925 -[4] http://www.ti.com/product/cdce937 -[5] http://www.ti.com/product/cdce949 +[2] https://www.ti.com/product/cdce913 +[3] https://www.ti.com/product/cdce925 +[4] https://www.ti.com/product/cdce937 +[5] https://www.ti.com/product/cdce949 The driver provides clock sources for each output Y1 through Y5. diff --git a/doc/device-tree-bindings/video/tilcdc/tilcdc.txt b/doc/device-tree-bindings/video/tilcdc/tilcdc.txt index 7bf1bb4..7600801 100644 --- a/doc/device-tree-bindings/video/tilcdc/tilcdc.txt +++ b/doc/device-tree-bindings/video/tilcdc/tilcdc.txt @@ -46,7 +46,7 @@ Optional nodes: crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is for Blue[3-7]. For more details see section 3.1.1 in AM335x Silicon Errata: - http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 + https://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 Example: diff --git a/doc/usage/cmd/askenv.rst b/doc/usage/cmd/askenv.rst index 347bd59..b85cefa 100644 --- a/doc/usage/cmd/askenv.rst +++ b/doc/usage/cmd/askenv.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: askenv command -=============== +============== Synopsis -------- diff --git a/doc/usage/cmd/bootdev.rst b/doc/usage/cmd/bootdev.rst index 6c68d0b..fb638b5 100644 --- a/doc/usage/cmd/bootdev.rst +++ b/doc/usage/cmd/bootdev.rst @@ -76,7 +76,7 @@ name is provided, all hunters are run. bootdev select -~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ Use this to select a particular bootdev. You can select it by the sequence number or name, as shown in `bootdev list`. @@ -89,7 +89,7 @@ unselected. bootdev info -~~~~~~~~~~~~~~~ +~~~~~~~~~~~~ This shows information on the current bootdev, with the format looking like this: diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst index 9c5ea9c..2198ff6 100644 --- a/doc/usage/cmd/bootflow.rst +++ b/doc/usage/cmd/bootflow.rst @@ -15,6 +15,7 @@ Synopis bootflow read bootflow boot bootflow cmdline [set|get|clear|delete|auto] <param> [<value>] + bootfloe menu [-t] Description ----------- @@ -24,6 +25,9 @@ locate bootflows, list them and boot them. See :doc:`../../develop/bootstd` for more information. +Note that `CONFIG_BOOTSTD_FULL` (which enables `CONFIG_CMD_BOOTFLOW_FULL) must +be enabled to obtain full functionality with this command. Otherwise, it only +supports `bootflow scan` which scans and boots the first available bootflow. bootflow scan ~~~~~~~~~~~~~ @@ -247,6 +251,16 @@ can be used to set the early console (or console) to a suitable value so that output appears on the serial port. This is only supported by the 16550 serial driver so far. +bootflow menu +~~~~~~~~~~~~~ + +This shows a menu with available bootflows. The user can select a particular +bootflow, which then becomes the current one. + +The `-t` flag requests a text menu. Otherwise, if a display is available, a +graphical menu is shown. + + Example ------- @@ -658,6 +672,56 @@ Now the buffer can be accessed:: 77b7e4e0: 320fc000 08e8ba0f c031300f b8d0000f ...2.....01..... 77b7e4f0: 00000020 6ad8000f 00858d10 50000002 ......j.......P +This shows using a text menu to boot an OS:: + + => bootflow scan + => bootfl list + => bootfl menu -t + U-Boot : Boot Menu + + UP and DOWN to choose, ENTER to select + + > 0 mmc1 mmc1.bootdev.whole + 1 mmc1 Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + 2 mmc1 mmc1.bootdev.part_1 + 3 mmc4 mmc4.bootdev.whole + 4 mmc4 Armbian + 5 mmc4 mmc4.bootdev.part_1 + 6 mmc5 mmc5.bootdev.whole + 7 mmc5 ChromeOS + 8 mmc5 ChromeOS + U-Boot : Boot Menu + + UP and DOWN to choose, ENTER to select + + 0 mmc1 mmc1.bootdev.whole + > 1 mmc1 Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + 2 mmc1 mmc1.bootdev.part_1 + 3 mmc4 mmc4.bootdev.whole + 4 mmc4 Armbian + 5 mmc4 mmc4.bootdev.part_1 + 6 mmc5 mmc5.bootdev.whole + 7 mmc5 ChromeOS + 8 mmc5 ChromeOS + U-Boot : Boot Menu + + Selected: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + => bootfl boot + ** Booting bootflow 'mmc1.bootdev.part_1' with extlinux + Ignoring unknown command: ui + Ignoring malformed menu command: autoboot + Ignoring malformed menu command: hidden + Ignoring unknown command: totaltimeout + Fedora-Workstation-armhfp-31-1.9 Boot Options. + 1: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + Enter choice: 1 + 1: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + Retrieving file: /vmlinuz-5.3.7-301.fc31.armv7hl + Retrieving file: /initramfs-5.3.7-301.fc31.armv7hl.img + append: ro root=UUID=9732b35b-4cd5-458b-9b91-80f7047e0b8a rhgb quiet LANG=en_US.UTF-8 cma=192MB cma=256MB + Retrieving file: /dtb-5.3.7-301.fc31.armv7hl/sandbox.dtb + ... + Return value ------------ @@ -667,6 +731,9 @@ return to U-Boot. If something about the U-Boot processing fails, then the return value $? is 1. If the boot succeeds but for some reason the Operating System returns, then $? is 0, indicating success. +For `bootflow menu` the return value is $? is 0 (true) if an option was choses, +else 1. + For other subcommands, the return value $? is always 0 (true). diff --git a/doc/usage/cmd/cat.rst b/doc/usage/cmd/cat.rst index 5ef4731..5aaf497 100644 --- a/doc/usage/cmd/cat.rst +++ b/doc/usage/cmd/cat.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: cat command -=============== +=========== Synopsis -------- diff --git a/doc/usage/cmd/coninfo.rst b/doc/usage/cmd/coninfo.rst index f913148..76cb6c3 100644 --- a/doc/usage/cmd/coninfo.rst +++ b/doc/usage/cmd/coninfo.rst @@ -21,7 +21,7 @@ environment variables stdin, stdout, stderr which contain a comma separated list of device names. Example --------- +------- .. code-block:: console diff --git a/doc/usage/cmd/mmc.rst b/doc/usage/cmd/mmc.rst index c0924ba..8394f64 100644 --- a/doc/usage/cmd/mmc.rst +++ b/doc/usage/cmd/mmc.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: mmc command -============ +=========== Synopsis -------- diff --git a/doc/usage/cmd/part.rst b/doc/usage/cmd/part.rst index 8a594aa..eee5225 100644 --- a/doc/usage/cmd/part.rst +++ b/doc/usage/cmd/part.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: part command -=============== +============ Synopis ------- diff --git a/doc/usage/cmd/qfw.rst b/doc/usage/cmd/qfw.rst index ec13e09..e734b26 100644 --- a/doc/usage/cmd/qfw.rst +++ b/doc/usage/cmd/qfw.rst @@ -15,7 +15,7 @@ Synopsis Description ----------- -The *qfw* command is used to retrieve information form the QEMU firmware. +The *qfw* command is used to retrieve information from the QEMU firmware. The *qfw list* sub-command displays the QEMU firmware files. diff --git a/doc/usage/cmd/wdt.rst b/doc/usage/cmd/wdt.rst index 8d80433..8bb8b36 100644 --- a/doc/usage/cmd/wdt.rst +++ b/doc/usage/cmd/wdt.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: wdt command -============ +=========== Synopsis -------- diff --git a/doc/usage/cmd/xxd.rst b/doc/usage/cmd/xxd.rst index 0de1223..13bb438 100644 --- a/doc/usage/cmd/xxd.rst +++ b/doc/usage/cmd/xxd.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: xxd command -=============== +=========== Synopsis -------- diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst index 0580ee1..a102be1 100644 --- a/doc/usage/fit/beaglebone_vboot.rst +++ b/doc/usage/fit/beaglebone_vboot.rst @@ -86,7 +86,7 @@ c. You will now have a U-Boot image:: Step 2: Build Linux --------------------- +------------------- a. Find the kernel image ('Image') and device tree (.dtb) file you plan to use. In our case it is am335x-boneblack.dtb and it is built with the kernel. diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst index 0aad590..9691904 100644 --- a/doc/usage/measured_boot.rst +++ b/doc/usage/measured_boot.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ Measured Boot -===================== +============= U-Boot can perform a measured boot, the process of hashing various components of the boot process, extending the results in the TPM and logging the @@ -16,7 +16,7 @@ TPM PCRs match the contents of the event log. This can further be checked against the hash results of previous boots. Requirements ---------------------- +------------ * A hardware TPM 2.0 supported by the U-Boot drivers * CONFIG_TPM=y |