[参考译文] AM62P：SK-AM62P-LP：MCU + SDK：SPL：无法从所有引导设备引导

您好：

请告知我们您正在使用的 OSPI NOR 闪存器件。

此致、

Vaibhav

Vaibhav Kumar  

[引用 userid=“531612" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1591165/am62p-sk-am62p-lp-mcu-sdk-spl-failed-to-boot-from-all-boot-devices/6130401

请告知我们您正在使用的 OSPI NOR 闪存器件。

[/报价]

OSPI NOR 闪存器件：  

存储器–OSPI  | OSPI0 | S28HS512TGABHM010  

“

2.16.2 OSPI 接口 AM62P SK EVM 电路板具有一个 Cypress 512Mb OSPI 存储器器件（器件型号为 S28HS512TGABHM010）。该器件连接到 AM62P SoC 的 OSPI0 接口。 该 OSPI 存储器支持单倍和双倍数据速率、存储器速度高达 200MBps SDR 和 400MBps DDR（（200MHz 时钟速度）

“

您好、

几个检查清单可供您检查：

1. 请确保您使用的是正确的 SYSFW。
2. 确保您的 uboot SPL 专为 SK-AM62P-LP 构建。
3. 检查 DTS 以了解 OSPI 和闪存状态。 这应设置为状态=“正常“。
4. padconfig 值/焊球编号应与 SK-AM62P-LP 型号匹配。 我在这里讨论了 pinmux 配置。

此致、

Vaibhav

您好、

请确保使用的是正确的 SYSFW。

>>是的。

确保您的 uboot SPL 专为 SK-AM62P-LP 而构建。

>>是的

检查 DTS 以了解 OSPI 和闪存状态。 这应设置为状态=“Okay"。“。

>>是、其 状态=“正常“；

[引用 userid=“531612" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1591165/am62p-sk-am62p-lp-mcu-sdk-spl-failed-to-boot-from-all-boot-devices/6130526

1. padconfig 值/焊球编号应与 SK-AM62P-LP 型号匹配。 我在这里讨论了 pinmux 配置。

[/报价]

>>是的。

我有时只遇到此错误。

出现此错误：5/20

使用 SDK 版本：  

mcu_plus_sdk_am62px_10_01_00_33 和  ti-processor-sdk-linux-am62pxx-evm-10.01.10.04

您好 Shanooj：

您能给我讲一讲引导流程结构的外观吗？

使用什么引导加载程序进行引导。 是 SBL OSPI Linux Multistage 吗？

此致、

Vaibhav

您好、

假设您正在使用类似的文件（如 default_sbl_ospi_linux_hs_fs_splash_screen.cfg） 、则第二阶段引导加载程序是 DSS 共享。

请在第二阶段引导加载程序中放置一个 while 循环/永远循环、并查看故障/卡住的确切位置。 如果没有被卡住的东西、那么我们需要看看行为是如何的。 确保 MCU+ SDK 示例中的 OSPI 区域按严格顺序配置。 基本上是 0x60000000 区域、直至 128MB 应严格排序。

期待调试的结果。 使用本指南了解如何在应用中始终以正确的方式使用循环： software-dl.ti.com/.../DEVELOP_AND_DEBUG_DMR5.html

此致、

Vaibhav

[引用 userid=“531612" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1591165/am62p-sk-am62p-lp-mcu-sdk-spl-failed-to-boot-from-all-boot-devices/6134063

假设您正在使用类似的文件（如 default_sbl_ospi_linux_hs_fs_splash_screen.cfg） 、则第二阶段引导加载程序是 DSS 共享。

[/报价]

是的、没错。

请在第二阶段引导加载程序中放置一个 while 循环/永久循环、并查看确切的故障/卡住的位置

已尝试此操作、未观察到故障、因此我添加了延迟  

void main_thread(void *args) {
  int32_t status = SystemP_SUCCESS;

  /* Open drivers */
  Drivers_open();
  /* Open flash and board drivers */
  status = Board_driversOpen();
  DebugP_assert(status == SystemP_SUCCESS);

  /* Init LPM specific data */
  Sciclient_initDeviceManagerLPMData(&gDMLPMData);

  sciServer_init();

  const TickType_t xDelay =
      pdMS_TO_TICKS(100);
  vTaskDelay(xDelay);
  
  dss_display_share_main(NULL);

到目前为止、还没有发现任何故障。

您好 Shanooj：

添加延迟后、根本没有观察到故障。 感谢您的更新。 但我们需要消除此延迟、因为我想这是您在第二阶段引导加载程序中不需要的内容。

我们首先了解一下您设置中的 UART 配置。 请告诉我在第一阶段引导加载程序中使用哪个 UART？

第二阶段引导加载程序呢、在本例中使用什么？  

另外、请告诉我 UART 的模式、例如轮询模式或中断模式。

期待您的答复。

此致、

Vaibhav

我假设这是您在第二阶段引导加载程序中不需要的内容正确吗？

是、不需要。  

以下是用于刷写的配置 AM

# First point to sbl_uart_uniflash_stage1 binary, which initialises DDR and receives sbl_uart_uniflash_stage2 binary
--flash-writer=sbl_prebuilt/am62px-sk/sbl_uart_uniflash_stage1.release.hs_fs.tiimage

# Points to sbl_uart_uniflash_stage2 binary, which function's as a server to flash one or more files
# Please note this binary is copied to DDR by sbl_uart_uniflash_stage1 and not written to any boot media like flash or eMMC
--file=../../examples/drivers/boot/sbl_uart_uniflash_multistage/sbl_uart_uniflash_stage2/am62px-sk/wkup-r5fss0-0_nortos/ti-arm-clang/sbl_uart_uniflash_stage2.release.appimage.hs_fs --operation=flash --flash-offset=0x0

# 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

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
--file=sbl_prebuilt/am62px-sk/sbl_ospi_linux_stage1.release.hs_fs.tiimage --operation=flash --flash-offset=0x0

# 2nd stage bootloader with DM is flashed at 0x80000 or to whatever offset your bootloader is configured for
--file=../../examples/drivers/dss/dss_display_share/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/dss_display_share_am62px-sk_wkup-r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs --operation=flash --flash-offset=0x80000

#--file=../../examples/drivers/mcan/mcan_loopback_interrupt/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/mcan_loopback_interrupt_am62px-sk_wkup-r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs --operation=flash #--flash-offset=0x80000

# When sending application image, make sure to flash at offset 0x100000 (default) or to whatever offset your bootloader is configured for
--file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/mcu-r5fss0-0_freertos/ti-arm-clang/ipc_rpmsg_echo_linux.release.appimage.hs_fs --operation=flash --flash-offset=0x800000

# HSM image is flashed at 0x800000 or to whatever offset your bootloader is configured for
--file=HSMAppimageGen/board/am62px-sk/hsm.appimage.hs_fs --operation=flash --flash-offset=0x240000

# Linux image is flashed at 0xC00000 or to whatever offset your bootloader is configured for
--file=linuxAppimageGen/board/am62px-sk/linux.appimage.hs_fs --operation=flash --flash-offset=0x1200000

# u-boot.img is flashed at 0x280000
--file=linuxAppimageGen/board/am62px-sk/u-boot.img --operation=flash --flash-offset=0x280000

以下是用于刷写的配置 AM

我知道您使用的配置、想知道您/您的团队是否更改了应用程序 SBL OSPI Linux Stage 1 和 DSS Display Share 中的 UART 配置？ 请帮助回答以下问题。

[引用 userid=“531612" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1591165/am62p-sk-am62p-lp-mcu-sdk-spl-failed-to-boot-from-all-boot-devices/6134948

我们首先了解一下您设置中的 UART 配置。 请告诉我在第一阶段引导加载程序中使用哪个 UART？

第二阶段引导加载程序呢、在本例中使用什么？  

另外、请告诉我 UART 的模式、例如轮询模式或中断模式。

[/报价]

期待您的答复。

此致、

Vaibhav

我想知道您/您的团队是否更改了应用程序 SBL OSPI Linux Stage 1 和 DSS Display Share 中的 UART 配置？

我已将 DSS Telltales 应用程序的示例代码修改为我自己的代码。

[引用 userid=“531612" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1591165/am62p-sk-am62p-lp-mcu-sdk-spl-failed-to-boot-from-all-boot-devices/6143253

我们首先了解一下您设置中的 UART 配置。 请告诉我在第一阶段引导加载程序中使用哪个 UART？

第二阶段引导加载程序呢、在本例中使用什么？  

另外、请告诉我 UART 的模式、例如轮询模式或中断模式。

[/报价]

syscfg 的 PFA 屏幕截图。

UART 处于轮询模式。

我希望这就是您的要求。 如果您需要更多数据、请告诉我。