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

您好 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很有趣。 让我在内部检查它所基于的内容。

雷克斯