szembed的博客

凭借其出色的性能表现、灵活的扩展能力以及全方位的安全保障机制，T536无疑将成为推动下一代智能硬件创新的关键驱动力之一。无论是在严苛的工业环境中还是在追求极致用户体验的消费市场中，T536都将展现出非凡的价值。以上就是关于T536工业级设备处理器的一个详细介绍。如果您想了解更多详情或者有任何疑问，请随时联系我们。

REC 是接收错误计数，TEC 是发送错误计数。由图可知 TEC 大于 255 时，进入 bus-off。回顾图一，得知这是发送数据出现了问题。此时数值为 f8H ，小于 255 ，但还是触发 bus-off 错误，百思不得其解。而且还测试了 CANH 和 CANL 的电压，处于空闲状态时，都是 2.5V ，正常。和硬件工程师沟通后，硬件工程师把 CAN 芯片换了另一个型号，发现能正常使用。bus-off 错误是致命错误，直接把 can 接口关闭了。发现 can0 的环回模式没有问题。

可以通过U-Boot菜单进行选择，在U-Boot启动倒数结束前按下“Ctrl+c”，进入U-Boot设置菜单，根据实际情况选择。图1.1 device/config/chips/t536/configs/demo/uboot-2023/uboot-board.dts。device/config/chips/t536/configs/demo/uboot-2023/uboot-board.dts和。T536支持LVDS、MIPI-DSI、LCD三种接口的屏幕。使用时将对应的dtsi使能即可。

看板 B ，它接收不到来自板 A 的 reply 包，而且先前已确认板 B 的 eth0 能正常通信，所以可确定板 A 的 eth0 的 TX 有问题。由于 T536 Demo 板是能正常通信的，它用的 PHY 芯片是 rtl8211 ，而我们自己的 T536 的 PHY 芯片是 yt8531H。所以从硬件上定位到问题，就是 TX 的时钟频率过低，导致根据 5M 时钟频率从 TX 发出的数据，对端 RX（时钟频率 25M ）无法正常接收。通过对比可知，板 B 往板 A 发送数据，板 A 是能正常接收的。

大部分 WiFi 驱动为了增强兼容性，驱动中会有一些存放 .h 文件的目录，而在 Makefile 中会引用这些目录，因为版本的差异， 此类目录的引用方法可能不一样。由于现在全志将他们自己的模块驱动都放到 BSP 目录，然后通过创建软链接文件，链接到内核目录中，所以现在把 rtl8821CS 驱动移植到 BSP 目录内。Kconfig 修改正确后，在 make kernel_menuconfig 中应该能看到 rtl8821CS 模块， 勾选后可以进行编译错误的解决。，我是从 T507 移植过来的。

这次仅调试 PCIe 的 RC 模式，RC 模式是 PCI 传统的类树状连接模式，而 EP 模式是 PCIe 独有的点对点连接模式。连接上之后，重新上电，进入终端输入。在固件包内，找到 rtl_nic 目录，把这个目录包括目录内的文件复制到开发板的文件系统的 /lib/firmware 内。在 board 设备树文件中，如果未发现这两个节点的开启状态，需要自己添加。接上网线，开启对应网口，获取动态 IPv4 ，ping 外网。由于该网卡有双网口，输入。插上 PCIe 网卡，上电开发板，进入终端输入。

usb转串口适配模块要被内核识别，生成ttyUSB设备，才能使用AT指令拨号，需要在drivers/usb/serial/option.c源码中加入此模块的PID和VID，但是如果插入后，发现dev目录下有新的ttyUSB*设备出现，就不需要这步骤了，说明内核已支持该模块。内核源码：drivers/usb/serial/option.c内核配置：CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_OPTION=y CONFIG_USB_SERIAL_QT2=ylsus