问题标签 [omap]

在下面的链接中，在内核下，提到它“将内核映像解压缩到 SDRAM”。u-boot 会这样做吗？如果不是，“内核”如何解压缩“内核”图像？

链接： http: //omapedia.org/wiki/Bootloader_Project#OMAP_Bootloader_Overview

在带有 Imagination Technologies PowerVR SGX 530 的 DM370 (TI OMAP 3) 上，我能够使用以下代码使用 CMEM 和 PIXMAP 屏幕外表面来初始化我的 EglSurface：

在 OMAP 5 / Sitara - AM57xx EVM 和 SGX 540 GPU 上，我使用 OpenGL 库、cmemk.ko 和 pvrsrvctl 构建和部署了处理器 SDK。我可以成功运行 PVR OpenGL 演示并且它们显示在显示器上。我试图在这个新的 EVM 上运行我的应用程序，但它总是失败：

如果我删除 pi32ConfigAttribs 中的 EGL_PIXMAP_BIT，那么它会更进一步。

AM57xx OpenGL 库不支持 PIXMAP 表面吗？如果他们这样做，我怎样才能让他们工作？谢谢！

我正在使用 OMAPl138 lcdk，并且我有一个用于音频处理的基本应用程序（一些过滤 + 均衡器，没什么特别的）。由于历史原因，我声明了很多静态和全局数据、变量、数组和结构......

基本上我的应用程序工作正常。但是，如果我再声明一个静态变量数组，我就看不到输出信号。同时我不访问它，它只是声明的。

最初我有以下 .bss

和 .far 部分

我正试图宣布static float tmpArr[8]并看到失败。

这些部分与声明如下的 DDR 内存有关：

所以它的未使用大小是 0x6fc0aa，这是一个要放置的大房间:)。

它可能与什么有关？任何点击都非常感谢。

根据我尝试的一些配置，/etc/fw_env.config例如一两个条目，在尝试读取 U-boot 环境变量时出现以下错误：

或者

根据本教程（https://developer.ridgerun.com/wiki/index.php/Setting_up_fw_printenv_to_modify_u-boot_environment_variables），我构建了我/etc/fw_env.config的样子：

仅供参考，我正在使用 TI Omap ARM 芯片（var-som-am33）和 Variscite 的 Yocto Fido 默认开箱即用，具有以下软件版本：

• U-boot版本： u-boot-var-som-am33 2014-+gitrAUTOINC+adf9a14020

• U-boot-fw-utils 版本：u-boot-fw-utils v2014.07+gitAUTOINC+524123a707-r0-arago0-var

我正在为 VxWorks 开发 BSP 并遇到以下问题：

UART3 TX 中断已启用，IIR 显示 PENDING THR 中断，但 Cortex A-9 GIC 无法识别它。因此 VxWorks IO 缓冲区已满，但 UART FIFO 仍为空。

当我在 GIC 中手动将相应的中断设置为 PENDING 时，它会传播中断并执行 ISR，从而将 64 字节发送到 UART FIFO 并正确打印在 RS232 上。证明 ISR 设置正确且正常运行，并且在 GIC 分发器中启用了中断。

OMAP4430 具有 16550 兼容的 UART。波特率配置很好，因为我可以在轮询模式下成功使用它。

UART TX 中断没有被断言的可能原因是什么？

编辑：找到了我的问题的原因，看起来中断号被移动了 32 位：

OMAP4430 TRM 指出 UART3 有中断线 74，但是当我查看 GIC 的 PENDING 寄存器时，我看到第 106 行有一个中断正在等待。考虑到 106 是 74 + 32 的总和，我尝试将中断线 106 配置为 UART3 中断号，看看它是否有效！

串行驱动程序是来自 VxWorks 的 vxbNs16550，GIC 驱动程序也来自 VxWorks，中断线是从 UART 到 TI 定义的 GIC 的物理连接。那么为什么物理中断线的编号会出现这种差异呢？

我将串行连接焊接到 Marquis Tablet MP977 以将直接外壳插入根目录。我使用的是电缆 1（9 针到 USB/图片 1），然后是 adafruit 一（图片2），我尝试了从 9600 到 115200 的所有串行速度。我得到的只是这个

M\0x9e\0x08\0x0c\0xc6\0x89\0x1f^\0xd0\0xd2r_=\0xf4\0x0e\0x9a\0x00[\0xe8RhI\0xd2\0xdb\0x88\0x003\0xc9\0xb8\0x1a\0x14=\0x13d* 3\0xcd\0xb1\0x9e\0x9b\0x1a4b4\0xe7\0xe7Z.\0xc0*\0xf8\0x93\0xb9 3\0x9d/s\0x99F\0x1f\0xfbd\0x19\0x93\0xebY\0x12\0xe9\0x9a ^\ 0x1eJ^ZNKM\0x00M^L\0xe7\0x12\0x1a {\0xf4\0xe9&X\0x0038\0xcec\0xf4\0xcb\0xa7\0xdd\0xe33\0xdd\0xb2\0xd1-\0xc9,\0xcc\0x00\0x00q\0x17 \0xd7\0x11{W\0x17\0xae\0xd4\0xa9\0xc8q\0xd5W\0x95\0xf2W\0xd7\0xaf\0x13\0x91\Z\0x16\0x95\0xbd\0x85\0xa1M]\0xfd\0xc2U\0xffZ] \0xc5u\0x93\0xd3\0xafE\0xaa\0xa4\0x14\0x95\0x97j\0x95\0xd7\0x81\0xe8.\0x00q\0xaf\0xd7\0xad\0x97\0xd5\0x13\0xae\0xf4\0x13\0x17\ 0xbdT\

我们使用的是运行 3.2 版内核的定制板，但在测试 MMC 层的稳健性时遇到了一些问题。

首先，我们的MMC插槽没有卡检测引脚。有问题的问题包括以下内容：

1. 加载模块 (omap_hsmmc)。卡在上电时被检测到，并被正确安装。
2. 从 SD 卡中读取内容（即cat foo.txt）
3. 在读取文件时，取出卡。
4. 在多次尝试失败后，系统挂起。

现在，我已将问题跟踪到以下代码部分drivers/mmc/card/queue.c：

调查这段代码，我发现它挂在mq->issue_fn(mq, req)调用中。此函数准备并发出适当的命令来完成传递给它的请求，并且它知道当它无法与卡通信时发生的任何错误。该错误以一种尴尬（在我看来）的方式处理，并且不会“冒泡”到mmc_queue_thread. 但是，我已经对照最新的内核版本（4.9）检查了我的版本代码，除了更好地分离每个错误情况（处理非常相似）之外，我没有发现在处理此类错误方面有任何区别）。

我怀疑这个问题是由于上层无法停止发出从 MMC 卡读取的新请求引起的。

我试过的：

• 重写了代码，以便将错误传递给我，以便我可以做ret = mq->issue_fn(mq, req)。
• 为了能够识别出具体的错误，我尝试以不同的方式取消线程：调用kthread_stop、调用mmc_queue_suspend、__blk_end_request等等。有了这些，我所能完成的最多就是保持线程处于“无害”状态，它仍然存在，但不消耗任何资源。但是，触发调用的用户空间程序没有返回，锁定在不可中断状态。

我的问题：

1. 通过阻止上层发出新请求来解决这个问题的最佳方法是什么？还是应该“杀死”线程本身？
2. 在我这样的情况下，是否应该假设因为没有卡片检测针，所以不应该取出卡片？

更新：我发现您可以告诉驱动程序使用轮询来检测卡插入/移除。可以通过在驱动程序初始化时将MMC_CAP_NEEDS_POLL标志添加到 mmc来完成.caps（在较新的内核上，您可以使用broken-cdDT 上的属性）。但是，修改后问题仍然存在。

我很难在AM57xx EVM板上使用基于 Yocto 发行版和 bitbake monster 的 Arago linux 。每一步都是一个问题。TI 论坛充斥着问题，但没有人回答，...看起来不是那么受欢迎的板。我打算用 debian 替换 yocto，以便更好地维护和包控制。我想知道哪个是正确的程序。

• 内核和 u-boot 将保留。
• 我从最小的 jessie ARM64 作为根 fs 开始。
• 57XX 以前的 rootfs 树有板特定的模块/lib/modules/KERNEL_VER/*文件
• 还有一些/usr/bin特定于板 IPC 的二进制文件
• /etc/init.d/daemons内核之间也有一些针对相同特定IPC的。
• Jessie Debian 与/lib/modules/KERNEL_VER2/modules现有的不同。

清除 yocto 的正确程序是什么，保存必须留下的东西，（/boot/ /etc/some /lib/modules/X.Y.Z.YOCTO/modules /usr/bin/some）放置 debian-jessie 并使其使用旧的保存/modules。

我尝试为基于 TI am335x soc 的板创建裸机应用程序。我需要做的一件事是callback1在上升沿和callback2下降沿调用。从数据表中我发现，可以通过写入1 << pinRISINGDETECT 和 FALLINGDETECT GPIO 寄存器来同时检测上升沿和下降沿。但是，我无法理解（在数据表中没有看到任何迹象），我如何确定当前出现的中断是由 GPIO 上的上升沿还是下降沿引起的？

我正在尝试运行从官方 linux-omap GIT 获得的最新 linux-omap 内核 Linux-4.3.0-rc5-12674-g80923cf8e。

我使用 multi_v7_defconfig 编译它，禁用不需要的板并添加一些调试选项，如 earlyprintk。

我现在陷入内核恐慌，找不到问题所在。

该板是 IGEPv2，我使用的是 omap3-igep0020.dts 设备树文件。

如果有帮助，使用最新的 u-boot 加载内核。

这是引导日志。任何想法 ？

我很困惑，因为似乎有几个堆栈跟踪。尽管在内核中编译了调试信息，但我也无法获得更详细的堆栈跟踪（但我怀疑调试信息实际上并不存在，因为文件非常小）

制造商 ISEE 为该板提供的最后一个支持的内核是 2.6.37，它非常旧。运行更新的内核似乎没有任何问题，但设备树文件可能长时间没有更新......我只是在寻找这个错误可能来自哪里的指针，我会尝试修复它。

谢谢 ！