All trademarks are the property of their respective owners.
There are multiple boot modes supported by J7 SoC, mainly can be divided into two types: peripheral booting and memory booting. Different boot mode required different hardware design and software configuration, details can be found in boot mode setting.
There is another special boot mode called “No boot” mode which is used for JTAG connection to directly load the image to DDR through JTAG interface during development phases.
For J7 based design, OSPI boot mode is normally chosen because of boot speed. Then, how to flash the OSPI flash during development and manufacturing is an important part of the design process. Different projects use different hardware design, and bring different interface. Even under the same hardware design, different silicon type will also bring different restrictions. So one flashing solution cannot be used to deal with all cases, this note introduces the OSPI flashing solution in HS silicon with different hardware design.
As shown in Figure 1-1, from security enabled product perspective, three phases included in J7 SOC development. In each phase, different device types have different features and are used for different purposes.
GP silicon is the basic silicon without security features enabled, on GP silicon, JTAG is enabled and then it can be used for flashing, meanwhile all the system binary does not need to be signed and encrypted, so GP silicon normally used for functionality development.
HS-FS is Field Securable silicon with valid secure features, but not enabled until the customer keys are programmed during manufacture. The Device Management and Security Control (DMSC) subsystem is protected by TI security keys. On HS-FS silicon, the JTAG can still be used for flashing.
HS-SE is Security Enforced silicon with customer keys programmed. This is done with the Key writer tools provided by TI at customer site. Therefore, the image running on the silicon need to be signed and encrypted by the keys and JTAG is disabled by default to enforce the security. On HS-SE silicon, separate consideration required for flashing.
According to the system design, different flashing solution can be chosen. The solution can follow the flowchart shown in Figure 1-2.
How to select the proper flashing solution depends on the system design.
As shown in above flow chart, secondary boot mode like SD boot mode is required to do the flashing when UART interface is not available. This requires switching to the secondary memory boot mode that may:
All the HS flashing solution were tested in SDK7.1 software with J721E-EVM hardware and works fine.
This section introduces the OSPI flashing solution with UART interface supported and divided into two parts. For more information on whether to support UART boot mode, see install the Uniflash tools.
Use the following steps to flash the binary to OSPI through UART in Linux PC:
# sudo ./dslite.sh --mode processors -c <COM Port> -f <Flash Programmer Binary with Full Path> -i 0
Example:
# sudo ./dslite.sh –mode processors -c /dev/ttyUSB1 -f (Path to Uniflash Install Directory) /processors/FlashWriter/j721e_evm /uart_j721e_evm_flash_programmer_release.tiimage -i 0
# sudo ./dslite.sh --mode processors -c <COM Port> -f <Flash Programmer Binary with Full Path> -i 0
Example:
# sudo ./dslite.sh –mode processors -c /dev/ttyUSB1 -f (Path to Uniflash Install Directory) /processors/FlashWriter/j721e_evm /uart_j721e_evm_flash_programmer_release.tiimage -i 0
If the design can support UART interface but cannot support UART boot mode, use the following steps can be used for OSPI flashing.
# sudo ./dslite.sh --mode load --config=<CCS Target Config file (ccxml) with Full Path>
-f <Flash Programmer Binary with Full Path> -n <Core ID to be Connected to JTAG on the Target Platform>
Example:
#sudo ./dslite.sh --mode load --config=/home/ti/CCSTargetConfigurations/j721e.ccxml -f (Path to Uniflash Install Directory) /processors/FlashWriter/j721e_evm /uart_j721e_evm_flash_programmer_release.tiimage -n 8
# sudo ./dslite.sh --mode processors -c <COM Port> -f <Path to the binary to be flashed> -d <Flash Device Type> -o <offset>
Example:
#sudo ./dslite.sh –mode processors -c /dev/ttyUSB1 -f (SDK Install Directory)/pdk/packages/ti/boot/sbl/binary/j721e_evm/cust
/bin/sbl_cust_img_mcu1_0_release.tiimage -d 3 -o 0
If the UART interface is not supported and there are other memory boot modes besides OSPI boot mode, like SD boot mode, below steps required for flashing:
$make keywriter_img
#......
# SBL image ~/ti-processor-sdk-rtos-j721e-evm-07_01_00_11/pdk_jacinto_07_01_00_45/packages/ti/boot/sbl/example/k3MulticoreApp/binary/keywriter_img_j721e_release.tiimage created.
#Keywriter Revision: 01.00.00.00 (Mar 7 2021 - 20:15:01)
# OTP Keywriter ver: 20.8.5-w2020.23-am64x-14-g7409e
#Beginning key programming sequence
#Taking OTP configuration from 0x41c7e000
#Debug response: 0x0
#Key programming is complete
Hit any key to stop autoboot: 0
=>
=> sf probe
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
=> fatload mmc 1 ${loadaddr} sbl_ospi_img_mcu1_0_release.tiimage
231444 bytes read in 5 ms (44.1 MiB/s)
=> sf update ${loadaddr} 0x0 0x40000
device 0 offset 0x0, size 0x40000
262144 bytes written, 0 bytes skipped in 1.331s, speed 201225 B/s
=>
Same procedure also applies to other memory boot modes, only need to stop in u-boot phase and flash OSPI.