问题描述
我正在调整 u-boot 以支持 Cyclone V SX PCIe + NVMe。我通过一系列 hack 让它在 2020.10 版 socfpga fork 中工作。
-
u-boot 似乎不理解 PCI 地址空间和主机地址空间不一定相同，当 nvme 获取分配给 PCIe 端口的地址时，PCI 驱动程序假定地址读取映射直接进入主存。它没有。它完全映射到另一个地址。我有一个黑客来处理这个问题。我将尝试向 u-boot 中的设备树实用程序添加一项功能，以便在不破坏现有功能的情况下进行地址转换。
-
在 NVMe 执行命令后，nvme 驱动程序处理清除和无效缓存以获取对内存的更改的方式存在重大问题。门铃寄存器在轮询时需要在呼出时清除，在呼入时无效，也就是说，在各种方面几乎完全错误。
这里是我需要指导的地方。
u-boot 中有两位代码来处理缓存清除/失效。一个是arm v7核心代码的一部分，另一个是pl310控制器代码。 arm v7 代码认为缓存行是 64 字节，pl310 代码认为缓存行是 32 字节。哇？
这两个代码都被 nvme 代码使用。我认为clear通过pl310，invalidate通过arm v7，但此时我可能会倒退，我仍在学习并且可以很容易地将它们混淆。
nvme 驱动程序的问题很简单：它要求清除未与缓存对齐的地址范围，并且两个代码都阻塞并执行错误的操作，最终不会清除或使需要清除的缓存无效并作废。在 pl310 的情况下，它对起始地址进行四舍五入并且不执行任何操作，而在 arm v7 代码的情况下，如果在将它们对齐到 64 字节边界后开始和停止是相同的，则代码执行什么都没有。
我通过在 nvme 代码中强制对齐到 64 字节并确保它通过在停止中添加一个来清除缓存来解决这个问题，如果它与 arm v7 调用中的 start 相同。
如果你还在关注我。谢谢，我真的很感激。
解决这个问题的正确方法是什么。这些代码都不是我的。在我看来，缓存代码中存在错误。 pl310 不应该在起始地址上加 1，也许应该将它加到停止地址，这取决于 for 循环的编写方式。用于使 arm v7 代码无效的 for 循环应至少运行一次，以确保它清除起始位置。所以无效循环应该是
如果有人感兴趣，我可以发布此代码，请告诉我。
但最大的问题是：为什么有两种方法可以清除/使缓存失效，为什么两者都被使用？在我看来，由于 Cyclone V 使用 pl310 缓存控制器，它的代码应该用于清除和无效。这是通过 #define 配置的，用于确定调用哪个代码，并且某些信息告诉我这也应该修复。
意见？选项？想法？
我很开放，请让我知道您的想法。
解决方法
由于您使用的是基于 v2020.10 的内容，因此您在这里遗漏了所有与缓存相关的更改：https://source.denx.de/u-boot/u-boot/-/commit/d0c04926cd054cf7360ec15913ac17a465f32603
至于您提出的其余内容，U-Boot 邮件列表（如果是正确的论坛），请确保抄送之前处理过代码的相关人员。 scripts/get_maintainer.pl 工具将对此有所帮助。