问题标签 [soc]

我知道手臂复位向量可以是低（0x00000000）或高（0xffff0000）。但是 linux 内核中的一些 SoC 代码说可以更改重置向量。

例如，在 mach-imx

他们说辅助 cpu 可以通过jump_addr跳转到你想要的地方。

你能告诉我它是如何工作的吗？

我想以编程方式获取完整的处理器名称，就像 CPU-Z 应用程序一样。eg：Qualcomm Snapdragon 800。最后一个对我来说是最重要的信息，即800。

我正在学习基于 ARM 的 SoC 开发的 Linux 内核前景。
这是学习的早期阶段，肯定需要很长时间，因为事情似乎很全面。
目标是在生态系统中有足够的定位，以便一旦要解决自己项目中的具体问题，就能够在适当的路径中进行搜索/调查。

有 Linus 的树，香草内核。至于 ARM 平台，还有 ARM 端口 tee/project/repository。但是，如果要查看 MAINTAINER 文件，则显然有几个维护者/子系统，这些维护者/子系统显然是 ARM 特定的窄谱主题。
我想知道为什么所有这些窄谱主题不交付/贡献到 ARM 端口（http://www.arm.linux.org.uk/）存储库，而不是直接交付到 Torvalds 树？似乎也存在 ARM SUB-ARCHITECTURES 子系统。几个窄谱子系统/维护器似乎旨在移植到某个平台，结论基于对找到的子系统/维护器的命名。为什么这些集中在/直接贡献给 Linus 树而不是对 ARM SUB-ARCHITECTURES 子系统或如上所述？

该组织在某种程度上是神秘的，对于新手来说是不透明的。

I've got a Xilinx Zynq 7000-based board with a peripheral in the FPGA fabric that has DMA capability (on an AXI bus). We've developed a circuit and are running Linux on the ARM cores. We're having performance problems accessing a DMA buffer from user space after it's been filled by hardware.

Summary:

We have pre-reserved at boot time a section of DRAM for use as a large DMA buffer. We're apparently using the wrong APIs to map this buffer, because it appears to be uncached, and the access speed is terrible.

Using it even as a bounce-buffer is untenably slow due to horrible performance. IIUC, ARM caches are not DMA coherent, so I would really appreciate some insight on how to do the following:

1. Map a region of DRAM into the kernel virtual address space but ensure that it is cacheable.
2. Ensure that mapping it into userspace doesn't also have an undesirable effect, even if that requires we provide an mmap call by our own driver.
3. Explicitly invalidate a region of physical memory from the cache hierarchy before doing a DMA, to ensure coherency.

More info:

I've been trying to research this thoroughly before asking. Unfortunately, this being an ARM SoC/FPGA, there's very little information available on this, so I have to ask the experts directly.

Since this is an SoC, a lot of stuff is hard-coded for u-boot. For instance, the kernel and a ramdisk are loaded to specific places in DRAM before handing control over to the kernel. We've taken advantage of this to reserve a 64MB section of DRAM for a DMA buffer (it does need to be that big, which is why we pre-reserve it). There isn't any worry about conflicting memory types or the kernel stomping on this memory, because the boot parameters tell the kernel what region of DRAM it has control over.

Initially, we tried to map this physical address range into kernel space using ioremap, but that appears to mark the region uncacheable, and the access speed is horrible, even if we try to use memcpy to make it a bounce buffer. We use /dev/mem to map this also into userspace, and I've timed memcpy as being around 70MB/sec.

Based on a fair amount of searching on this topic, it appears that although half the people out there want to use ioremap like this (which is probably where we got the idea from), ioremap is not supposed to be used for this purpose and that there are DMA-related APIs that should be used instead. Unfortunately, it appears that DMA buffer allocation is totally dynamic, and I haven't figured out how to tell it, "here's a physical address already allocated -- use that."

One document I looked at is this one, but it's way too x86 and PC-centric: https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt

And this question also comes up at the top of my searches, but there's no real answer: get the physical address of a buffer under Linux

Looking at the standard calls, dma_set_mask_and_coherent and family won't take a pre-defined address and wants a device structure for PCI. I don't have such a structure, because this is an ARM SoC without PCI. I could manually populate such a structure, but that smells to me like abusing the API, not using it as intended.

BTW: This is a ring buffer, where we DMA data blocks into different offsets, but we align to cache line boundaries, so there is no risk of false sharing.

Thank you a million for any help you can provide!

UPDATE: It appears that there's no such thing as a cacheable DMA buffer on ARM if you do it the normal way. Maybe if I don't make the ioremap call, the region won't be marked as uncacheable, but then I have to figure out how to do cache management on ARM, which I can't figure out. One of the problems is that memcpy in userspace appears to really suck. Is there a memcpy implementation that's optimized for uncached memory I can use? Maybe I could write one. I have to figure out if this processor has Neon.

我正在使用基于 Xilinx Zynq 7000 ARM 的 SoC。我正在为 DMA 缓冲区苦苦挣扎（需要帮助在 Xilinx/ARM SoC (Zynq 7000) 上映射预先保留的 **cacheable** DMA 缓冲区），所以我追求的一件事是更快的 memcpy。

我一直在考虑使用 Neon 指令和内联 asm 为 ARM 编写更快的 memcpy。无论 glibc 有什么，它都很糟糕，尤其是当我们从一个未缓存的 DMA 缓冲区复制时。

我从各种来源整合了我自己的复制功能，包括：

• 快速 ARM NEON memcpy
• gcc中的arm内联汇编
• http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html

对我来说主要的区别是我试图从一个未缓存的缓冲区复制，因为它是一个 DMA 缓冲区，而 ARM 对缓存的 DMA 缓冲区的支持是不存在的。

所以这就是我写的：

我做的主要事情是省略了预取指令，因为我认为它在未缓存的内存上毫无价值。

这样做导致 glibc memcpy 的速度提高了 4.7 倍。速度从大约 70MB/秒到大约 330MB/秒。

不幸的是，这并不像缓存内存中的 memcpy 那样快，系统 memcpy 的运行速度约为 720MB/秒，Neon 版本的运行速度约为 620MB/秒（可能更慢，因为我的 memcpy 可能不进行预取）。

谁能帮我弄清楚我能做些什么来弥补这个性能差距？

我尝试了很多事情，比如一次复制更多，两次加载，然后是两次存储。我可以尝试预取只是为了证明它没用。还有其他想法吗？

我是一个相当新的 SoC，我目前正在使用评估平台 Zedboard。我在我的块设计中包含了一个四通道 SPI，并希望通过在其中一个 ARM 处理器上运行的 Linux 与它进行通信。我需要 SPI 在一次突发中传输/接收 32 位并处理来自 C++ 的通信。但是，我无法让它工作。

Quad SPI 设置为标准，无 FIFO 和事务宽度 = 32 位。我已将 Linux 设备树更新如下：

在此之后，我可以按预期在 /dev 中看到 spidev0.0 和 spidev.0.1。此外，当使用 bits_per_word = 8 写入设备文件时，我从 quad SPI 中得到一个 8 位突发，但有 32 个时钟周期，即我得到对应于 32 位突发的 1/4 的第一个字节（通过调试探针看到在 Vivado 中）。我想我看到了这一点，因为事务宽度设置为 32 位。

但是，当我想将突发更改为 32 位 (bits_per_word = 32) 时，它不起作用 - 我在我的 Linux 终端中收到消息“xilinx_spi_setup_transfer，不支持的 bits_per_word=32”。

我在 C++ 中使用以下代码：

我曾尝试编译 xilinx 驱动程序 xilinx-spi.c 但是当我尝试安装它时（在 Linux 中使用“modprobe xilinx_spi”）它说“设备或资源忙”。

如何让它支持 32 位，以便我可以一次传输/接收 32 位？有人可以帮我吗？谢谢！

兄弟。雅各布

我有一个使用A20-OLinuXino-MICRO-4GB board的软件项目。我无法控制使用哪个板，所以关于替代品的建议没有帮助。

它有一个 Allwinner A20 双核 Cortex-A7 处理器 (armv7a)。

我尝试从 linux 进行工作，但即使具有最高优先级 PTHREAD_EXPLICIT_SCHED 和 SCHED_FIFO，我也无法阻止控制代码的时间关键部分的中断（需要每 10 微秒处理一次，但每秒大约 40 次有 40 微秒的间隙） .

有了上述限制，从 linux 访问 SPI 和 UART 的建议也无济于事。第二个线程的时间限制（整个 cpu 核心专用于它）意味着常规 linux 目前不是一个可行的替代方案。也许一个完整的实时 linux 可以完成这项工作，但我没有资源来构建它，只是想看看它是否可以工作。

目前的开发环境：

构建u-boot目前不适用于 5.x 版本的 gcc，因此没有太多空间可以移动到那里。

所以转而将其编写为从 u-boot 开始的独立代码。那里没有额外的延迟，但现在我缺少配置核心其他模块的东西。当我尝试初始化和配置 SPI 或 UART 设备（除了用于 u-boot 控制台的 UART0 之外）时，所有寄存器都报告为零，并且即使在设置它们之后也保持在那里。它就像那里没有任何东西（没有硬件）一样。UART0 具有合理/预期的值，并且配置标准 GPIO 引脚（输入和输出）工作正常。配置多路复用的 GPIO 引脚以供 SPI 或 UART 使用似乎也可以工作，但模块顽固地拒绝承认它们的存在。

示例代码、Makefile 和尝试与 SPI 模块对话的输出可以在 olimex 论坛中找到。请注意，示例使用来自 u-boot 构建的包含文件。用于创建该代码的主要文档是A20 用户手册。

有没有人使用过 A20、Cortex-A7、armv7a 或类似芯片，并想出如何访问 linux 之外的功能？

有人知道在哪里可以获得有关该级别编程的更好文档吗？

我的用户手册有很多关于寄存器地址、偏移量、位掩码的信息，但没有任何代码示例。我希望一个简单的独立 C（甚至汇编程序）示例，它配置任何（设备）模块，并设置一个中断来处理它，对找出其余部分非常有帮助。

实际上，我通过位敲击 I/O 引脚使 SPI 通信正常工作。这不适用于 UART，而 SPI 看起来像是一个更简单的情况，首先要处理。

我多年来一直在大型系统上编程，有些在非常小的（6502、8085、arduinio）系统上编程，但在这种环境下没有真正的开发经验。我不是内核程序员，也不是任何接近的人。

编辑：我在示例代码中添加了 SPI1 时钟设置，但在设置它们之前和之后，所有 SPI 寄存器仍然显示为全零。代码更改：

这表明时钟配置 DID 从 0x00000000 变为 0x8003000f

在 ARM7 中，当处理器复位时，它会在复位时从 0x00000000 地址开始执行代码，但在基于 ARM7 的 lpc214x 中，复位时引导加载程序会执行，其 lpc2148 的起始地址为 0x7FFFD000，因此在复位时如何将该起始地址加载到 pc。然后 pc 将如何加载 0x00 地址？

在下图中，给出了 lpc2148 的内存映射。

我在 Linaro 上制作了一个设备驱动程序，运行一个 zedboard 来控制 Linux 的开关和 LED。

它们安装为 /proc/zedLeds 和 /proc/zedSwitches

当从 C 生成的程序迭代地读取和写入相应的驱动程序时，几乎没有延迟。当开关被翻转时，相关的 LED 会立即亮起。

我构建了 GNU Radio 模块（开关源和 LED 接收器）来从 GNU Radio 做同样的事情。它们通过 32k 采样节流阀连接。运行此设计时，它运行的时间越长，切换-> 照明的延迟就越长。

我的方法与使用 C 方法基本相同，所以我不确定极端延迟来自何处。有油门和没有油门我都试过了。

会不会是使用 GNU 只是占用了太多落后于操作的资源？

这是包含所有项目文件的 github。

https://github.com/minersrevolt/zedboard_gnuradio

结构：

我和我的团队正在设计一个项目，该项目需要检测方波的上升沿，然后使用 time.time() 将时间存储在变量中。如果将相同的方波提供给 RPi 的 3 个不同引脚，则事件检测应用在每个引脚上，理论上它们应该同时发生，但是它们有一个延迟，这也会导致相位差异（我们是从时间计算相位）。我们得出的结论是 time.time() 是一个缓慢的函数。谁能帮助我了解使用哪个函数来获得比 time.time() 更精确的 SOC？或者请向我提供函数 time.time() 背后的编程。我会很感激的。