[参考译文] AM625：AM62x 安全启动卡在&quot；starting Keywriting&quot；—VPP 硬件切换问题

您好：

感谢您的澄清。

我们不使用 SD 卡引导;相反,我们使用 DFU (dfu-util ) 将映像刷写到目标存储器中。

请确认：

使用 dfu-util 通过 DFU 刷写 tiboot3-am62x-hs-evm.bin（使用虚拟密钥签名）是否正确？

通过 DFU 刷写此 HS-SE 签名的 SPL 时、要使用什么正确的闪存偏移或 DFU alt 设置？

是否还需要使用虚拟密钥对任何其他引导加载程序组件（例如 u-boot.img、tispl.bin）进行签名并相应地刷写？

现在、我们希望确保已成功完成密钥写入步骤、从而正确签名并刷写整个引导链。

感谢并期待您的指导。

请继续执行刷写和引导器件的流程。 唯一需要的更改是刷写 HSSE tiboot3.bin、而不是以相同的偏移刷写 HSFS。 `tispl.bin`和`u-boot.img`已使用虚拟密钥签名。

您好：

刷新  tiboot3-am62x-hs-evm.bin 后 ,这是我们得到的 R5 终端输出:-

U-Boot SPL 2023.04 (Aug 25 2025 - 15:25:36 +0530)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

我们使用“sudo dfu-util -c 1 -i 0 -a bootloader -D “此命令用于刷新 tiboot3-am62x-hs-evm.bin、这是我们得到的终端输出：-

$ sudo dfu-util -c 1 -i 0 -a bootloader -D /home/renu/my_boot/tiboot3.bin 
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to sourceforge.net/.../

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0451:6165
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 512
Copying data from PC to DFU device
Download	[=========================] 100%       294274 bytes
Download done.
state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
state(2) = dfuIDLE, status(0) = No error condition is present
Done!

您能否解释一下迄今为止启动 HSFS 器件所遵循的步骤？ 如果您有一个有效的设置、则只需使用 HSSE tiboot3.bin 而不是 HSFS。

您好：  

1. 根据要求、我们在 FS 模式下引导器件所遵循的步骤如下。

# FOR FLASHING BOOTLOADER 

sudo dfu-util -R -a bootloader -D bootloader.bin
sudo dfu-util -R -a tispl.bin -D tispl.bin
sudo dfu-util -R -a u-boot.img -D u-boot.img

stop autoboot, enter below commands -

setenv dfu_alt_info ${dfu_alt_info_emmc}
dfu 0 mmc 0

# FOR FLASHING FILESYSTEM USE BELOW COMMANDS

sudo dfu-util -a tiboot3.bin.raw -D tiboot3-raw.bin
sudo dfu-util -a tispl.bin.raw -D tispl.bin
sudo dfu-util -a u-boot.img.raw -D u-boot.img

sudo dfu-util -a rootfs -D /PATH/TO/EXT4

enter ctrl-C and enter below commands -
mmc partconf 0 1 1 1
mmc bootbus 0 2 0 0

change the switch mode and set the environment

setenv mmcdev 0
setenv bootpart 0
saveenv

    2.是的,我们有工作设置。 我们只刷写了 HSSE tiboot3.bin。

另外附上 HSSE tiboot3.bin 文件  

e2e.ti.com/.../5826.tiboot3.zip  

# FOR FLASHING BOOTLOADER 

sudo dfu-util -R -a bootloader -D bootloader.bin

如何生成此“bootloader.bin"？“？ 在这些步骤中、您只需为“bootloader.bin"和“和“tiboot3-raw.bin"使用“使用相应的 HSSE 映像。

关于 bootloader.bin、

• 到目前为止、我使用的是 GP 映像。
• 我按照以下步骤生成该文件：

Defcofig for tiboot3.bin :

make ARCH=arm CROSS_COMPILE=/home/renu/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf- am62x_evm_r5_usbdfu_defconfig O=/home/renu/ti-processor-sdk-linux-am62xx-evm-09.00.00.03/board-support/build/out/r5

build tiboot3.bin : dfu-usb

make ARCH=arm CROSS_COMPILE=/home/renu/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf- O=/home/renu/ti-processor-sdk-linux-am62xx-evm-09.00.00.03/board-support/build/out/r5/ BINMAN_INDIRS=/home/renu/ti-processor-sdk-linux-am62xx-evm-09.00.00.03/board-support/prebuilt-images/am62xx-evm/

我的问题是： — 要迁移到 HSSE、我是否需要重新注册一个专门针对 HSSE 的新 bootloader.bin（使用 HSSE 签名流程）、或者我是否可以继续使用 GP 生成的 bootloader.bin 和 HSSE tiboot3.bin？

构建会自动为所有设备类型 (GP、HSFS、HSSE) 生成“tiboot3.bin"，“，因此、因此您只需选择 HSSE。 更具体地说、编译完成后、您需要选择“board-support/u-boot-build/r5/tiboot3-am62x-hs-evm.bin"二“二进制文件。

感谢您的澄清。 我现在了解到、构建流程已经生成了所有 tiboot3 变体、包括 HSSE One。 对于 HSSE Boot、我应该特别使用： “Board-support/u-boot-build/r5/tiboot3-am62x-hs-evm.bin"二“二进制文件。

请确认我的现有 bootloader.bin 是否还需要专门为 HSSE 重建/签名、或者仅用 HSSE 版本替换 tiboot3.bin 即可启动。

请确认是否还需要专门为 HSSE

编译过程中不会生成名为“bootloader.bin"的“的文件。 您可能只是在某个时候将“tiboot3.bin"重“重命名为“bootloader.bin"。“。

您好：

我们 从以下路径刷写了 HSSE tiboot3-am62x-hs-evm.bin：“board-support/u-boot-build/r5/tiboot3-am62x-hs-evm.bin"</s>“

在终端上、我看到以下输出：

Terminal ready

U-Boot SPL 2023.04 (Aug 25 2025 - 15:25:36 +0530)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

根据我的理解、这表明 tiboot3 已成功执行、并且 SYSFW 已加载、但无法找到下一阶段的引导加载程序。

请确认：

1. 此日志是否确认 HSSE tiboot3 已成功刷写并执行？
2. 对于后续步骤、我应该刷写 HSSE 版本“board-support/u-boot-build/a53/ tispl.bin 和 u-boot“。

我相信您没有完全遵循正常工作的 HSFS 设置。 R5 SPL (tiboot3.bin) 单独构建以支持 DFU 和 eMMC。 在使用 HSFS 时、您会单独生成这些文件。 您只需要对 HSSE 执行同样的操作。

在任何情况下、您都需要单独构建 R5 SPL 以从 DFU 和 eMMC 引导。

software-dl.ti.com/.../UG-General-Info.html

您好：

我已成功预置器件、现在可以看到器件现在处于 HS-SE 模式。

SoC:   AM62X SR1.0 HS-SE
Model: Texas Instruments AM625 SK

从该代码刷写 u-boot 后、这两条输出线路用于验证器件状态。

但是、我目前在尝试通过 UART 验证器件类型 (SoC ID) 时遇到了问题。

根据文档、设置适当的引导模式开关（例如 UART 模式）后、我希望在终端上看到引导 ROM 输出（SoC ID 等）。 但我在 UART 终端上根本看不到任何输出—它完全空白。

根据文档、在设置适当的引导模式切换（例如 UART 模式）后、

请确保已为 UART 引导模式正确设置引导模式引脚。

从 A53 U-Boot 运行的以下命令的输出是什么？

=> mw 0x43000030 0x3b 0x1;reset;

我尝试使用 DFU 模式引导电路板、如下所示

$sudo dfu-util -c 1 -i 0 -a bootloader -D /home/ti/board-support/u-boot-build/r5/tiboot3-am62x-hs-evm.bin
$sudo dfu-util -R -a tispl.bin -D tispl.bin
$sudo dfu-util -R -a u-boot.img -D u-boot.img

这是从这些命令接收到的输出

Terminal ready

U-Boot SPL 2023.04 (Aug 28 2025 - 11:48:42 +0530)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes
Trying to boot from DFU
##########################################################DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 10 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.9(release):v2.9.0-614-gd7a7135d32-dirty
NOTICE:  BL31: Built : 09:34:15, Aug 24 2023

U-Boot SPL 2023.04 (Aug 28 2025 - 12:07:43 +0530)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 1856 bytes
MMC: no card present
** Bad device specification mmc 1 **
Couldn't find partition mmc 1:1
Error: could not access storage.
Trying to boot from DFU
####DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed


U-Boot 2023.04 (Aug 28 2025 - 12:07:43 +0530)

SoC:   AM62X SR1.0 HS-SE
Model: Texas Instruments AM625 SK
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed -1
DRAM:  2 GiB
Core:  72 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed -1
Net:   Could not get PHY for ethernet@8000000port@1: addr 0
am65_cpsw_nuss_port ethernet@8000000port@1: phy_connect() failed
No ethernet found.

Hit any key to stop autoboot:  0 
=> 
=> setenv dfu_alt_info ${dfu_alt_info_emmc}
=> dfu 0 mmc 0
generic_phy_get_bulk : no phys property

我看不到这些命令。 您只是运行 DFU 命令。

Hit any key to stop autoboot:  0 
=> mw 0x43000030 0x3b 0x1;reset;
resetting ...
02000000011a0000616d3632780000000000000048535345010001000100010002a6000001000200d68ecb2c055dff11ade95bd927e837d2a53bc23b0a2800cebce4f106bcf309df2213912d77a157a8b7c2df40672a06a918034aa4c7d603e462481475225d49b81f6002b07cd9b0b7c47d9ca8d1aae57b8e8784a12f636b2b760d7d98a18f189760dfd0f23e2b0cb10ec7edc7c6edac3d9bdfefe0eddc3fff7fe9ad875195527d74b24aed316cea6820016d5ff184fbcf2fedcff26f288a6108d9c320a0e784a0CCCCCCCCCCCC

您好：

将引导加载程序组件刷写到 eMMC 后出现引导故障。

已将电路板引导至 USB DFU 模式并使用刷写到 RAM 中

sudo dfu-util -R -a bootloader -D tiboot3-am62x-hs-evm.bin
sudo dfu-util -R -a tispl.bin -D tispl.bin
sudo dfu-util -R -a u-boot.img -D u-boot.img

2. 在 U-Boot 提示符处停止并执行：

setenv dfu_alt_info ${dfu_alt_info_emmc}
dfu 0 mmc 0

然后、使用以下命令刷写到 eMMC：

sudo dfu-util -a tiboot3.bin.raw -D tiboot3-am62x-hs-evm.bin
sudo dfu-util -a tispl.bin.raw -D tispl.bin
sudo dfu-util -a u-boot.img.raw -D u-boot.img

在 U-Boot 中、我配置了 eMMC 引导设置：

mmc partconf 0 1 1 1
mmc bootbus 0 2 0 0

然后、关闭电路板的电源、将引导模式开关更改为 eMMC 引导、然后重新接通电源。

 问题：

重新启动后、我始终收到以下错误：

U-Boot SPL 2023.04 (Aug 28 2025 - 11:48:42 +0530)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

您好：
我们生成了  单独的 tiboot3.bin 以从 DFU 和 eMMC 引导
已在 USB DFU 模式下引导电路板并使用以下命令刷写到 RAM：
sudo dfu-util -R -a bootloader -D tiboot3-am62x-hs-evm.bin
sudo dfu-util -R -a tispl.bin -D tispl.bin
sudo dfu-util -R -a u-boot.img -D u-boot.img

在 U-Boot 提示符处停止并执行：
setenv dfu_alt_info $｛dfu_alt_info_eMMC｝
DFU 0 MMC 0

Couldn't find part #1 on mmc device #0
DFU entities configuration failed!
(partition table does not match dfu_alt_info?)
dfu - Device Firmware Upgrade

Usage:
dfu <USB_controller> [<interface> <dev>] [list]
  - device firmware upgrade via <USB_controller>
    on device <dev>, attached to interface
    <interface>
    [list] - list available alt settings

2.  在 U-Boot 提示符处停止并执行：

在您最后的第二个回答中、它起了作用、但现在不起作用。 所以,你必须改变某种东西。 您记得做些什么吗？

请共享以下命令的输出

=> printenv dfu_alt_info_emmc
=> mmc dev 0
=> mmc part

您好：

=> printenv dfu_alt_info_emmc
dfu_alt_info_emmc=rawemmc raw 0 0x800000 mmcpart 1; rootfs part 0 1; tiboot3.bin.raw raw 0x0 0x400 mmcpart 1; tispl.bin.raw raw 0x400 0x1000 mmcpart 1; u-boot.img.raw raw 0x1400 0x2000 mmcpart 1; u-env.raw raw 0x3400 0x100 mmcpart 1; sysfw.itb.raw raw 0x3600 0x800 mmcpart 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc part
## Unknown partition table type 0

您好：

已成功创建 eMMC 分区。

我在刷写 rootfs 时遇到问题。

MMC 部件显示分区 1 存在且为~15 GB。

• 它是一个自定义生成的 ext4 映像,

• 大小约为 8.6GB

Isuue：

尝试通过 DFU 刷写 rootfs 映像时收到以下错误：

dfu-util: File size is too big: Success

但是、在 DFU 刷写期间我遇到错误：

“dfu-util"工具“工具不归 TI 所有。 这是一个开源工具、因此有关该工具的任何问题都应在其特定论坛上讨论。 我只能建议尝试刷写较小大小的 rootfs、只是看看“dfu-util"是否“是否仅针对较大的文件大小失败。

您好：
ext4 文件系统刷写问题已解决 — ext4 现在已正确刷写。 但是、 修复后 、设备将成功引导一次、然后再次重新引导。 2-3 次自动重新引导后、终端输出在引导过程中中途挂起、系统无响应。