This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TDA4VEN-Q1:J722S EVM 上的 OSPI 擦除引起的问题

Guru**** 2874030 points

Other Parts Discussed in Thread: UNIFLASH

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1638598/tda4ven-q1-issue-caused-by-ospi-erase-on-the-j722s-evm

器件型号: TDA4VEN-Q1
Thread 中讨论的其他器件: UNIFLASH

在执行 OSPI 初始化后、我们在 J722S EVM 上遇到问题。

  • 我们从 U-Boot 中初始化(擦除/编程)OSPI 闪存。
  • 然后、我们将之前使用过的图像写入 OSPI、没有任何问题。
  • 执行此操作后、OSPI 引导不再工作:
    • 从 OSPI 引导时、U-Boot 不会启动。
    • 从 SBL 执行的 R5F 软件也不会运行。
    • 在 UART 上未观察到输出、而日志以前可见。

在此 OSPI 初始化之前、相同的 OSPI 引导设置 (SBL→R5F/U-Boot) 正常工作。

此时、我们无法确定故障的任何明确原因。
我们想确认此问题是否与从 U-Boot 执行的 OSPI 初始化或擦除操作有关、或者在 J722S EVM 上重新初始化 OSPI 时是否存在任何已知的预防措施或所需的步骤。

任何指导或调试建议都将不胜感激。

使用 U-Boot 的 OSPI 初始化过程

使用以下 U-Boot 命令初始化 OSPI 闪存:

=> sf probe
=> sf erase 0 0x4000000

 

OSPI 编程程序和内容

中对 OSPI 闪存进行了编程 UART 引导模式
使用从主机 PC 执行编程 uart_uniflash.py

.cfg用于编程的配置文件 () 的内容如下所示。

--flash-writer=/home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage

# Program the OSPI PHY tuning attack vector
--operation=flash-phy-tuning-data

# Now send one or more files to flash or flashverify as needed. The order of sending files does not matter
# Hsm binary
#--file=/home/kozai/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hsm_bin/hsm-demo-firmware-j722s-hs-fs.bin --operation=flash --flash-offset=0x80000

# MulticoreApp
#--file=/home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/linux.appimage.hs_fs --operation=flash --flash-offset=0xC0000

# Flash U-Boot.img
#--file=/home/kozai/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hlos_prebuilt/j722s-evm/linux/u-boot.img --operation=flash --flash-offset=0x280000

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
--file=/home/kozai/cms_proj/sbl_ospi_hlos/j722s-evm/wkup-r5fss0-0_nortos/ti-arm-clang/sbl_ospi_hlos.release.hs_fs.tiimage --operation=flash --flash-offset=0x0

此致、

Toshiki

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Toshiki-san、

    您是否可以使用 SD 卡引导至 U-Boot 提示符并尝试使用 U-Boot 刷写引导加载程序?

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j722s/11_01_00_03/exports/docs/linux/Foundational_Components /U-Boot/UG-QSPI.html

    => SF 探针 
    => mmc dev 0 1
    => fatload mmc 1 ${loadaddr}tiboot3.bin => sf update $loadaddr 0x0 $filesize => fatload mmc 1 ${loadaddr}tispl.bin => sf update $loadaddr 0x80000 $filesize => fatload mmc 1 ${loadaddr}u-boot.img => sf update $loadaddr 0x280000 $filesize

    这是使用 U-Boot 将引导二进制文件刷写到 OSPI 的一种方法。

    - Keerthy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keerthy:

    我们能够使用 U-Boot 从 SD 卡将引导二进制文件刷写到 OSPI。
    但是、这并不能解决根本的问题。

    我们的目标是使用 sbl_ospi_hlos.release.hs_fs.tiimage 从 OSPI 进行引导、然后:

    • 在 A53 内核上执行 U-Boot、以及
    • 在 R5F 内核上执行 appimage 中包含的应用程序。
    此致、
    Toshiki
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keerthy:

    我已确定原因。 由于 linux.appimage.hs_fs 的大小为 2.2MB 、因此它溢出到 U-Boot 偏移地址 0x280000。 当我使用较小的 AppImage 时、系统引导没有任何问题。

    为了防止这种溢出、我想将 u-boot.img 的偏移地址更改为 0x310000。 但是、这也需要修改在 sbl_ospi_hlos.release.hs_fs.tiimage 中配置的 U-Boot 放置(加载)地址。

    也就是说、该 SBL 直接来自
    /ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/sbl_prebuilt/j722s-evm/
    我不确定如何重建它。

    您能解释一下如何修改加载地址并重新编译 SBL 吗?

    此致、

    Toshiki

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好:  

    您能分享一下存储器映射吗?  

    二进制及其 ospi 偏移?  

    此致、  

    Keerthy  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keerthy:

    以下是 OSPI 存储器映射。

    ・SBL
    sbl_ospi_hlos.release.hs_fs.tiimage:flash-offset=0x0

    ・HSM
    HSM-demo-Firmware-j722s-hs-FS.bin:flash-offset=0x80000

    ・MulticoreApp
    linux.appimage.hs_fs:flash-offset=0xC0000

    ・U-boot
    u-boot.img:flash-offset=0x280000→  0x310000

    此致、

    Toshiki

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Toshiki、

    我们将尽快回复您。

    感谢您耐心等待。

    此致、

    Vinit

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Toshiki、

    如中所示、生成的 Linux 应用映像的代码库已经包含 U-Boot、如果是这种情况、可能会从 Linux 组合的应用映像加载 U-Boot 映像。

    但根据.cfg、Linux 应用映像首先被刷新、然后再刷新 u-boot、这可能会破坏 Linux 应用映像、从而导致这种异常行为。

    您制作了带有 r5f 核心 appimage 的 Linux appimage、对吧?

    我 只想省略 u-boot 映像刷写一次、然后再试一次。

    如果这样有效、那么我们就不必修改 SBL 映像。

    请告诉我会发生什么情况。

    此致、

    Vinit

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Vinit:

    appimage 仅包含 U‑Boot SPL、不包含主 U‑Boot 映像、因此需要单独对 u‑boot.img 进行编程。

    即使省略了 u‑boot.img、U‑Boot 也无法启动。

    此致、

    Toshiki

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Toshiki、

    首先,由于块对齐,我们不能使用 0x3100 ,我们会使用 0x340000。

    我们不需要更改 SBL、因为 SBL 只知道加载多核映像。

    多核映像包含 u-boot spl、该 spl 知道要从哪个闪存偏移量加载 u-boot。

    因此、我们需要更改 u-boot spl、然后再使用该命令生成 Linux 应用程序映像。

    步骤 1:  转到 /board-support/ti-u-boot-2025.01 + git/configs/j722s_evm_a53_defconfig、并更改下面的行

    发件人:

    CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
    收件人:
    CONFIG_SYS_SPI_U_BOOT_OFFS=0x340000
    步骤 2:  转到 并运行$make u-boot
    会生成一些文件、我们需要  u-boot-spl.bin 文件、这个文件位于 board-support/ti-u-boot-2025.01+git/build/a53/spl/u-boot-spl.bin
    第 3 步:  将该  u-boot-spl.bin 复制到目录中 /mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hlos_prebuilt/j722s-evm/linux、并将其重命名为 u-boot-spl-j722s-evm.bin
    步骤 4:  从目录运行以下命令  /mcu_plus_sdk_j722s_11_01_00_15/tools/boot/linuxAppimageGen
    $ make BOARD=j722s-evm Clean
    $ make BOARD=j722s-evm
    它将 在生成 linux.appimage.hs_fs 文件 /mcu_plus_sdk_j722s_11_01_00_15/tools/boot/linuxAppimageGen/board/j722s-evm/linux.appimage.hs_fs
    步骤 5:  现在、使用 u boot 映像偏移量为 0x340000 更新配置文件。
    步骤 6:  擦除闪存 、然后 使用新的配置文件刷写 OSPI。
    这将解决该问题。
    如果您遇到任何问题、请告知我们。
    此致、
    Vinit