[参考译文] J784S4XEVM：从另一个 SoC 通过 PCIe 引导 Jacinto 7

尊敬的 KR：

由于今天是美国假期、请预计回复会延迟1-2天。

此致、

Josiitaa.

尊敬的 Cedric：

硬件支持 PCIe 引导、但 J784S4/J7x 器件不支持 PCIe 引导的软件。

此致、

Takuma

你好、Takuma、

关于如何开始、是否有任何线索？ 我的意思是、我想我们需要配置 bar、然后将其写入以启动引导、但我不知道我需要写入哪个文件(也许是 tiboot3.bin？)。

谢谢

你好、Ajins、

感谢您的参与。 负责处理此线程的 Takuma 今天正在旅行、必须能够在周一查看。

谢谢。

尊敬的 Cedric：

这要求写入 U-Boot 中的 PCIe 驱动程序和/或写入 SBL 引导流程的 PCIe 驱动程序。 TDA4VH/J784S4的 PCIe 驱动程序仅适用于 Linux、因此 PCIe 引导功能将变得很难实现。

建议使用 eMMC 等板载存储器来引导电路板、然后通过 Linux 启动 PCIe 链路、而不是通过 PCIe 引导。

此致、

Takuma

你好、Takuma、

我们不一定要从 U-Boot 开始进入 PCIe、我们可以从 Linux 开始。 我们需要实现的是验证该机制、以确保 Jacinto 可以在 PCIe 中正确启动。

首先、我们不明白为什么有6个存储器区域、它们的用途是什么？

此外、以下 J784S4 AM69A TRM：

在根复合体侧枚举后显示的存储器区域与文档中提到的相应端点存储器位置之间的映射是什么？

是否有任何与之相关的文档？

如果我们要对地址位置0x41CF3FE0 (如上所述)进行写入、我们应该对根复合体侧的地址进行写入？

KR、

Cedric

尊敬的 Cedric：

让我澄清一下、即使 是非 U-boot、我们很遗憾也不支持 J784S4的 PCIe 引导。 ROM 能够从 PCIe 中读取、但它只会通过 PCIe 读取初始引导加载程序 tiboot3.bin。 但是、tiboot3.bin 不会从 PCIe 获取其他引导二进制文件、因此引导将停止。

因此、我 建议您从不同的引导介质引导 J784S4 EP、以将其设置为 EP、然后您可以从  TMDS64EVM 等 RC 访问 J784S4 EP。

此致、

Takuma

你好、Takuma、

我正在与 Cedric 合作、我 想跟进您之前的 回答。 我们确实需要从 PCIe 引导、而不是从其他引导介质引导。 因此、理解它的工作原理对我们来说非常重要。

我们理解您的意思、从软件的角度来看、需要最初通过 PCIe 传输的二进制 tiboot3.bin 不处理通过 PCIe 继续执行引导过程。 这确实需要修改代码以处理 PCIe 并继续引导阶段。

不过、我们想了解如何传输 tiboot3.bin。

如果我 参考 C é dric 已经提供给您的部分屏幕截图：

当我们查看 该捕获图时、我们清楚地观察到6个区域的 大小为256,512、1K、16K、128K、 1M 已被端点请求。

您能明确告诉我们更多有关这6个区域在 Jacinto SoC 端的映射的信息吗？ 这些区域是映射到共享存储器还是其他任何地方？  您能否在 Jacinto 映射中向我们提供映射的地址以便能够传输 tiboot3.bin 文件？

感谢您的帮助。

此致、

Kiêt μ A

您好、 Kiêt

Unknown 说：

您能否明确告诉我们有关 soc 侧这6个区域的映射情况？

长话短说、这会映射到 Linux devicetre 中定义为 CMA 的某个连续存储器区域。

有关详细的响应...

我 想这是 EP 中默认的 Linux/RC 示例、这意味着 EP 正在运行此处的 PCI-EPF-TEST.c 驱动程序： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pci/endpoint/functions/pci-epf-test.c?h=ti-linux-6.6.y。这定义了一些大小增加的任意条形尺寸、以演示可以分配不同大小的事实。

如果遵循代码、那么最终会调用 dma_alloc_相干 来分配内存： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pci/endpoint/pci-epf-core.c?h=ti-linux-6.6.y#n285 

dma_alloc_相干 从连续 CMA 存储器池分配存储器、以允许 DMA 顺畅使用。

[报价 userid="405847" url="~/support/processors-group/processors/f/processors-forum/1463846/j784s4xevm-booting-jacinto-7-through-pcie-from-another-soc /5670568#5670568"]

不过、我们想了解如何传输 tiboot3.bin。

[报价]

对于这个问题、我刚才解释的是没有用的。 这是因为只有在运行 PCI-EPF-TEST Linux 驱动程序时、才会在每个 PCIe 函数下创建6个条形图。 此外、由于在运行 Linux、U-Boot 或任何其他引导加载程序之前需要 tiboot3.bin、因此在需要 tiboot3.bin 时不会运行 PCI-EPF-TEST。

尽管我知道您需要 PCIe 引导、但我仍然不建议使用 PCIe 引导。 它将极大地增加系统的复杂性。

为了解释完整 PCIe 引导的复杂性、引导流程如下所示：

1. ROM 代码初始化 PCIe 并等待 tiboot3.bin
2. tiboot3.bin 初始化 PCIe 并等待 tispl.bin
3. tispl.bin 初始化 PCIe 并等待 uboot.img
4. uBoot.img 用于初始化 PCIe 并等待 Linux 内核和 devicetree
5. Linux 内核初始化 PCIe 并从 PCIe 安装文件系统

我们没有步骤2、3和4、因此您必须为3个不同的代码库开发 PCIe 驱动程序。 除此之外、每个驱动程序都需要平稳地将 PCIe 硬件控制权交给引导的下一步、RC 必须在每个阶段重新枚举 EP、并在每个阶段同步从 RC 到 EP 的二进制发送。

相反、如果您执行 SDK 中支持的 eMMC 或 OSPI 引导( 仅在 Linux 中初始化 PCIe)、引导流程将为：

1. ROM 从 eMMC 或 OSPI 读取 tiboot3.bin、其中会读取 tispl.bin、然后是 uboot.img、Linux 内核、devicetre、 和文件系统。
2. Linux 初始化 PCIe 以进行 PCIe 传输。

对于 eMMC 或 OSPI 引导、 SDK 中支持所有步骤。 引导时间会明显快于 PCIe 引导。 最后、您仍然有 PCIe 来传输数据。

此致、

Takuma

你好、Takuma、

感谢您的答复。 事实上,我很抱歉,我走得太快了 C é dric 所写的内容。 屏幕截图实际上位于两个 Linux 系统之间。

C é dric 再次测试并提供了一张来自端点的屏幕截图、其中显示了条形分配。

它看起来更好,并显示两条(两条的大小都是32 MB )。

我重复关于这些新映射的区域的同一个问题：您能在 Jacinto 映射中为我们提供映射的地址、以便传输 tiboot3.bin 文件吗？ 我应该在哪里写入 tiboot3.bin 文件？ 在 BAR0或 BAR1、以及在偏移0或其他地址处？

在端点本地、2个映射区域的地址是什么？

我们正在设计定制电路板、需要通过 PCIe 将一个 SoC 连接到另一个 SoC。 我们无法对第二个 SoC 使用 eMMC 或 QSPI。

我看到了您所描述的步骤。 但是、一旦 tiboot3.bin 被传输并引导、我认为我们可以按照以下步骤操作：

1. ROM 代码初始化 PCIe 并等待 tiboot3.bin。
2. tiboot3.bin 初始化 PCIe 并等待 tispl.bin (在 MSM 中？)。
3. tispl.bin 初始化 PCIe 和 LPDDR4并等待 uboot.img、设备树、Linux 内核和 RAM rootfs (在 LPDDR4中)。

提前感谢您。

此致、

Kiêt μ A

您好、 Kiêt

这是一个警告、指出 这是其他人不走的道路。 我担心你会走这条路,遇到障碍,我们将无法帮助你。   在加载 tiboot3.bin 的步骤1之后、TI 实际上不支持通过 PCIe 实现引导。

另一方面、 我建议的替代解决方案的客户已选择使用此 eMMC/OSPI 引导路径来实现主要使用 PCIe 进行相互通信的双 SoC 解决方案。 因此、这是一种已知有效的设计。 我知道您需要 PCIe 引导(可能以更低的 BOM 成本)、但请注意、对于 通过 PCIe 连接两个 SoC 的定制电路板、有其他的引导解决方案。

现在、记住警告、回到您的问题...

总共有4个酒吧、应该再有两个酒吧、如下所示：

01:00.0 Non-VGA unclassified device: Texas Instruments Device b010
        Flags: fast devsel, IRQ 536
        Memory at 68100000 (32-bit, non-prefetchable) [virtual] [size=1M]
        Memory at 68200000 (32-bit, prefetchable) [virtual] [size=2M]
        Memory at 6a000000 (64-bit, prefetchable) [virtual] [size=32M]
        Memory at 6c000000 (64-bit, prefetchable) [virtual] [size=32M]
        Capabilities: [80] Power Management version 3
        Capabilities: [90] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [b0] MSI-X: Enable- Count=1 Masked-
        Capabilities: [c0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [150] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [160] Power Budgeting <?>
        Capabilities: [180] Resizable BAR <?>
        Capabilities: [1b8] Latency Tolerance Reporting
        Capabilities: [1c0] Dynamic Power Allocation <?>
        Capabilities: [300] Secondary PCI Express
        Capabilities: [400] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [440] Process Address Space ID (PASID)
        Capabilities: [4c0] Virtual Channel
        Capabilities: [900] L1 PM Substates
        Capabilities: [a20] Precision Time Measurement
        Kernel driver in use: pci-endpoint-test
        Kernel modules: pci_endpoint_test

您使用的 PC 可能需要 sudo 权限才能查看额外的两个条形图。  

在我的日志中、0x68200000是 BAR1、它映射到0x41C00000。 TRM 应具有应写入起始地址位置和写入魔术字位置的寄存器、以指示传输完成。

此致、

Takuma

你好、Takuma、

是的、我明白您不支持它、无法为引导流程的后续步骤提供帮助。 我们有一些原因需要从 PCIe 而非闪存启动、并且这与 BOM 成本无关。 其中之一是电路板上安装新闪存的空间、因为我们正在设计复杂的电路板。

我不知道为什么我们没有看到1 MB 的条形图。 我们会检查一下、必要时稍后回来与您联系。

实际上、我们在 TRM 中已经看到了在 tiboot3传输后继续引导所需的信息。

感谢您的支持。

此致、

Kiêt μ A

您好、 Kiêt

在您的努力中祝您好运！

此致、

Takuma