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.

[参考译文] CCS:如果通过 Uboot 从 PDK MLO 启动、则 Linux 启动失败

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/943175/ccs-linux-boot-fail-if-start-from-pdk-mlo-througth-uboot

工具/软件:Code Composer Studio

各位专家、您好!

  我们有一个(另一个)小问题、现在是关于 SMP、我们的 SOC 架构是 K2H14。

为了(一起)执行 DSP 和 ARM 的引导、我们的客户端希望使用 MLO (TI PDK 中的内容)。
所使用的 PDK 包含在 ti-processor-sdk-rtos-k2hk-evm-05.02.00.10-Linux-x86-Install.bin 中

我发现 out2rprc.exe 有一个小问题,然后使用了 opensource 工具 elf2rprc
进行了一些校正、以便能够启动 ARM 和 DSP 应用。

我已经为我们的定制板配置了 uboot u-boot-2019.01 (数据包内容进入)
TI-processor-sdk-linux-k2hk evm-06.01.000.08-linux-x86-64安装.bin)。

现在、如果我配置 u-boot、使其在 SMP 模式下的所有 ARM 内核上运行 SPL Linux (作为客户端请求)。

如您在此处所见:

U-Boot SPL 2019.01-svn10 (2020年9月22日- 20:32:37 +0200)
尝试从 SPI 引导


U-Boot 2019.01-svn10 (2020年9月22日- 20:32:37 +0200)

CPU:66AK2Hx SR3.1 (XXX)
型号:XXXXXXXX XXXX 板(uBoot)
DRAM: DDR3A 内存组[XXXX-K2H-2G1600SED]
DDR3速度1600
DRAM:2 GiB (包括以下报告)
2GiB
(小部分
重定位偏移为:f3f46000
重新定位到 fff46000、fdf05ed8处的新 gd、fdf05eb0处的 sp
(小部分
未找到 USB DR_MODE
与非:  
找到设备、制造商 ID:0x2C、芯片 ID:0xb3
Micron MT29F8G16ADBDAH4
1024 MIB
正在从 SPI 闪存加载环境... SPI_FLASH_std_probe:slave=fdf0bb98、cs=0
SF:检测到的 mt25qu256a、页大小为256字节、擦除大小为4 KiB、总共32 MIB
好的
Turn _Off_All_DSP#34:被称为禁用 DSP
net:  eth0:netcp@2000000、eth1:netcp@slave-1、eth2:netcp@slave-2、eth3:netcp@slave-3

净如果 Nr:4
按任意键停止自动引导:1 0
=>运行 ubiUpgrade

Netcp@2000000等待 SGMII 自动协商完成。 完成
使用 netcp@2000000器件
来自服务器192.168.111.150的 TFTP;我们的 IP 地址为192.168.111.11
文件名"/tftpboot/XXXXX_RootFS.ubi。
加载地址:0x8000000
正在加载:############################################################################
        ####################################################
 …
        ####################################################
        ####################################################
        ####
        4.5 MIB/s
完成
传输的字节= 132513792 (7e60000十六进制)

NAND 擦除.part:器件0偏移量0x0、大小0xc800000
在0xc7e0000处擦除-- 100%完成。
好的

NAND 写入:器件0偏移量0x0、大小0x7e60000
 132513792字节被写入:好的

=>运行 bootcmd1 bootcmd2 bootcmd3 bootcmd4
ubi0:连接 mtd1
ubi0:扫描完成
ubi0:卷0 ("rootfs")将大小从1009调整为1436 LEB
ubi0:附加的 mtd1 (名称"ubifs2"、大小为200 mib)
ubi0:PEB 大小:131072字节(128 KiB)、LEB 大小:126976字节
ubi0:最小值/最大值 I/O 单元大小:2048/248、子页大小2048
ubi0:VID 标头偏移:2048 (对齐2048)、数据偏移:4096
ubi0:良好的 PEB:1600、不良 PEB:0、损坏的 PEB:0
ubi0:用户卷:1,内部卷:1,最大 卷数:128
ubi0:最大/平均擦除计数器:1/0、WL 阈值:4096、图像序列号:260444989
ubi0:可用 PEB:0、总保留 PEB:1600、为不良 PEB 处理保留的 PEB:160

       7392 Mon A04 06 14:50:46 2020 bin
        160 Mon Apr4 06 14:50:46 2020 开发
       6648 星期二05年5月16:12:48 2020 年等
       7296 Tue May 19 16:59:35 2020 lib
        232 监控06年4月14:50:46 2020 年安装
        2014年 4月24日星期一06年14:50:46 2020 年可选
        160 Mon APR 06 14:50:47 2020 Run
        224 Mon APR 06 14:50:47 2020 srv
        160 Mon Apr 06 14:50:47 2020 tmp
        160 Mon APR 06 14:50:47 2020 系统
        808 Mon APR 06 14:50:49 2020 var
        752 Mon Apr 06 14:50:48 2020 USR
        488 星期二9月22日19:35:06 2020 年启动
        224 Mon Jun 01 13:01:10 2020 主页
          2020 年4月20日星期一06月14:50:49初始化
        160 Mon Apr 06 14:50:47 2020 proc.
       7744 Mon A04 06 14:50:47 2020 sbin
        160 Mon Apr 06 14:50:46 2020 介质

Netcp@2000000等待 SGMII 自动协商完成。 完成
使用 netcp@2000000器件
来自服务器192.168.111.150的 TFTP;我们的 IP 地址为192.168.111.11
文件名"/tftpboot/XXXXX_multi.itb。
加载地址:0x90000000
正在加载:############################################################################
        ####################################################
        ####################################################
        ####################################################
        ##############################
        4.5 MIB/s
完成
传输的字节= 4310332 (41c53c 十六进制)
##正在从起始图像中复制'firmware-1'子图像,地址为90000000...
MD5+ SHA1+   正在加载第15部分... 好的
调试:来自安全模式的消息2:核心频率- 203450520Hz

K2_BM_15。 07 nogit soc:k2hk 内置:20:07:43、2020年9月10日

##已安装显示器@ 0xc5f0000、freq [203450520]、状态207552512
##正在将"FDT-2"子映像从90000000处的 FIT 映像复制...
CRC32+   正在加载部件253... 好的
##正在从起始图像中复制'kernel-1'子图像,地址为90000000...
MD5+ SHA1+   正在加载部件0... 好的
##正在从90000000处的 FIT 图像加载内核...
  使用'config-1'配置
  正在尝试'kernel-1'内核子映像
    说明: xxxx 内核
    创建时间     :2020-09-22 19:35:05 UTC
    键入:        kernel Image
    压缩: 未压缩
    数据开始:  0x900a1298
    数据大小:   3564032字节= 3.4 mib
    架构:ARM
    操作系统:          Linux
    载入地址:0x80000000
    入口点: 0x8000000
    散列算法:   MD5
    哈希值:  c1254a24db7ddb1584c950d6a1a23907
    散列算法:   SHA1
    散列值:  10983e72e01c411757da5e1c233c7fe1336b2e6a
  正在验证散列完整性... MD5+ SHA1+正常
###展开的设备树状图、位于81fe0000
  使用0x81fe0000处的 FDT blob 进行引导
  正在加载内核映像... 好的
  正在将设备树加载到8fff2000,结束位置8ff5f3... 好的

正在启动内核...

调试:>>> skern_powerON_CPU (1)>>>

调试:来自安全模式的消息2:核心频率- 203450520Hz

调试:>>> skern_powerON_CPU (2)>>>

调试:来自安全模式的消息2:核心频率- 203450520Hz

调试:>>> skern_powerON_CPU (3)>>>

调试:来自安全模式的消息2:核心频率- 203450520Hz

[0.000000]   在物理 CPU 0x0上引导 Linux
[0.000000]   Linux 版本4.14.79-gbde58ab01e (xxxxx@pdaeth)(gcc 版本7.2.1 20171011 (Linaro GCC 7.2-2017.11))#153 SMP 优先于 Tue Sep 22 21:31:41 CEST 2020
[0.000000]   CPU:ARMv7处理器[412fc0f4]修订版4 (ARMv7)、CR=30c5387d
[0.000000]   CPU:可用的 div 指令:修补分部代码
[0.000000]   CPU:PIPT/VIPT 非混叠数据高速缓存、PIPT 指令高速缓存
[0.0000M]   、共页:FDT:机器型号:XXXXXX 板(Linux)
[0.000000]   内存策略:数据高速缓存 writealloc
[0.000000]   将物理地址空间切换为0x8000000
[0.000000]   EFI:从 FDT 获取 EFI 参数:
[0.000000]   EFI:未找到 UEFI。
[0.000000]   保留内存:创建了0x000000081f800000的 CMA 内存池,大小为8 MIB
[   0.000000]、共模:保留内存:已初始化节点 DSP-公共内存@81f800000、兼容 ID 共享 dma-pool
[0.000000]   CMA:保留0x000000087e400000处的24 MIB
[0.000000]   psci:从 DT 探测导管方法。
[0.000000]   psci:使用 DT 中的 PSCI v0.1函数 ID
[0.000000]   perpu:嵌入式16页/CPU @de593000 s35468 r8192 d21876 u65536
[0.000000]   在上构建了1个区域列表、移动分组。  总页数:455040
[0.000000]   内核命令行:console=ttyS0、115200n8 {mtdparts} rootwait=1 root=/dev/zero rw initrd=-、8M rootdelay=4 rootfstype=ubifs root=ub0:ubfs flags=sync rw ubi.MTD=rootifs2、2048
[0.000000]   PID 哈希表条目:2048 (顺序:1、8192字节)
[0.000000]   条目高速缓存散列表条目:65536 (顺序:6、262144字节)
[0.000000]   inode 高速缓存散列表条目:32768 (顺序:5、131072字节)
[0.000000]   内存:1760228K/1824768K 可用(8192K 内核代码、226K rwdata、2412K rodata、2048K init、263K BSS、 31772K 保留、32768K CMA 保留、1275904K HIGHMEM)
[0.000000]   虚拟内核内存布局:
[0.000000]       矢量 :0xff0000-0xff1000  (4KB)   
[0.000000]       fixmap :0xc00000 - 0xc00000  (3072 KB)
[0.000000]       vmalloc:0xe0800000 - 0x0x800000  (496MB)
[0.000000]       低内存 :0xC0000000 - 0xe0000000  (512 MB)
[0.000000]       pkmap  :bbfe00000 - 0xC0000000  (  2 MB)
[0.000000]       模块:bbf000000 - bbbfe00000  ( 14 MB)
[0.000000]         .text:0xc0008000 - 0xc0a00000  (10208 KB)
[0.000000]         .init:0xc0e00000 - 0xc1000000  (2048KB)
[0.000000]         .data:0xc1000000 - 0xc1038b00  (227KB)
[0.000000]          .bss:0xc103a000 - 0xc107be28  (264 KB)
[0.000000]   slub:HWalign=64、order=0-3、MinObjects=0、CPU=4、Nodes=1
[0.000000]   可抢占的分层 RCU 实现。
[0.000000]    RCU 将 CPU 从 NR_CPU=8限制为 nr_CPU_IDs=4。
[0.000000]    启用了 RCU 任务。
[0.000000]   RCU:调整 RCU_FANOUT_LEVEE=16的几何结构,nr_CPU_IDs=4
[0.000000]   NR_IRQ:16、nr_IRQ:16、预分配 IRQ:16
[0.000000]   GIC:使用分离 EOI/Deactivate 模式

相反、如果我在没有 SPL 的情况下配置相同的 U-Boot 并使用 PDK MLO:

Board_init@115:正常

**** PDK SBL ****
SBL 修订版本:01.00.09.02 (2020年9月23日- 17:33:22)
1.8
PSC_GET_DOMAIN_num:模块编号0x00000006域编号0x00000001
开始解析用户应用程序
设置 spiParams.bitrate = 80000
尝试打开闪存0x0000bb19

NOR_spiReadId mofID 内部:0x00000020 DevID:0x0000bb19
NOR_open 确定
norInfo->deviceId:47897
norInfo->manufacturerId:32.
norInfo->blockCnt: 512
norInfo->pageCnt: 256
norInfo->pagesize:256
norInfo->busWidth:8.

打开 OK
SBL_MulticoreImageParse@71:被调用

SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc000000
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc0003c0
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc04f9b8
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc06ae40
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc06ae60
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc073d00
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc07acf4
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc07ad00
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc089048
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc07c298
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc089078
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc08907c
正在跳转到用户应用程序...


U-Boot 2019.01-svn10 (2020年9月23日- 13:54:30 +0200)

CPU:66AK2Hx SR3.1 (XXX)
型号:xxxxxxx XXXXXX 板(uBoot)
DRAM: DDR3A 内存组[XXXX-K2H-2G1600SED]
DDR3速度1600
DRAM:2 GiB (包括以下报告)
2GiB
(小部分
重定位偏移为:f3f46000
重新定位到 fff46000、fdf05ed8处的新 gd、fdf05eb0处的 sp
(小部分
未找到 USB DR_MODE
与非:  
找到设备、制造商 ID:0x2C、芯片 ID:0xb3
Micron MT29F8G16ADBDAH4
1024 MIB
正在从 SPI 闪存加载环境... SPI_FLASH_std_probe:slave=fdf0bb98、cs=0
SF:检测到的 mt25qu256a、页大小为256字节、擦除大小为4 KiB、总共32 MIB
好的
Turn _Off_All_DSP#34:被称为禁用 DSP
net:  eth0:netcp@2000000、eth1:netcp@slave-1、eth2:netcp@slave-2、eth3:netcp@slave-3

净如果 Nr:4
按任意键停止自动引导:1 0

=>运行 bootcmd1 bootcmd2 bootcmd3 bootcmd4
ubi0:连接 mtd1
ubi0:扫描完成
ubi0:附加的 mtd1 (名称"ubifs2"、大小为200 mib)
ubi0:PEB 大小:131072字节(128 KiB)、LEB 大小:126976字节
ubi0:最小值/最大值 I/O 单元大小:2048/248、子页大小2048
ubi0:VID 标头偏移:2048 (对齐2048)、数据偏移:4096
ubi0:良好的 PEB:1600、不良 PEB:0、损坏的 PEB:0
ubi0:用户卷:1,内部卷:1,最大 卷数:128
ubi0:最大/平均擦除计数器:2/0、WL 阈值:4096、图像序列号:260444989
ubi0:可用 PEB:0、总保留 PEB:1600、为不良 PEB 处理保留的 PEB:160

       7392 Mon A04 06 14:50:46 2020 bin
        160 Mon Apr4 06 14:50:46 2020 开发
       6928 2018年12月16日04:29:50 等
       7296 Tue May 19 16:59:35 2020 lib
        232 监控06年4月14:50:46 2020 年安装
        2014年 4月24日星期一06年14:50:46 2020 年可选
        160 Mon APR 06 14:50:47 2020 Run
        224 Mon APR 06 14:50:47 2020 srv
        160 Mon Apr 06 14:50:47 2020 tmp
        160 Mon APR 06 14:50:47 2020 系统
        880 Sun 2018年12月16日04:29:50 var
        752 Mon Apr 06 14:50:48 2020 USR
        488 星期二9月22日19:35:06 2020 年启动
        224 Mon Jun 01 13:01:10 2020 主页
          2020 年4月20日星期一06月14:50:49初始化
        160 Mon Apr 06 14:50:47 2020 proc.
       7744 Mon A04 06 14:50:47 2020 sbin
        224 Sun 2018年12月16日04:29:49 介质
               0 Sun 2018年12月16日04:31:05 forcefsck

Netcp@2000000等待 SGMII 自动协商完成。 完成
使用 netcp@2000000器件
来自服务器192.168.111.150的 TFTP;我们的 IP 地址为192.168.111.11
文件名"/tftpboot/XXXXXXX_multi.itb。
加载地址:0x90000000
正在加载:############################################################################
        ####################################################
        ####################################################
        ########################################
        623 KiB/s
完成
传输的字节= 3683489 (3834a1十六进制)
##正在从起始图像中复制'firmware-1'子图像,地址为90000000...
MD5+ SHA1+   正在加载第15部分... 好的
调试:来自安全模式的消息2:核心频率- 203450520Hz

K2_BM_15。 07 nogit soc:k2hk 内置:20:07:43、2020年9月10日

##已安装显示器@ 0xc5f0000、freq [203450520]、状态207552512
##正在将"FDT-2"子映像从90000000处的 FIT 映像复制...
CRC32+   正在加载部件253... 好的
##正在从起始图像中复制'kernel-1'子图像,地址为90000000...
MD5+ SHA1+   正在加载部件0... 好的
##正在从90000000处的 FIT 图像加载内核...
  使用'config-1'配置
  正在尝试'kernel-1'内核子映像
    说明: xxxx 内核
    创建时间     :2020-09-23 12:05:56 UTC
    键入:        kernel Image
    压缩: 未压缩
    数据开始:  0x90008230
    数据大小:   3564032字节= 3.4 mib
    架构:ARM
    操作系统:          Linux
    载入地址:0x80000000
    入口点: 0x8000000
    散列算法:   MD5
    哈希值:  c1254a24db7ddb1584c950d6a1a23907
    散列算法:   SHA1
    散列值:  10983e 72e01c411757da5e1c233c7fe1336b2e6a
  正在验证散列完整性... MD5+ SHA1+正常
###展开的设备树状图、位于81fe0000
  使用0x81fe0000处的 FDT blob 进行引导
  正在加载内核映像... 好的
  正在将设备树加载到8fff2000,结束位置8ff5f3... 好的

正在启动内核...  <<<在此处保持停止(未激活 ARM 1-3)

如果我使用 VxWorks 应用程序(这是一个客户端请求、但我想是这样
以下是其他需要解决的问题):

Board_init@115:正常

**** PDK SBL ****
SBL 修订版本:01.00.09.02 (2020年9月23日- 17:33:22)
1.8
PSC_GET_DOMAIN_num:模块编号0x00000006域编号0x00000001
开始解析用户应用程序
设置 spiParams.bitrate = 80000
尝试打开闪存0x0000bb19

NOR_spiReadId mofID 内部:0x00000020 DevID:0x0000bb19
NOR_open 确定
norInfo->deviceId:47897
norInfo->manufacturerId:32.
norInfo->blockCnt: 512
norInfo->pageCnt: 256
norInfo->pagesize:256
norInfo->busWidth:8.

打开 OK
SBL_MulticoreImageParse@71:被调用

SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc000000
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc0003c0
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc04f9b8
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc06ae40
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc06ae60
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc073d00
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc07acf4
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc07ad00
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc089048
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc07c298
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc089078
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc08907c
正在跳转到用户应用程序...


U-Boot 2019.01-svn10 (2020年9月23日- 13:54:30 +0200)

CPU:66AK2Hx SR3.1 (XXXX)
型号:xxxxxxxxx 电路板(uBoot)
DRAM: DDR3A 内存组[XXXX-K2H-2G1600SED]
DDR3速度1600
DRAM:2 GiB (包括以下报告)
2GiB
(小部分
重定位偏移为:f3f46000
重新定位到 fff46000、fdf05ed8处的新 gd、fdf05eb0处的 sp
(小部分
未找到 USB DR_MODE
与非:  
找到设备、制造商 ID:0x2C、芯片 ID:0xb3
Micron MT29F8G16ADBDAH4
1024 MIB
正在从 SPI 闪存加载环境... SPI_FLASH_std_probe:slave=fdf0bb98、cs=0
SF:检测到的 mt25qu256a、页大小为256字节、擦除大小为4 KiB、总共32 MIB
好的
Turn _Off_All_DSP#34:被称为禁用 DSP
net:  eth0:netcp@2000000、eth1:netcp@slave-1、eth2:netcp@slave-2、eth3:netcp@slave-3

净如果 Nr:4
按任意键停止自动引导:1 0

=>运行 BOOT_VX

Netcp@2000000等待 SGMII 自动协商完成。 完成
使用 netcp@2000000器件
来自服务器192.168.111.150的 TFTP;我们的 IP 地址为192.168.111.11
文件名"/tftpboot/XXXX/uVxWorks。
加载地址:0x82000000
正在加载:############################################################################
        ####################################################
        ####################################################
        ####################################################
        ####################################################
        ####################################################
        ####################################################
        ########
        3.2 MIB/s
完成
传输的字节= 6768524 (67478c 十六进制)

Netcp@2000000等待 SGMII 自动协商完成。 完成
使用 netcp@2000000器件
来自服务器192.168.111.150的 TFTP;我们的 IP 地址为192.168.111.11
文件名"/tftpboot/xxxx/k2hk_xxxx.dtb。
加载地址:0x88000000
正在加载:#
        1.7 MIB/s
完成
传输的字节= 7003 (1b5b 十六进制)
##从 Legacy Image 中引导内核,地址为82000000...
  图像名称:  VxWorks
  创建时间     :202020-09-08 14:09:17 UTC
  图像类型:  ARM VxWorks 内核图像(未压缩)
  数据大小:   6768460字节= 6.5 MIB
  载入地址:80100000
  入口点: 80100000
  正在验证校验和... 好的
###展开的设备树 blob、88000000
  使用0x88000000处的 FDT blob 进行引导
  正在加载内核映像... 好的
  正在将设备树加载到8fffb000,结束8fffb5a... 好的
##正在从0x80100000开始 VxWorks,设备树位于0x8fffb000...
初始化 CPU
启动 CPU
初始化 MMU
初始化基本虚拟内存支持
初始化虚拟内存支持模块
初始化地址空间库
初始化全局映射
初始化 VxBus
       安装总线类型:
               vxbMiBus (MII 总线类型)
               vxbFdtBus (平展器件树总线类型)
               vxbNexusBus (Nexus 总线类型)
       安装驱动程序:
               armgic (ARM GIC FDT 驱动器)
               armGenTimer (ARM 通用定时器)
               netcp (处于开关模式的 TI KeyStone Netcp 终端驱动器)
               KeyStone 固定时钟(TI KeyStone 固定速率时钟 FDT 驱动器)
               KeyStone 主 PLL 时钟(TI KeyStone 主 PLL 时钟 FDT 驱动器)
               KeyStone-PLL-divder-clock (TI KeyStone PLL 分频器时钟 FDT 驱动器)
               KeyStone 固定因数时钟(TI KeyStone 固定因数时钟 FDT 驱动器)
               KeyStone 电源模块时钟(TI KeyStone 电源模块时钟 FDT 驱动器)
               ksTimer (TI KeyStone 64位计时器)
               genericPhy (通用10/100/1000 PHY 驱动器)
               fdtBus (FDT 总线控制器)
               simpleBus (简单总线控制器)
               ns16550 (ns16550串行驱动程序)
               mainbus (通用根 Nexus 驱动程序)
       探测和连接设备
------------------ AFI_DEBUG_20200908 vxbLibInit()启动
               探头主总线
               连接主总线:0
               探测器 fdtBus
               连接 fdtBus:0
               探头 SoC
               连接 simpleBus:0
               探头参考系统
               连接 KeyStone-fix-clock:0
               探头维护
               连接 KeyStone 主 PLL 时钟:0
               探头维护1
               连接 keystone-pll-divder-clock:0
               探针内部 div_6
               连接 KeyStone-fix-facter-clock:0
               探测器 sharedlocaldiv_6
               连接梯形固定因子时钟:1
               探测器中断控制器
               附加臂架:0
               探头时间器0
               附加 k计时 器:0
               探测定时器1
               附加 k计时 器:1
               探头架2.
               附加 k计时 器:2
               探头通用计时器
               连接 armGenTimer:0
               探头 i2c
               探测 i2c 失败
               探针串行0
               连接 ns16550:0
               探针 GPIO
               无法探测 GPIO
               探头 edma0
               无法探测 edma0
               探头 edma1.
               无法探测 edma1
               探头 edma2.
               无法探测 edma2
               探头 EDMA3
               探测 EDMA3失败
               探头 edma4.
               无法探测 edma4
               探测器 netcp_ethernet_SW
               连接 netcp:0
               探测 netcp_ethernet_ip
               无法探测 netcp_ethernet_ip
               探测 CPU
               探测 CPU 失败
               探测虚拟总线
               探测 virtBus 失败
------------------ AFI_DEBUG_20200908 vxbLibInit()正常
------------------ AFI_DEBUG_20200908 cpcInit()启动
------------------ AFI_DEBUG_20200908 cpcInit() vxIpiConnect =确定
------------------ AFI_DEBUG_20200908 cpcInit() vxIpiEnable (0)=确定
------------------ AFI_DEBUG_20200908 vxdbgCpuLibInit() start     <<< VxWorks 在此处停止

如果使用 TI 引导监视器 VxWorks 提早停止:


##从 Legacy Image 中引导内核,地址为82000000...
  图像名称:  VxWorks
  创建时间     :202020-09-08 14:09:17 UTC
  图像类型:  ARM VxWorks 内核图像(未压缩)
  数据大小:   6768460字节= 6.5 MIB
  载入地址:80100000
  入口点: 80100000
  正在验证校验和... 好的
###展开的设备树 blob、88000000
  使用0x88000000处的 FDT blob 进行引导
  正在加载内核映像... 好的
  正在将设备树加载到8fffb000,结束8fffb5a... 好的
##正在从0x80100000开始 VxWorks,设备树位于0x8fffb000...  <<< VxWorks 在此停止。

我假设 Linux 不能激活从机臂并保持等待阶段。
问题是 MLO 中缺少哪个代码来激活该内核?

PS:U-Boot 仅在 ARM Core0上启动。

现在、此 MLO 能够启动单独的 U-Boot、几个 DSP (core0&1)或 U-Boot+DSP

Board_init@115:正常

**** PDK SBL ****
SBL 修订版本:01.00.09.02 (2020年9月23日- 16:31:56)
1.8
开始解析用户应用程序
设置 spiParams.bitrate = 80000
尝试打开闪存0x0000bb19

NOR_spiReadId mofID 内部:0x00000020 DevID:0x0000bb19
NOR_open 确定
norInfo->deviceId:47897
norInfo->manufacturerId:32.
norInfo->blockCnt: 512
norInfo->pageCnt: 256
norInfo->pagesize:256
norInfo->busWidth:8.

打开 OK
SBL_MulticoreImageParse@71:被调用

SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x8003a0
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc0f4200
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc224458
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc1fae40
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc223d00
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x800200
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x80031c
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x80033c
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x800500
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x830000
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x834200
SBL_RprcImageParse@366:DSP0 L2SRAM DestAddr 0x800000
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc211b80
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc1a6060
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x8003a0
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc0f4200
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc224458
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc1fae40
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc223d00
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x800200
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x80031c
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x80033c
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x800500
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x830000
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x834200
SBL_RprcImageParse@366:DSP1 L2SRAM DestAddr 0x800000
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc211b80
SBL_RprcImageParse@353:MSMCSRAM DestAddr 0xc1a6060
正在跳转到用户应用程序...
无机械臂应用除颤完成...
不可
xxxx 测试软件版本0.0.1内部版本42 CPU 频率983 MHz DSP 的 Core0内核8.
DSP 硬件修订版0 DSP 名称"TMS320C66AK2H14"电路板名称 XXXXX"构建日期2020年9月23日16:28:00

您是否有解决此问题的建议?

此致、
Dario

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

    您好、Dario、

    这是一个很长的日志。 我需要缓慢地浏览它们。 我将在浏览您的日志后返回给您。

    雷克斯

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

    您好 Rex。

     没问题。

    我在 Linux 中的 uboot 跳转之前以及 Linux 中的第一个函数处添加了一些打印输出。
    似乎没有启动 Linux:

    ###展开的设备树状图、位于81fe0000
      使用0x81fe0000处的 FDT blob 进行引导
      正在加载内核映像... 好的
    flush_dcache_range@183:结束
    do_bootm_linux@416:called
    do_bootm_linux@423:0.0
      正在将设备树加载到8fff2000,结束位置8ff5f3... 好的
    do_bootm_Linux@425:0.1
    do_bootm_linux@416:called
    do_bootm_linux@430:1.0
    ##正在将控制权转移到 Linux (地址8000000处)...

    正在启动内核...

    clean_Before_Linux@84:调用
    clean_Before_linux_select@28:called
    DCache_disable@360:被调用
    v7_OUTER_SACK_DISABLE@229:被调用
    validate_dcache_all@171:结束
    ICache@disable 339:被调用
    cache_disable@288:被调用
    cache_disable@308:结束
    ICache@disable 341:结束
    validate_ICache_all@203:调用
    validate_ICache@218:结束
    CPU_Cache_initialization@24:called
    Announce_and_clean_113@:调用
    BOOT_JUTER_Linux@400:1  <<<在此处保持停止

    最新的打印输出为:

    静态空 boot_jum_linux (bootm_headers_t *映像、int 标志)



       如果(!fake){
    #ifdef CONFIG_ARMV7_NONSEC
          if (armv7_boot_nonsec ()){
             armv7_init_nonsec();
             SECURE_RAM_addr (_do_nonsec_entry)(kernel_entry、
                          0、machid、R2);
          }否则
    #endif
             printk ("%s@%d:1 \n"、__func__、__line__);<<<< 一个示例
             kernel_entry (0、machid、R2);<<<此处运行 Linux (我认为)
       }
    #endif
       printk ("%s@%d:end \n"、__func__、__line__);


    在 uboot 中、我在 cache_v7.c、cpu.c 和 cache-cp15.c 等中的每个函数中添加了一个打印输出
    在 Linux 中、我在 setup.c 和 main.c 中的每个函数中添加了一个打印输出

    如果改为使用 SPL:

    ###展开的设备树状图、位于81fe0000
      使用0x81fe0000处的 FDT blob 进行引导
      正在加载内核映像... 好的
    flush_dcache_range@183:结束
    do_bootm_linux@416:called
    do_bootm_linux@423:0.0
      正在将设备树加载到8fff2000,结束位置8ff5f3... 好的
    do_bootm_Linux@425:0.1
    do_bootm_linux@416:called
    do_bootm_linux@430:1.0
    ##正在将控制权转移到 Linux (地址8000000处)...

    正在启动内核...

    clean_Before_Linux@84:调用
    clean_Before_linux_select@28:called
    DCache_disable@360:被调用
    v7_OUTER_SACK_DISABLE@229:被调用
    validate_dcache_all@171:结束
    ICache@disable 339:被调用
    cache_disable@288:被调用
    cache_disable@308:结束
    ICache@disable 341:结束
    validate_ICache_all@203:调用
    validate_ICache@218:结束
    CPU_Cache_initialization@24:called
    Announce_and_clean_113@:调用
    BOOT_JUK_Linux@400:1
    调试:>>> skern_powerON_CPU (1)>>>

    调试:来自安全模式的消息2:核心频率- 203450520Hz

    调试:>>> skern_powerON_CPU (2)>>>

    调试:来自安全模式的消息2:核心频率- 203450520Hz

    调试:>>> skern_powerON_CPU (3)>>>

    调试:来自安全模式的消息2:核心频率- 203450520Hz
    [0.000000]   start_kernel@553:called
    [0.000000]   SMP_setup_processor_id@611:called
    [0.000000]   在物理 CPU 0x0上引导 Linux
    [0.000000]   Linux 版本4.14.79-gbde58ab01e (inddaia@pdaeth)(gcc 版本7.2.1 20171011 (Linaro GCC 7.2-2017.11))#157 SMP 优先于 Thu Sep 24 01:35:19 CEST 2020
    [0.000000]   setup_arch@1110:被调用
    [0.000000]   setup_processor@699:called
    [   0.000000 ]__get_cpu_architecture@248:called
    [0.000000]   cpu_architecture@280:called
    [0.000000]   CPU:ARMv7处理器[412fc0f4]修订版4 (ARMv7)、CR=30c5387d

    似乎没有调用引导监视器、也没有应答(循环)或无法激活 ARM 内核。

    此致、
    Dario

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

    您好!

     小更新。


    SBL_SLAVE.c 中、我看到了以下宏:

    /* ARM 条目的 RBL 地址*/
    #define ARM_魔术_ADDRESS  0x0C5AD000
    /* ARM 子内核条目的 SBL 地址*/
    #define SBL_ARM_魔术      0x0C0FFF00

    K2H 的地址是否正确?

    该地址没有描述(我没有找到它们)、无论如何我已经移入0x0C0C0000
    MLO、位于0x0C000000中、具有 uboot、位于0x0C5F0000、引导监视器、位于0xC0F0000
    放置了我的 DSP 应用。
    MSMCSRAM 中的其他地址用于 DSP 共享 DSP&ARM 的 DSP 数据。

    此致、
    Dario


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

    您好、Dario、

    在引导日志中、我看到您已"运行 ubiUpgrade "将映像刻录到 NAND。 该映像稍后是否也用于引导 DSP 的情形?  我不熟悉.ITB 的使用情况,并假设它是内核(?)的设备树 blob。 那么、内核不使用文件系统/boot 中的 dtb 文件?  

    在加载 DSP 应用的引导日志中、与不加载 DSP 的引导日志相比、存在一些差异。  首先加载 MLO,内核引导日志不会显示“卷0 (rootfs)重新调整大小从1009到1436 LEBs”。  我不确定它是否重要、或许应该加以考虑。 另外,如果某些目录在 NAND 中使用相同的文件系统,为什么两次引导之间的大小不同? 两次引导之间的.ITB 文件大小也不同,它们应该是什么? 在日志中、数据起始地址也不同。 这些可能需要了解、以查看它们是否有任何影响。

    我不擅长引导 DSP 映像或 DSP 操作。 我需要与同事一起查看他是否有任何意见。

    雷克斯

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

    您好 Rex。

    ********* 更新信息*****

    NAND FS 在 Linux 中使用、没有 DSP 使用、UBoot DTB 存储在 U-Boot 中。

    在 ITB 文件中,我有一个 uboot 副本(用于板载 uboot 升级)、引导监视器和内核
    和几个 DT (一个用于 EVM 环境、现在未使用、另一个用于定制
    主板)中,现在我没有存储 inetrd 文件(在以前使用过它)。

    在 Linux 内核中、我还插入了 netcp 和 xnetcp TI FW 驱动程序、用于3310的神奇10 FW 驱动程序
    其他 FWs。

    NAND FS  Arago-base-tisdk-image-k2hk evm.tar.xz 是解压缩和
    使用我的 Linux 驱动程序和一些其他脚本进行自定义、以配置所有 eth 接口
    其他东西。

    秘书长的报告 问题:「

    用于激活附加 ARM 的引导监视器回调是从 uboot 还是从 Linux?

    我已经看到 uboot 在几秒钟后将控制权交给 Linux 之前打印了最新的打印输出
    (4~5)(工作时)我可以看到 ARM 激活打印、那么我猜是 Linux 发送的
    消息(或 IRQ、我不知道)。 我认为打印会在模芯激活后显示、而不是
    当不起作用时、尝试(或计数器)无限循环。

    uboot 中的 SPL 具有正确的功能/程序以使臂能够工作的其他可能性
    该函数在 MLO 中未定义(或未很好地完成)。

    PS:但汇编程序对我来说有点不方便。


    出于测试目的、昨天我使用 uboot 命令对 mon_power、if 进行了一些测试
    引导监视器未加载电源开/关块 uboot (现在使用 SPL 加载 uboot):

    => mon_power
    MON_POWER -打开/关闭辅助内核

    用法:
    MON_POWER MON_POWER
    - CoreID (1-3)和操作器(1 -打开、0 -关闭)

    => mon_power 1 0
    MON_POWER_OFF@56:被调用  <<此处被阻止

    该行为与 MLO 方案相同。
    如果加载了监护仪:

    =>运行 bootcmd1 bootcmd2 bootcmd3
    ubi0:连接 mtd1
    ubi0:扫描完成
    ubi0:附加的 mtd1 (名称"ubifs2"、大小为200 mib)
    ubi0:PEB 大小:131072字节(128 KiB)、LEB 大小:126976字节
    ubi0:最小值/最大值 I/O 单元大小:2048/248、子页大小2048
    ubi0:VID 标头偏移:2048 (对齐2048)、数据偏移:4096
    ubi0:良好的 PEB:1600、不良 PEB:0、损坏的 PEB:0
    ubi0:用户卷:1,内部卷:1,最大 卷数:128
    ubi0:最大/平均擦除计数器:2/0、WL 阈值:4096、图像序列号:2093418666
    ubi0:可用 PEB:0、总保留 PEB:1600、为不良 PEB 处理保留的 PEB:160


    Netcp@2000000等待 SGMII 自动协商完成。 完成
    使用 netcp@2000000器件
    来自服务器192.168.111.150的 TFTP;我们的 IP 地址为192.168.111.23
    文件名"/tftpboot/DRSP/DRSP_multi.itb。
    加载地址:0x90000000
    正在加载:############################################################################
            ####################################################
            ####################################################
            ####################################################
            ##############################
            51.8 KiB/s
    完成
    传输的字节= 4312788 (41ced4十六进制)
    ##正在从起始图像中复制'firmware-1'子图像,地址为90000000...
    MD5+ SHA1+   正在加载第15部分... 好的
    flush_dcache_range@183:结束
    MON_INSTALL@18:被调用
    调试:来自安全模式的消息2:核心频率- 203450520Hz

    K2_BM_15。 07 nogit soc:k2hk 内置:20:07:43、2020年9月10日

    ##已安装显示器@ 0xc5f0000、freq [203450520]、状态207552512
    ##正在将"FDT-2"子映像从90000000处的 FIT 映像复制...
    CRC32+   正在加载部件253... 好的
    flush_dcache_range@183:结束
    ##正在从起始图像中复制'kernel-1'子图像,地址为90000000...
    MD5+ SHA1+   正在加载部件0... 好的
    flush_dcache_range@183:结束
    => mon_power 1 0
    MON_POWER_OFF@56:被调用
    调试:>>> skern_poweroff_CPU (1)>>>

    内核1已成功断电

    => mon_power 1 1
    MON_POWER_ON@37:被调用
    调试:>>> skern_powerON_CPU (1)>>>

    内核1已成功通电
    =>调试:来自安全模式的消息2:内核频率- 203450520Hz


    脚本 bootcmd1 bootcmd2 bootcmd3下载 ITB 文件并解压缩
    所有模块、并加载引导监视器。
    我记得、昨天我曾尝试启动 Linux (在 MLO/U-Boot 之后)
    我还加载了 boot-monitor (我不记得是否使用了 mon_power
    命令)。



    秘书长的报告 答案****

    我不使用 NAND 中的/boot 目录(现在)、当系统稳定时、我可以使用它
    (为避免继续 NAND 下载),无论如何,rootfs 都是在以后加载的。

    multi.itb (-600kB)的大小差异 是由于从 ITB 上卸下 uboot (请小心)造成的
    升级 uboot.gph 在 MLO 方案中不可用)。

    VxWorks 从我的 Linux 内核的 DDR3A (0x80100000)中的不同地址开始
    0x8000000、但在 MLO/SPL 中地址相同(我对您的问题进行了充分解释?)。

    定制板中的 NAND 是 EVM 中的 NAND (1GB)的两倍、我想我有
    mtdpart 中的参数出错(我将很快检查、谢谢)。


    感谢您的支持。


    此致、
    Dario

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

    您好、Dario、

    很抱歉、回答很慢。 我需要我的同事来看看这一点。 在 Linux 启动之前、他可能对 MLO 启动 DSP 有一些见解。

    雷克斯

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

    尊敬的 Rex:

       再次感谢你。

    此致、
    Dario

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

    尊敬的 Rex:

      您对此问题有什么新闻吗?

    此致
    Dario

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

    您好、Dario、

    我没有听到同事的反馈。 我会再次对他执行 Ping 操作。

    雷克斯

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

    尊敬的 Rex:

       今天我做了另一项测试。 我已将 Linux 配置为在单个内核上运行、并且 MLO 能够启动它。 然后、我假设问题与 AD SMP 模式相关(激活辅助内核)。

    感谢您的支持。

    Dario

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

    您好、Dario、

    是否可以执行 SMP 模式引导并在进行或不进行 MLO 下载的情况下附加完整的引导日志? 我返回到您的日志、但没有一个日志足够长、无法查看我在下面显示的有关辅助内核的任何消息。 请将日志作为文件附加、这样更易于阅读、而不会影响帖子的发布。 谢谢!

    [0.001098] CPU:测试写入缓冲区一致性:好
    [0.001125] CPU0:幽灵 v2:固件未设置辅助控制寄存器 IBE 位、系统容易受到攻击
    [0.001330]/cpus/cpu@0缺少时钟频率属性
    [0.001356]/cpus/cpu@1缺少时钟频率属性
    [0.001382]/cpus/cpu@2缺少时钟频率属性
    [0.001408]/cpus/cpu@3缺少时钟频率属性
    [0.001417] CPU0:线程-1、CPU 0、套接字0、mpidr 8000000
    [0.039983]为0x80200000 - 0x80200138设置静态标识映射
    [0.059987]分层 SRCU 实现。
    [0.080148] EFI 服务将不可用。
    [0.100035] SMP:启动辅助 CPU ...
    [0.175032] CPU1:线程-1、CPU 1、套接字0、mpidr 8000000001
    [0.175039] CPU1:幽灵 v2:固件未设置辅助控制寄存器 IBE 位、系统容易受到攻击
    [0.245132] CPU2:线程-1、CPU 2、插座0、mpidr 800002
    [0.245139] CPU2:幽灵 v2:固件未设置辅助控制寄存器 IBE 位、系统容易受到攻击
    [0.315225] CPU3:线程-1、CPU 3、插座0、mpidr 800003.
    [0.315231] CPU3:幽灵 v2:固件未设置辅助控制寄存器 IBE 位、系统容易受到攻击
    [0.315364] SMP:带来1个节点、4个 CPU
    [0.315374] SMP:总共激活4个处理器(1600.00 BogoMips)。
    [0.315381] CPU:所有 CPU 均在 HYP 模式下启动。
    [0.315388] CPU:提供虚拟化扩展。
    [0.315850] devtmpfs:已初始化
    [0.32181] random:从 buck_table_alloc+0x104/0x22c 调用 get_random_u32、crng_init=0

    雷克斯

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

    尊敬的 Rex:

       感谢您的帮助、为解决这一大问题(为我们)、我已经做了一个解决方法。

    SCI 接口不工作、在 VxWorks 或 u-boot 中不处理 RPC、VxWorks 从开始
    仅 UBoot… 问题太多、无法快速解决。

    我在 uboot 中从 MLO 移植了一些函数、并添加了一个新命令来解析 RPRC
    然后复制 DSP/MSMC 存储器中的存储器部分、之后我重新进行了复位
    已选择的 DSP。

    我看到的唯一问题是 DSP 从断电状态上电时的问题、实际上我不得不这样做
    已禁用 DSP 断电功能(替换为存根)、现在 Uboot 中的 DSP 引导为
    从微控制器或操作系统命令重新启动后获得。

    为此、我导入了一些.h 文件(来自 PDK)。 如果您需要我的文件、您可以问我。

    PS:有关 PSC 的 TI 文档很糟糕、在 K2H 数据表中、PSC 只有一个相关文档、但
          对于 Keystone I、uboot 会触摸保留的一些位(在文档中)、并且寄存器名称不同。

    例如:
    int psc_disable_domain (u32 domain_num)

       u32 pdctl;
       u32 ptcmd;
                    //在使用前不进行状态检查(2.3.3中的步骤1)
       pdctl =__raW_readl (KS2_PSC_BASE + PSC_REG_PDCTL (domain_num));
       pdctl = PSC_REG_PDCTL_SET_NEXT (pdctl、PSC_REG_VAL_PDCTL_NEW_OFF);//位0 PDCTL (下一个字段)
       pdctl = PSC_REG_PDCTL_SET_PDMODE (pdctl、PSC_REG_VAL_PDCTL_PDMODE_SLEEP);//位12和13 PDCTL (保留)
       _raW_writel (pdctl、KS2_PSC_BASE + PSC_REG_PDCTL (domain_num));

       ptcmd =__raW_readl (KS2_PSC_BASE + PSC_REG_PTCMD);
       ptcmd |=(u32)(1 << domain_num);  // GO[x]位
       _raW_writel (ptcmd、KS2_PSC_BASE + PSC_REG_PTCMD);

       返回 PSC_WAIT (domain_num);

    您是否有任何更新的与 K2S 相关的 PSC 文档? (我已查阅 sprugv4c.pdf 9/2014)

    此致、
    Dario

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

    您好、Dario、

    PSC 用户指南适用于 KS-1和 KS-2、没有任何更新版本的 PSC UG、但看到代码设置位12-15很有趣。 让我在内部检查它所基于的内容。

    雷克斯

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

    您好、Dario、

    我们找不到任何描述这些保留位的文档。 我们仅使用下一位。 即使在 RTOS GEL 文件中、它也只使用位0。

    雷克斯

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

    尊敬的 Rex:

     好的、位在 K2H 中可能无效、但对于其他 TI 架构而言。

    在此文档中、我没有看到 DPS 需要的其他步骤(在执行断电之前将其置位)。


    无论如何,现在都是值得的。

    谢谢你。

    此致、
    Dario