tag 标签: toradex

相关博文
  • 2025-3-6 12:00
    61 次阅读|
    0 个评论
    B y Toradex 秦海 1). 简介 基于 ARM 平台 Yocto Linux BSP 开发嵌入式设备,开发完成后需要生成用于量产的 Yocto Linux BSP 镜像,本文就基于 Toradex Yocto Linux BSP 镜像进行量产定制做流程说明。 2. 准备 a). Toradex Yocto Linux BSP 提供预编译好的基于 Downstream/Mainline Linux Kernel 版本的 Minimal 或者 Multimedia 镜像供客户测试开发,具体可以从下面地址下载。 https://developer.toradex.cn/software/toradex-embedded-software/toradex-download-links-torizon-linux-bsp-wince-and-partner-demos/#toradex-embedded-linux---yocto-project-reference-images b ). Toradex ARM 核心板 产品出厂预装 Toradex Easy Installer 工具软件,便于进行量产安装,因此对应使用的 Yocto Linux BSP 镜像也是适用于通过 Toradex Easy Installer 安装的镜像,具体关于 Toradex Easy Installer 的更详细介绍请见如下。 https://developer.toradex.cn/easy-installer/toradex-easy-installer/toradex-easy-installer-overview/ c). 如果熟悉 Yocto Project 编译环境,可以参考如下文章通过 Yocto Project 来定制编译用于量产的 BSP 镜像,本文不做赘述。 https://www.toradex.cn/blog/tong-guo-ycoto-project-ding-zhi-qian-ru-shi-ycoto-linux-jing-xiang 3). 定制流程 a). 本文以适用于 Verdin i.MX8M Plus 的 Yocto Linux Mutimedia BSP Reference Image 镜像为例进行示例,其他平台和版本的 BSP 方法思路都一致。 b). 从 这里 下载针对 Verdin i.MX8M Plus 的 Yocto Linux Mutimedia BSP Reference Image V7.x 版本,并解压后包含文件如下。 ------------------------------- $ tar xvf Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.1.0+build.3.tar $ cd Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.1.0+build.3/ $ tree -L 1 . ├── image.json ├── imx-boot ├── LA_OPT_NXP_SW.html ├── marketing.tar ├── prepare.sh ├── Reference-Multimedia-Image-verdin-imx8mp.rootfs.bootfs.tar.xz ├── Reference-Multimedia-Image-verdin-imx8mp.rootfs.tar.xz ├── toradexlinux.png ├── u-boot-initial-env-sd └── wrapup.sh 0 directories, 10 files ------------------------------- c). image.json 是 BSP 镜像配置文件, Toradex Easy Installer 软件就是通过读取这个文件来进行 BSP 镜像更新的 ./ image.json 配置文件详细说明请见如下文章,不同的硬件平台具体的文件会有不同,尤其是底层 bootloader 相关的 binary 文件。本文只将和定制量产镜像相关的参数着重说明。 https://developer.toradex.cn/easy-installer/toradex-easy-installer/toradex-easy-installer-configuration-files ./ “ autoinstall ” 参数定义了是否自动安装 BSP 镜像 ------------------------------- false - 不自动安装 (default) true - 自动安装 ------------------------------- ./ “u_boot_env” 参数定义了 U-Boot 启动动态加载的环境变量参数,可以将自定义的 U-Boot 环境变量参数更新到这个文件,刷写 BSP 镜像后启动即可以生效。 ------------------------------- u-boot-initial-env-sd (default) ------------------------------- ./ “ prepare_script ” 参数定义了 Toradex Easy Installer 工具进行分区和烧写镜像操作前需要进行的操作 ------------------------------- prepare.sh (default) ------------------------------- ./ “wrapup_script” 参数定义了 Toradex Easy Installer 工具完成分区和烧写镜像操作后需要进行的操作 ------------------------------- wrapup.sh (default) ------------------------------- ./ “blockdevs” 参数下面就定义了实际需要烧写的镜像以及分区,当然也可以参考上述配置文件说明定制添加自己需要的分区或者只读文件系统等。 // 通常首先是一个 FAT32 分区,用于烧写包括 Linux Kernel Image/Device-Tree Binary/Device-Tree Overlay Binary 等启动文件, ” filename ” 参数定义了写入的文件压缩包, "uncompressed_size" 定义了要写入文件未压缩前的大小 (MB) 。如果定制镜像过程中修改了压缩包文件的名字和文件大小就需要修改对应修改这两个参数。 ------------------------------- "label": "BOOT", "filesystem_type": "FAT", "mkfs_options": "", " filename ": "Reference-Multimedia-Image-verdin-imx8mp.rootfs.bootfs.tar.xz", " uncompressed_size ": 8.671875 ------------------------------- // 然后是一个 EXT4 分区,用于烧写 Linux Rootfs 文件系统文件, ” filename ” 参数定义了写入的文件压缩包, "uncompressed_size" 定义了要写入文件未压缩前的大小 (MB) 。如果定制镜像过程中修改了 Rootfs 文件系统压缩包文件的名字和文件大小就需要修改对应修改这两个参数。 ------------------------------- "label": "RFS", "filesystem_type": "ext4", "mkfs_options": "-E nodiscard", " filename ": "Reference-Multimedia-Image-verdin-imx8mp.rootfs.tar.xz", " uncompressed_size ": 1272.7109375 ------------------------------- // 最后是 Raw 分区,用于烧写包括 Bootloader Binary 等在内的底层引导固件文件,文件可能是一个文件或者多个文件,根据不同的硬件平台不一致。 ” filename ” 参数定义了写入的 Binary 固件文件,比如 Verdin i.MX8MP 平台对应的是 imx-boot 文件就是一个包含 ATF/DDR Firmware/SPL/U-Boot 等的 Boot Container ,而比如 Verdin AM62 平台则每个固件都是分开的单独文件。 ------------------------------- "filesystem_type": "raw", "rawfiles": ------------------------------- d). “ imx-boot ” 如章节 (c) 说明是 Verdin i.MX8MP 平台对应的 Boot Container 文件,如果需要修改底层 Bootloader ,可以参考如下文章修改编译生成新的 “ imx-boot ” 文件后替换 BSP Image 镜像里面的文件。 https://developer.toradex.cn/linux-bsp/os-development/build-u-boot-and-linux-kernel-from-source-code/build-u-boot/ e). “prepare.sh” 如章节 (c) 说明是烧写镜像前需要进行的操作,通常不需要修改。 f). “ wrapup .sh” 如章节 (c) 说明是烧写镜像后进行的操作,如果使能了 “ autoinstall ” 自动安装可以增加如下内容在完成自动安装后自动重启。 ------------------------------- reboot -f exit 0 ------------------------------- g). “Reference-Multimedia-Image-verdin-imx8mp.rootfs.bootfs.tar.xz” 压缩包文件如章节 (c) 说明是 FAT32 启动分区文件,请注意不同 Yocto Linux BSP 版本命名方式可能略有不同。 ./ 解压后内容如下 ------------------------------- $ cd Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.1.0+build.3/ $ mkdir bootfs $ tar Jxf Reference-Multimedia-Image-verdin-imx8mp.rootfs.bootfs.tar.xz -C bootfs/ $ cd bootfs $ tree -L 1 . ├── boot.scr ├── Image.gz ├── imx8mp-verdin-nonwifi-dahlia.dtb ├── imx8mp-verdin-nonwifi-dev.dtb ├── imx8mp-verdin-nonwifi-ivy.dtb ├── imx8mp-verdin-nonwifi-mallow.dtb ├── imx8mp-verdin-nonwifi-yavia.dtb ├── imx8mp-verdin-wifi-dahlia.dtb ├── imx8mp-verdin-wifi-dev.dtb ├── imx8mp-verdin-wifi-ivy.dtb ├── imx8mp-verdin-wifi-mallow.dtb ├── imx8mp-verdin-wifi-yavia.dtb ├── overlays └── overlays.txt 1 directory, 13 files ------------------------------- ./ “ boot.scr ” 文件是 Linux U-Boot Distroboot 配置文件,如果定制 BSP 镜像涉及 Linux Kernel 启动参数相关配置,可以参考 这里 修改并重新生成这个文件后替换原有文件。 ./ 其他文件都是包含 Linux Kernel Image / Device-Tree Binary / Device-Tree Overlay Binary 等文件,如果定制 BSP 涉及了相关修改可以在这里替换原有文件。 ./ 修改完成所有要修改的文件后,可以通过如下命令重新压缩,如果命名不变则无需修改 image.json 文件,否则就要对应修改。 ------------------------------- $ cd Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.1.0+build.3/bootfs/ $ tar Jcf ../Reference-Multimedia-Image-verdin-imx8mp.rootfs.bootfs.tar.xz * $ cd .. $ rm -rf bootfs/ ------------------------------- h). “Reference-Multimedia-Image-verdin-imx8mp.rootfs.tar.xz” 压缩包文件如章节 (c) 说明是 EXT4 Linux Rootfs 文件系统分区文件,请注意不同 Yocto Linux BSP 版本命名方式可能略有不同。 ./ 解压后内容如下 ------------------------------- $ cd Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.1.0+build.3/ $ mkdir rootfs $ sudo tar Jxf Reference-Multimedia-Image-verdin-imx8mp.rootfs.bootfs.tar.xz -C rootfs/ $ cd rootfs $ tree -L 1 . ├── bin - usr/bin ├── boot ├── dev ├── etc ├── home ├── lib - usr/lib ├── media - run/media ├── mnt ├── opt ├── proc ├── root ├── run ├── sbin - usr/sbin ├── srv ├── sys ├── tmp ├── unit_tests ├── usr └── var 18 directories, 1 file ------------------------------- ./ 在这里可以进行 Linux Rootfs 相关的修改适配,比如部署应用程序以及相关运行库,配置应用程序开机自启动等,下面是几个简单示例。 ------------------------------- ### modify below default autorun systemd service file to make customized application autorun ### rootfs/lib/systemd/system/wayland-app-launch.service ... ExecStart=/usr/share/cinematicexperience-1.0/Qt5_CinematicExperience --fullscreen ... ### modify below splash picture to adapt customized splash after enabling plymouth in Yocto project ### rootfs/usr/share/plymouth/themes/spinner/watermark.png ### modify weston configuration file if needed, below for example to hide weston normal shell ### rootfs/ etc/xdg/weston/weston.ini ... shell=kiosk-shell.so ... ------------------------------- ./ 修改完成所有要修改的文件后,可以通过如下命令重新压缩,如果命名和大概文件大小不变则无需修改 image.json 文件,否则就要对应修改。 ------------------------------- $ cd Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.1.0+build.3/rootfs/ $ sudo tar Jcf ../Reference-Multimedia-Image-verdin-imx8mp.rootfs.tar.xz * $ cd .. $ sudo rm -rf rootfs/ ------------------------------- i). “u-boot-initial-env-sd” 如章节 (c) 说明是 U-Boot 环境变量配置文件,可以将定制需要的环境变量修改或者添加在这个文件。比如这里示例添加为了显示 Plymouth Splash 以及关闭 log 输出的环境变量定义。 ------------------------------- tdxargs = quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3’ bootdelay = 0 ------------------------------- j). 定制完成后将完整 BSP image 文件复制到 U 盘或者 SD 卡,通过模块 Toradex Easy Installer 工具安装到模块进行量产即可。 4 ). 总结 本文 基于 Toradex i.MX8MP ARM 处理器平台示例了 Yocto Linux 量产 BSP 镜像定制流程,其他平台定制思路都是基本一致的。
  • 2025-2-26 12:17
    254 次阅读|
    0 个评论
    ARM 处理器平台 eMMC Flash 存储磨损测试示例
    ​ By Toradex秦海 1).简介 目前工业嵌入式ARM平台最常用的存储器件就是eMMC Nand Flash存储,而由于工业设备一般生命周期都比较长,eMMC存储器件的磨损寿命对于整个设备来说至关重要,因此本文就基于NXP i.MX8M Mini ARM处理器平台演示eMMC器件磨损测试的示例流程。 关于eMMC存储器件的基本介绍可以参考如下文章,eMMC存储器件通常包含有eMMC Nand Flash控制器和一定数量的Nand Flash存储颗粒来组成,ARM处理器主机对于eMMC的操作都要通过Nand Flash控制器进行映射,同时Nand Falsh控制器还负责Wear leveling/ECC/Bad Block Management等功能以保证eMMC器件稳定可靠工作。 eMMC (Linux) | Toradex Developer Center eMMC存储器件的磨损寿命主要由其包含的Nand Flash颗粒存储单元的P/E(programming and erasing)次数来决定,不同Nand Flash颗粒种类通常的P/E次数不同,一个大概的参考如下,不同品牌不同工艺的颗粒会有差异。 ./ SLC Nand Flash - 10K - 100K P/E Cycles ./ MLC Nand Flash - 3K - 10K, normally 3K P/E Cycles ./ 2D TLC Nand Flash - normally 1K P/E Cycles ./ 3D TLC Nand Flash - normally 3K P/E Cycles 但是由于Nand控制器操作Nand Flash存储单元programming写入最小单位是Page,而erasing擦除最小单位是Block,因此当写入/擦除数据不是对应最小单元整数倍时候就会产生额外的开销,同时还附加其他Wear leveling/Garbage collection/Bad Block Management等功能产生的开销,就会导致实际写入的全寿命数据量要小于理论上按照单元P/E Cycles计算的数据量(eMMC capacity * P/E cycles),这个差异就是WAF(Write Amplification Factor)写放大因子((eMMC capacity * P/E cycles)/actual full-lifetime data written)。更多相关说明请参考如下文章。 使用 eMMC 闪存设备的磨损估计 因此由于上述Nand Flash控制器地址映射和WAF的存在,磨损测试是无法直接将Host写入数据和实际Nand Flash颗粒的P/E对应的,而WAF在不同写入情况下又是一个动态数值,所以我们依赖Linux Kernel mmc-utils工具或者eMMC提供商的专用软件来读取Extended CSD rev 1.7 (MMC 5.0)包含的Health Status信息,并通过其每10%的线性变化和实际写入数据是否对应线性变化,以及最终写入数据量,可以推算出实际的WAF。 eMMC (Linux) | Toradex Developer Center 关于CSD Register中Health Status和Spare Block Register的定义说明如下 ./Device life time estimation typeA/B: life time estimationbased on blocks P/E cycles, provided in steps of 10%, e.g.: 0x02 means 10%-20% device life time used. ./Pre EOL information: overall status for reserved blocks. Possible values are: 0x00 - Not defined. 0x01 - Normal: consumed less than 80% of the reserved blocks. 0x02 - Warning: consumed 80% of the reserved blocks. 0x03 - Urgent: consumed 90% of the reserved blocks. 本文所示例的平台来自于ToradexVerdini.MX8MM嵌入式平台。 2.准备 a). Verdin i.MX8MM ARM 核心版配合 Dahlia 载板并连接调试串口用于后续测试 b).参考 这里 下载 Toradex Yocto Linux BSP6 Reference Image c).参考 这里 的说明将上述下载的 BSP Image 安装到 Verdin i.MX8MM 核心板。 d).准备一个 SD 卡,参考 这里 的说明使用上述下载的 BSP Image 制作启动 SD 卡。 3). 测试流程 a).将SD插入Dahlia载板后启动,系统自动会优先从外部SD卡(mmc1)启动,可以通过如下调试串口log信息来进一步判定。 ------------------------------- ...... Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot.scr ...... ------------------------------- b).因为系统会自动mount eMMC对应设备分区,为了后续测试,需要先关闭自动挂载。 ------------------------------- root@verdin-imx8mm-07276322:~# mount |grep /dev/mmcblk0 /dev/mmcblk0p2 on /media/RFS-mmcblk0p2 type ext4 (rw,relatime) /dev/mmcblk0p1 on /media/BOOT-mmcblk0p1 type vfat (rw,relatime,gid=6,fmask=0007,dmask=0007,allo) ------------------------------- 在设备Linux下执行下面脚本关闭自动挂载,执行成功后上述挂载信息就没有了。 ------------------------------- #!/bin/sh -e systemd-umount /dev/mmcblk0p1 systemd-umount /dev/mmcblk0p2 systemctl stop systemd-udevd systemctl stop systemd-remount-fs count=`ls -1 /etc/udev/rules.d/*automount.rules 2/dev/null |wc -l` if then rm /etc/udev/rules.d/*automount.rules fi ------------------------------- c).接下来要通过Linux磁盘操作工具来进行大量写入数据来测试eMMC的磨损,本文测试使用fio工具,当然还有像dd/hdparm等工具也可以根据情况酌情选择。 ./ 首先创建 fio 配置文件,类似如下,具体说明可以参考 fio官方文档 。 ------------------------------- bs=32k direct=0 ioengine=libaio iodepth=4 verify=crc32c filename=/dev/mmcblk0 ; emmc device filename verify_dump=1 verify_fatal=1 randrepeat=0 description=Write once area, used for testing date retention stonewall rw=write verify_pattern=0xaa555aa5 ; fixed data pattern size=256M offset=0 description=Verify write once area, used for testing data retention stonewall rw=read verify_only size=256M offset=0 description=Write r/w stress data area with random data stonewall rw=write do_verify=0 offset=256M description=Verify r/w stress data area stonewall rw=read verify_only offset=256M ------------------------------- //其中需要说明的是bs (block size)的设置需要根据不同的eMMC手册中定义的Optimal Write Size以尽可能减小WAF,比如当前测试eMMC手册中定义如下 实际读取的寄存器数值如下,对应为32KB,因此fio配置文件中bs参数设置为32k或者其整数倍数,可以保证Nand Flash颗粒存储单元写入都是按照Page Size。 ------------------------------- $mmc extcsd read /dev/mmcblk0 | grep write Optimal write size ------------------------------- ./然后可以通过类似如下测试脚本来进行一次写入和验证,测试fio的配置正确和可用以及当前的eMMC Health Status状态 ------------------------------- #!/bin/bash -e EMMC_DEVICE=/dev/mmcblk0 FIO_TEST_NAME=emmc-pe-test.fio echo " eMMC P/E test preparation on ${EMMC_DEVICE}" echo " eMMC EXTCSD Health Status" mmc extcsd read "${EMMC_DEVICE}" | fgrep -A1 DEVICE_LIFE_TIME_EST mmc extcsd read "${EMMC_DEVICE}" | fgrep -A1 PRE_EOL_INFO echo " Write once data" fio --section=write-once "${FIO_TEST_NAME}" echo " Verify write once data" fio --section=verify-write-once "${FIO_TEST_NAME}" ------------------------------- ./最后可以通过如下循环写入脚本持续写入测试来测试eMMC磨损情况。 ------------------------------- #!/bin/bash -e EMMC_DEVICE=/dev/mmcblk0 COUNT=0 FIO_TEST_NAME=emmc-pe-test.fio echo " Starting eMMC P/E test on ${EMMC_DEVICE}" while true do echo " Run $COUNT" echo " eMMC EXTCSD Health Status" mmc extcsd read "${EMMC_DEVICE}" | fgrep -A1 DEVICE_LIFE_TIME_EST mmc extcsd read "${EMMC_DEVICE}" | fgrep -A1 PRE_EOL_INFO echo " Check write once data" fio --section=verify-write-once "${FIO_TEST_NAME}" echo " Wear eMMC" fio --section=write --section=verify "${FIO_TEST_NAME}" COUNT=$(($COUNT + 1)) done ------------------------------- ./磨损测试一次全盘写入和验证的log信息如下,由于实际测试完成时间会非常长,通常根据eMMC容量不同可能需要几天甚至十几天时间,本文就不演示最终完成的数据。最后可以根据寿命达到90%以上时候全部log信息统计出类似如下表格eMMC每磨损10%实际P/E的次数和数据量,得出eMMC的全寿命磨损数据/磨损是否线性以及实际WAF数值。另外,关于LIFE_TIME_EST_A还是LIFE_TIME_EST_B没有标准定义,由各个厂商自行定义,所以实际以厂商定义为准。 ------------------------------- Starting eMMC P/E test on /dev/mmcblk0 Run 0 eMMC EXTCSD Health Status Device life time estimation type B i.e. 0% - 10% device life time used Device life time estimation type A i.e. 0% - 10% device life time used Pre EOL information i.e. Normal Check write once data verify-write-once: (g=0): rw=read, bs=(R) 32.0KiB-32.0KiB, (W) 32.0KiB-32.0KiB, (T) 32.0KiB-32.4 fio-3.30 Starting 1 process Jobs: 1 (f=1) verify-write-once: (groupid=0, jobs=1): err= 0: pid=583: Fri Apr 29 20:04:38 2022 Description : read: IOPS=4908, BW=153MiB/s (161MB/s)(256MiB/1669msec) ... Run status group 0 (all jobs): READ: bw=153MiB/s (161MB/s), 153MiB/s-153MiB/s (161MB/s-161MB/s), io=256MiB (268MB), run=166c Disk stats (read/write): mmcblk0: ios=1009/0, merge=0/0, ticks=2390/0, in_queue=2391, util=94.47% Wear eMMC write: (g=0): rw=write, bs=(R) 32.0KiB-32.0KiB, (W) 32.0KiB-32.0KiB, (T) 32.0KiB-32.0KiB, ioeng4 verify: (g=1): rw=read, bs=(R) 32.0KiB-32.0KiB, (W) 32.0KiB-32.0KiB, (T) 32.0KiB-32.0KiB, ioeng4 fio-3.30 Starting 2 processes Jobs: 1 (f=1): write: (groupid=0, jobs=1): err= 0: pid=590: Fri Apr 29 20:17:15 2022 Description : write: IOPS=732, BW=22.9MiB/s (24.0MB/s)(14.4GiB/642435msec); 0 zone resets ... verify: (groupid=1, jobs=1): err= 0: pid=607: Fri Apr 29 20:17:15 2022 Description : read: IOPS=4812, BW=150MiB/s (158MB/s)(14.4GiB/97725msec) ... Run status group 0 (all jobs): WRITE: bw=22.9MiB/s (24.0MB/s), 22.9MiB/s-22.9MiB/s (24.0MB/s-24.0MB/s), io=14.4GiB (15.4GB),c Run status group 1 (all jobs): READ: bw=150MiB/s (158MB/s), 150MiB/s-150MiB/s (158MB/s-158MB/s), io=14.4GiB (15.4GB), run=9c Disk stats (read/write): mmcblk0: ios=58819/29449, merge=0/3732727, ticks=143387/81519893, in_queue=81663280, util=99.% ... ------------------------------- 4 ).总结 本文基于NXP i.MX8MM ARM处理器平台说明和演示了eMMC寿命磨损测试的流程,同时由于测试是线性写入,得出的结果和实际应用具体情况可能有不同,不过在实际应用中,为了最大程度的增加eMMC存储器件的寿命和可靠性,在写入数据时候最好不要无论大小数据每次都直接写入磁盘,最好使用缓存将要写入的数据累积到一定量之后,根据具体eMMC Optimal Write Size来最终写入磁盘,以尽可能减少WAF,提高磨损寿命。 ​
  • 热度 8
    2023-8-25 16:40
    1705 次阅读|
    0 个评论
    B y Toradex 胡珊逢 Toradex 自从 Linux BSP v6 开始在使用 32 位处理器的 Arm 模块如 iMX6 、 iMX6ULL 、 iMX7 上提供 mainline/upstream kernel , 部分 64 位处理器模块如 Verdin iMX8M Mini/Plus 也提供实验性支持。文章将以季度发布版本 Linux BSP V6.3.0 为例介绍如何下载和编译 mainline/upstream Linux kernel 和 U-Boot 。 Linux 下载 kernel 源码 内核源码可以从官网 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 下载。但考虑到国内网络情况, 推荐 从国内的镜像站点下载,如 https://mirrors.tuna.tsinghua.edu.cn/git/linux-stable.git 。默认下载时会获取最新的 upstream 内核版本。可根据模块上运行 Linux 的版本 checkout 到对应版本源码。在模块上的 Linux 中运行 uname 命令 , 可以看到当前版本是 6.1.37 。后面的 6.3.0 是 Toradex Linux BSP 季度发布版本。季度发布版本是经过充分的自动化和人工测试后发布的 , 可用于对应模块的生产环境。 ---------------------------------- root@apalis-imx6:~# uname -a Linux apalis-imx6 6.1.37-6.3.0+git.0f4ac6b4c5f0 #1 SMP Sat Jul 1 11:16:27 UTC 2023 armv7l armv7l armv7l GNU/Linux ---------------------------------- 在电脑上使用下面命令并 checkout 到 v6.1.37 。 ---------------------------------- $ git clone https://mirrors.tuna.tsinghua.edu.cn/git/linux-stable.git $ git checkout v6.1.37 ---------------------------------- 下载和应用补丁 mainline/upstream kernel 通常还需要一些补丁。它们可以从 meta-toradex-bsp-common 中下载, 后续 其版本也需要对应到一样的季度版本。首先打开网址 https://git.toradex.com/cgit/toradex-manifest.git/tree/bsp/pinned-tdx.xml?h=6.3.0 。结尾的 6.3.0 为对应的季度发布版本号。在页面中可以看到如下内容: ---------------------------------- ---------------------------------- 可以看到 meta-toradex-bsp-common.git 在季度发布版本 6.3.0 对应的 hash 是 f7ff10a3b560dcf4e258115da679d1f864e09837 。通常建议使用最新发布的季度版本,获得问题修复和功能完善。 因此, 下载时请修改季度发布版本号和 hash 值。 进入上面下载的 Linux 源码目录后创建 patch 文件夹,并在其中下载 meta-toradex-bsp-common , checkout 对应用版本。 ---------------------------------- $ cd linux-stable/ $ mkdir patch $ cd patch $ git clone https://git.toradex.com/cgit/meta-toradex-bsp-common.git $ cd meta-toradex-bsp-common $ git checkout f7ff10a3b560dcf4e258115da679d1f864e09837 ---------------------------------- 将 meta-toradex-bsp-common/recipes-kernel/linux/linux-toradex-mainline-git 的所有 patch 文件复制到 patch 目录下。 ---------------------------------- $ cp meta-toradex-bsp-common/recipes-kernel/linux/linux-toradex-mainline-git/*.patch ./ ---------------------------------- 在 patch 目录下使用 git am 命令给 kernel 打补丁。注意必须要以固定的顺序打补丁。补丁顺序可以参看 meta-toradex-bsp-common/recipes-kernel/linux/linux-toradex-mainline_git.bb 文件。 ---------------------------------- SRC_URI:append = " \ file://0001-thermal-imx-Update-critical-temp-threshold.patch \ file://0001-Revert-drm-panel-simple-drop-use-of-data-mapping-pro.patch \ file://0001-arm-dts-colibri-imx6-usb-dual-role-switching.patch \ file://0002-arm-dts-colibri-imx6-move-vbus-supply-to-module-leve.patch \ file://0003-arm-dts-colibri-imx6-specify-usbh_pen-gpio-being-act.patch \ file://0001-arm-dts-colibri-imx6ull-keep-peripherals-disabled.patch \ file://0002-arm-dts-colibri-imx6ull-enable-default-peripherals.patch \ file://0001-ARM-dts-colibri-imx6ull-Enable-dual-role-switching.patch \ file://0002-drivers-chipidea-disable-runtime-pm-for-imx6ul.patch \ file://0001-ARM-dts-apalis-imx6-Disable-usb-over-current.patch \ file://0002-ARM-dts-colibri-imx6-Disable-usb-over-current.patch \ file://0003-ARM-dts-colibri-imx6ull-Disable-usb-over-current.patch \ file://0004-ARM-dts-colibri-imx7-Disable-usb-over-current.patch \ file://0001-arm64-dts-imx8mm-verdin-Add-yavia-carrier-board.patch \ file://0002-arm64-dts-imx8mp-verdin-Add-yavia-carrier-board.patch \ file://0001-media-v4l2-async-fix-binding-async-subdevs-with-mult.patch \ file://0002-media-i2c-ov5640-Implement-get_mbus_config.patch \ file://0001-Revert-media-v4l2-async-Use-endpoints-in-__v4l2_asyn.patch \ " ---------------------------------- 在 patch 文件夹里执行面命令,期间不应该出现任何错误和冲突。 ---------------------------------- $ cd patch $ git am 0001-thermal-imx-Update-critical-temp-threshold.patch \ 0001-Revert-drm-panel-simple-drop-use-of-data-mapping-pro.patch \ 0001-arm-dts-colibri-imx6-usb-dual-role-switching.patch \ 0002-arm-dts-colibri-imx6-move-vbus-supply-to-module-leve.patch \ 0003-arm-dts-colibri-imx6-specify-usbh_pen-gpio-being-act.patch \ 0001-arm-dts-colibri-imx6ull-keep-peripherals-disabled.patch \ 0002-arm-dts-colibri-imx6ull-enable-default-peripherals.patch \ 0001-ARM-dts-colibri-imx6ull-Enable-dual-role-switching.patch \ 0002-drivers-chipidea-disable-runtime-pm-for-imx6ul.patch \ 0001-ARM-dts-apalis-imx6-Disable-usb-over-current.patch \ 0002-ARM-dts-colibri-imx6-Disable-usb-over-current.patch \ 0003-ARM-dts-colibri-imx6ull-Disable-usb-over-current.patch \ 0004-ARM-dts-colibri-imx7-Disable-usb-over-current.patch \ 0001-arm64-dts-imx8mm-verdin-Add-yavia-carrier-board.patch \ 0002-arm64-dts-imx8mp-verdin-Add-yavia-carrier-board.patch \ 0001-media-v4l2-async-fix-binding-async-subdevs-with-mult.patch \ 0002-media-i2c-ov5640-Implement-get_mbus_config.patch \ 0001-Revert-media-v4l2-async-Use-endpoints-in-__v4l2_asyn.patch ---------------------------------- kernel 配置 内核配置文件 .config 也可以从 Toradex Artifactory 下载,并使用对应的季度发布版本的编译文件。打开 Toradex Artifactory 网页,在左边的 Artifact Repository Browser 中点开 oe-release ,选择 Linux BSP v6 对应的 kirkstone-6.x.y 。依次打开 kirkstone-6.x.y/release/7/apalis-imx6/tdx-xwayland-upstream/tdx-reference-multimedia-image/oedeploy/ 。 release 下面一般可以选择最大序列的,这对应最新的发布版本。右击 kernel-config 下载即可。 将 kernel-config 复制到刚才下载的内核源码目录,命名为 .config ,用其作为 Linux 的默认配置。如果需要修改,后面还可以使用 make menuconfig 命令。 ---------------------------------- $ cd linux-stable/ $ mv kernel-config .config $ make olddefconfig ---------------------------------- 准备好源码、补丁和内核配置文件,接下来就可以编译了,具体方法参考 这里 。 U-Boot 下载 U-Boot 源码 首先从 https://source.denx.de/u-boot/u-boot.git 下载源码,并 checkout 到 v2022.07 版本,也是 Linux BSP v6 所使用的 U-Boot 版本。 ---------------------------------- $ git clone https://source.denx.de/u-boot/u-boot.git $ cd u-boot $ git checkout v2022.07 ---------------------------------- 下载和应用补丁 Upstream/mainline U-Boot 同样也需要相关补丁,和上面一样由 meta-toradex-bsp-common 提供。按照前面的方法在 u-boot 目录中建立 patch 文件夹后,在其中下载和 checkout 。 U-Boot 补丁位于 meta-toradex-bsp-common/recipes-bsp/u-boot/u-boot-toradex 目录下。将里面的 patch 文件复制到 u-boot/patch 目录下。 ---------------------------------- $ cd u-boot $ mkdir patch $ cd patch $ git clone https://git.toradex.com/cgit/meta-toradex-bsp-common.git $ cd meta-toradex-bsp-common $ git checkout f7ff10a3b560dcf4e258115da679d1f864e09837 $ cp meta-toradex-bsp-common/recipes-bsp/u-boot/u-boot-toradex/*.patch ./ ---------------------------------- 注意必须要以固定的顺序打补丁。补丁顺序可以参看 U-Boot meta-toradex-bsp-common/recipes-bsp/u-boot/u-boot-toradex_2022.07.bb 文件。 ---------------------------------- TDX_PATCHES = " \ file://0001-toradex-tdx-cfg-block-use-only-snprintf.patch \ file://0002-toradex-tdx-cfg-block-use-defines-for-string-length.patch \ file://0003-toradex-tdx-cfg-block-extend-assembly-version.patch \ file://0004-toradex-tdx-cfg-block-add-new-toradex-oui-range.patch \ file://0005-toradex-tdx-cfg-block-add-0068-i.mx-8m-mini-sku.patch \ file://0006-toradex-common-Remove-stale-comments-about-modules-a.patch \ file://0007-toradex-common-Use-ARRAY_SIZE-macro.patch \ file://0008-toradex-tdx-cfg-block-Cleanup-interactive-cfg-block-.patch \ file://0009-toradex-common-Remove-stale-function-declaration.patch \ file://0010-toradex-common-Remove-ifdef-usage-for-2nd-ethaddr.patch \ file://0011-toradex-tdx-cfg-block-Use-official-SKU-names.patch \ file://0012-toradex-common-Improve-product-serial-print-during-b.patch \ file://0013-configs-colibri-imx7-Enable-bootd-command.patch \ file://0001-ARM-imx8mp-verdin-imx8mp-Add-memory-size-detection.patch \ file://0001-apalis-colibri_imx6-imx6ull-_imx7-update-env-memory-.patch \ file://0001-configs-colibri-imx7-Fix-bad-block-table-in-flash-co.patch \ file://0001-colibri_imx6-fix-RALAT-and-WALAT-values.patch \ " ---------------------------------- 在 patch 文件夹里执行面 g it am 命令,期间不应该出现任何错误和冲突。 ---------------------------------- $ git am 0001-toradex-tdx-cfg-block-use-only-snprintf.patch \ 0002-toradex-tdx-cfg-block-use-defines-for-string-length.patch \ 0003-toradex-tdx-cfg-block-extend-assembly-version.patch \ 0004-toradex-tdx-cfg-block-add-new-toradex-oui-range.patch \ 0005-toradex-tdx-cfg-block-add-0068-i.mx-8m-mini-sku.patch \ 0006-toradex-common-Remove-stale-comments-about-modules-a.patch \ 0007-toradex-common-Use-ARRAY_SIZE-macro.patch \ 0008-toradex-tdx-cfg-block-Cleanup-interactive-cfg-block-.patch \ 0009-toradex-common-Remove-stale-function-declaration.patch \ 0010-toradex-common-Remove-ifdef-usage-for-2nd-ethaddr.patch \ 0011-toradex-tdx-cfg-block-Use-official-SKU-names.patch \ 0012-toradex-common-Improve-product-serial-print-during-b.patch \ 0013-configs-colibri-imx7-Enable-bootd-command.patch \ 0001-ARM-imx8mp-verdin-imx8mp-Add-memory-size-detection.patch \ 0001-apalis-colibri_imx6-imx6ull-_imx7-update-env-memory-.patch \ 0001-configs-colibri-imx7-Fix-bad-block-table-in-flash-co.patch \ 0001-colibri_imx6-fix-RALAT-and-WALAT-values.patch ---------------------------------- U-Boot 配置 对于 32 位处理器的模块,默认配置如下: l colibri_imx6_defconfig l colibri-imx6ull_defconfig l colibri-imx6ull-emmc_defconfig l colibri_imx7_defconfig l colibri_imx7_emmc_defconfig l apalis_imx6_defconfig 以 Apalis iMX6 为例 。 ---------------------------------- $ make mrproper $ make apalis_imx6_defconfig ---------------------------------- 最后编译 U-Boot 。 ---------------------------------- $ make -j$(nproc) ----------------------------------
  • 热度 11
    2023-3-29 16:45
    1860 次阅读|
    0 个评论
    这是我们两篇博客系列的第二部分。在第一部分中,您学习了 USB-C 引脚、配置通道和电源分配。 让我们继续通过您已经学到的知识分析现实世界的示例,然后我们将以分析USB-C上的数据信号来结尾。 在跳进现实案例之前,让我们快速回顾一下电阻设置以及DFP设备(主机)在连接不同电阻时检测CC引脚时可能检测到的状态: 简单的电源输送 USB-C Configuration Channel CC1 CC2 State Cable Orientation Open Open Nothing attached N/A Rp Rp Another DFP / No action N/A Rd Open Sink Attached Normal Open Rd Inverted Open Ra Powered cable without Sink attached Normal Ra Open Inverted Rd Ra Powered cable with Sink, VPA* or VPD** Normal Ra Rd Inverted Rd Rd Debug Accessory Mode Attached N/A Ra Ra Audio Adapter Accessory Mode Attached N/A *VPA - Vconn-Powered Accessory **VPD - Vconn-Powered USB Device 电源输送 - 输出示例 现在,您可以查看一个真实的工作案例 ,一个双重角色的 USB-C 端口,可以为连接设备提供电源。 Simple USB-C dual role port 本节摘自Verdin开发板,使用了TUSB321芯片来处理配置通道和VBUS中的功率切换芯片。CC连接的芯片检测线缆的方向和电源输入设备的存在(请参见上面的表格)。然后,它将检测到的状态告知给Verdin模块,该模块控制功率切换芯片。根据引脚状态,TUSB321可以宣布不同的最大输出电流级别(0.5 / 0.9A,1.5A和3A)。功率切换芯片(IC4)的电流限制需要相应调整。 The block diagram for the TUSB321 在 TUSB321 中,您可以看到 CC 引脚切换到下拉电阻,并且可配置上拉电阻。这种方式使您的设备可以用于 UFP、DFP 和 DRP 配置 ,由 PORT 引脚控制 ,并可配置以宣布其电源传递能力 ,这由 CURRENT_MODE 引脚控制。由于 TUSB321 仅使用上拉电阻来宣布端口的电源能力,因此它只能宣布最大为5V和3A(15W)的电源。对于更高的电压,需要使用高级电源传递配置芯片。 电源输送 - 输入示例 您还会发现查看电源汇输入设备示例很有帮助。 USB-C power sink 本节内容适用于我们的Dahlia 载板,该板具有一个能够进行总线通信的芯片(IC23)。因此,这种解决方案可以协商获得具有高于5V和大于3A的电流的功率配置。连接到CC引脚的芯片具有内置的EPROM,其中包含三个配置。这些信息通过CC总线进行通信,并由可用匹配配置的电源输出设备使用。当两个设备都同意一个相互可用的配置时,VBUS被切换,设备可以从总线上开始消耗电力。 原理图还提供了一个选配的充电器检测器芯片(IC22)。通过检查D+和D-数据信号是否短路在一起,IC22可以检测到传统充电器。如果USB电源输送协商成功(IC23)或接入USB Type-A充电器(IC22),则启用总线电源(IC20),并且载板可以开始启动模块。如果未检测到充电器或USB-C电源输送端口,则系统将不会启动,因为不被允许从端口吸取超过5V / 100mA的电流。 数据信号 USB-C 接口相比以前的接口,具有更多的数据信号引脚,这一点值得注意。 作为回顾,让我们来看看 USB-C 可用的数据信号引脚: 两条 Super-Speed 信号通道——TX 和 RX 对。 对称的 D+ 和 D- 信号对(只在设备端冗余)。 两个 Sideband Use(SBU)引脚,用于其他模式下的特殊功能。 USB 2.0 Mode USB 2.0的D+/D-引脚在插座上是对称的,这意味着不需要识别插入的电缆的方向,也不需要多路复用器来切换信号。 USB 3.X Super-Speed Mode 为了充分利用USB-C的 Super-Speed 信号功能,必须使用多路复用器以及使用CC引脚进行正确的电缆方向检测,如第一篇博客所解释的那样,以便多路复用器能够得到正确的控制。这是在使用双路或单路配置时确保使用正确的通道所必需的。 现实情况中的案例 让我们看看实际的案例,以了解它们是如何联系在一起的; High-Speed UFP 使用USB-C的最简单的配置是作为上行面向的高速端口设备。 USB-C Client 使用CC引脚的下拉电阻和D+ / D-引脚,所示电路是Micro Type-B连接器的简单替代品,完全符合USB-C标准。它可以用于鼠标和闪存驱动器等设备。 High-Speed DRD 可以使用下图所示的配置替换OTG,该配置来自我们的Verdin开发板,在分析USB-C电源输出源时曾在本博客文章中出现过。 High-Speed DRD CC引脚和已经解释过的检测过程用于定义设备的角色,即作为DFP或UFP,以及 D+和D-引脚被用作 Data Signals 和之前示例相同。 在这里使用没有 Super-Speed 引脚的连接器是一个好的做法,否则会可以大大增加引脚密度,增加PCB布线的工作量。 Super-Speed DRD 在我们的Apalis 载板参考设计中,您可以看到USB-C的更高级用途。 USB-C Super-Speed 当向您的USB-C应用添加 Super-Speed 功能时,如前所述,所需的多路复用器用于将 Super-Speed 信号连接到电缆的正确一侧,这可以简单地由同一个 TUSB321芯片控制。 在这个设计中,使用了一个技巧来简化布线过程:CC引脚被反转,因此用于控制多路复用器的信号也被反转,简化了多路复用器周围的布线。 笔记本电脑示例 现在,让我们来看一个来自笔记本电脑应用的完整功能示例。 Laptop USB-C implementation Source:https://www.nxp.com/docs/en/data-sheet/PTN5100.pdf 在这个设置中,笔记本可以充电或为UFP设备提供电源,包括通过专用IC(PTN5100)进行电源协商和可同时使用的显示端口功能。请注意矩阵切换器IC,它可以连接来自CPU图形部分的视频信号和南桥的 Super-Speed 信号。 让我们更仔细地看一下使用USB-C和显示端口配置的可能性。您可以在下面的图像中看到其中一些选项: b Display port configurations 重申一下,DisplayPort最多可以使用4个通道,但也可以使用1个或2个通道。每个用于 super-speed 信号的双向通道(TX/RX对)可以容纳2个DisplayPort通道,因为它的通道是单向的。因此,如果您只使用2个DisplayPort通道,则可以在剩余的双向通道中与 super-speed 信号结合使用。这也意味着在DisplayPort中使用高分辨率(使用4个通道)时,您只能使用 D+和D-引脚的 USB 2.0。 陷阱 让我们看看一些错误,这些错误可以通过严格遵循标准来避免。 Rasp Pi 4 USB-C circuit Source:https://datasheets.raspberrypi.com/rpi4/raspberry-pi-4-reduced-schematics.pdf 在树莓派4的第一个版本中,CC引脚共用了同一个Rd电阻,这导致它们被短接在一起。当使用被动线缆(无标记芯片)连接时,DFP设备只能在一个CC引脚上检测到Rd,因为只有CC1 在线缆中被连接,这导致UFP设备可以正常工作。对照表格进行查看: CC1 CC2 State Cable Orientation Rd Open Sink Attached Normal Open Rd Inverted 然而,让我们看看当它连接到一个在 CC2 两端都有Ra电阻的主动USB-C线缆时会发生什么: Resultant configuration with marker cable 在DFP设备端,CC2引脚检测到Ra电阻,CC1引脚检测到并联于电缆另一端的Ra电阻,由于Raspberry Pi板上的CC1和CC2引脚短接而引入的Rd电阻。这种并联配置导致形成了836欧姆的电阻,其在Ra电阻的允许值范围内。如果你仔细检查一下表格,你会发现这导致了检测到音频适配器的状态,使板子无法获得电源。 CC1 CC2 State Cable Orientation Ra Ra Audio Adapter Accessory Mode Attached N/A 通过介绍基本的USB-C概念,你现在了解了它所带来的可能性、限制以及使用其资源的基本设置。 更详细的信息可通过下面的链接获得,如果你需要设计载板方面的帮助,欢迎给我们留言。 参考链接 Official USB Specifications https://www.usb.org/documents Wikipedia articles https://en.wikipedia.org/wiki/USB-C https://en.wikipedia.org/wiki/USB_3.0 https://en.wikipedia.org/wiki/USB Short USB-C and Power Delivery Guidehttps://microchipdeveloper.com/usb:type-c Easy to read USB 2.0 - the basic about enumeration and the protocol https://www.beyondlogic.org/usbnutshell/usb1.shtml Toradex Design Guides https://docs.toradex.cn/108140-verdin-carrier-board-design-guide.pdf https://docs.toradex.cn/101123-apalis-arm-carrier-board-design-guide.pdf
  • 热度 2
    2023-2-20 13:09
    1765 次阅读|
    0 个评论
    B y Toradex Peter Lischer ​ 本文是双篇文章系列的第一部分,旨在帮助您理解并实现在您的下一版电路板设计中使用USB-C。您将学习以下内容: USB-C端口的引脚及其在不同配置中的用途 USB-C电缆可以随意更换方向,无论是正面还是反面 同一设备如何在主机和客户端之间切换 USB-C的供电方式 DRP、DRD、UFP和DFP等新术语 主动和被动USB-C电缆之间的区别以及适配器电缆的工作原理 现在从以下内容开始。 USB 标准和连接器 USB最初发布于1996年,旨在标准化外围设备与个人计算机之间的连接,目前已经经历了四个主要版本:USB 1.x、USB 2.0、USB 3.x和USB4。自那时以来,该标准替换了不同的接口,例如串行和并行端口。它确保设备具有自我配置和供电能力等有用功能。在USB标准的演变过程中,使用了不同的连接器,如下表所示: USB连接器与USB标准 - 不同标准及每种连接器引入时间 USB-C 连接器 如表所示,USB-C似乎只是标准中的一种连接器。然而,请注意它替代了从USB 3.2开始的所有其他连接器 此外,请注意在USB-C之前的连接器被分别应用于主机端(type A 和其 mini/micro 变体连接器)和客户端(type B 和其 mini/micro 变体连接器)。因此,USB-C连接器的一个有趣特点是它在客户端和主机端都可以使用。 在USB 2.0版本之前,标准中的连接器有四个引脚:Vbus、D-、D+和GND。USB 3.0版本引入了SuperSpeed连接器,它有五个额外的引脚:SSRX-、SSRX+、SSTX-、SSRX+和GND_DRAIN。连接器因而被修改以适应额外的引脚。虽然 type-A 连接器很容易修改以适应五个以上的引脚,但type-B 连接器需要进行一些微小的改进。而Micro-B连接器变成了一个令人困惑且不友好的连接器。 参考图片 Type - A https://en.wikipedia.org/wiki/USB_3.0#/media/File:Connector_USB_3_IMGP6024_wp.jpg Type - B https://4.bp.blogspot.com/-2IBVZ1_H6f8/VDQThGSgCHI/AAAAAAAABD4/egZs7BXvE7o/s1600/etymmm.jpg Micro - B https://m.media-amazon.com/images/I/61qynPKsvvL._AC_SL1500_.jpg USB-C连接器的推出是为了解决用户体验问题,也成为第一个翻转对称的标准USB电缆。 它有 24 个引脚: 相比之前的版本,USB-C 有 2条 SuperSpeed 信号通道,而之前的版本只有1条。 额外的翻转对称电源引脚。 对称的D+和D-信号对(在设备侧是冗余的,电缆只使用一个D+和一个D-)。 新的信号:2个用于配置控制的引脚和2个用于辅助通信的引脚。 引脚用途 USB-C 连接器仍然可以用于默认的 Low/Full/High-Speed (2.0)连接,使用默认的 D+ 和 D- 数据信号对。 它也可以用于 SuperSpeed (3.x)连接,使用 high-speed 通道和配置控制引脚。 USB-C 还可以作为 电源传输接口(充电器) 使用,其中使用 VBUS、GND 和配置控制。 同时,它的另一模式还可用作显示端口。通过将 superspeed 通道用作 Display Port 并使用 SBU 作为配置显示器的辅助通道,最多可以使用 4 条数据线。在此模式中,仍可以使用 D+ 和 D- 引脚进行 USB 2.0 连接。 它还可以作为 音频适配器配件 使用,支持立体声耳机和麦克风。 术语 在 USB-C 的文档中,可以看到之前标准中没有广泛使用的新术语。以下是这些新术语: DFP : 下行面向端口(Downstream Facing Port)- USB主机端口和电源输出。 UFP : 上行面向端口(Upstream Facing Port)- USB客户端和电源输入。 DRD : 双重角色设备(Dual Role Device)- 可以充当主机或客户端口(取代OTG)。 DRP : 双重角色电源(Dual Role Power)- 可以作为电源输出者或电源输入者运行。 DFP和UFP这两个术语很容易理解,而DRD和DRP这两个不那么容易理解的术语是为了符合USB-C标准中两种独立角色的分类而故意创建的。 关于数据方向 - 主机和客户端。 关于电源方向 - 电源输入和电源输出。 因此,同一设备可以同时作为客户端(数据方向)和电源输出端(电源方向)。例如,某些扩展坞站即是 USB 客户端,又可作为笔记本电脑的充电电源。 控制通道 在USB-C引入的新引脚中,配置引脚 CC1和CC2是特别重要的,因为它们有三个基本用途: 电缆方向检测: 由于USB-C电缆具有翻转对称性,所以任何一面都可以插入。因此,检测方向对于设备能够复用必要的引脚进行正确通信显得非常重要。请记住,连接器中并不是所有引脚都是对称的。 角色检测: 在之前的标准中,通过使用不同的连接器来进行主机端(type-A)和客户端(type-B)之间的通信,从而可以轻松确定通信中的角色。这意味着,通过合规的电缆,不可能将两个主机连接在一起。 对于 USB-C,连接器的形状不再防止连接两个主机。角色检测功能确保在这种情况下不会造成任何破坏。在 Dual Role Devices 相连接时,角色检测也非常重要,以确定哪个设备是主机,哪个是客户端。 电源检测与协商: 支持不同的电源配置,客户端和主机需要就配置电源分配达成共识,这包括不同的VBus电压和最大电流。 这通过下图中展示的设置来实现: 线缆方向和角色识别设置 在上行设备中,CC1和CC2引脚有下拉电阻。 在下行设备中,CC1和CC2引脚有上拉电阻。 在被动电缆中,只有一对CC引脚被使用。 通过检测 CC1 和 CC2 引脚的电压,双方都可以轻松地确定所有参数: 角色检测 – 是否有电压变化? 这意味着一侧是UFP(上行面向端口),另一侧是DFP(下行面向端口)。如果UFP设备没有检测到电压变化,则表示连接中没有DFP。如果DFP没有检测到电压变化,则表示另一端没有UFP。如果另一端连接的是同一类型的设备,也不会出现问题,因为此时的电压感应阶段发生在电源切换之前,这一点将在本博客后面介绍。 线缆方向 – 哪个引脚电压变化? 由于电缆在CC引脚之间只有单个连接,因而只有一个引脚的电压会变化,这确定了每一端的电缆方向。 电源检测 - 电压是多少? 通过使用不同值的上拉电阻,根据CC引脚上的最终电压值 ,DFP设备可以轻松地向UFP设备宣告电源传输能力。 后续将介绍详细信息 。 配置通道被用作双向通信总线,用于设备之间的高级电源协商。主动电缆具有标记芯片,可以通过CC总线通信,以了解电缆在电源传输方面的能力。 稍后将提供详细信息 。 另一个CC引脚可以用来为电缆内部存在的任何芯片提供电源。这些芯片可以是标记器、信号复制器或适配器。这些有源电缆有一个拉下的Ra电阻,并且使用 VCONN电压进行供电,固定为最大5V-1W。根据电缆的方向,两个CC引脚都可以切换到VCONN - 另一个引脚仍然可以用于通信总线。切换是通过VCONN控制信号完成的,该信号将CC1或CC2连接到电源。该方案可以在以下图表中看到。 USB-C 的一个关键方面是 VBUS 不总是通电。与以前的 USB 标准不同,这些标准的 VBUS 总是通电的,而 USB-C 上的 VBUS 仅在电源输出端通过观察 CC 引脚的电压值,检测到连接的电源输入端后才会开启。 支持的配置 了解了有关配置通道的信息后,您可以在一些情况下看到它是如何运作的: DFP 连接 UFP 在这种设置中,当两个设备连接在一起时,CC1上的电压下降。然后设备的USB控制器切换VBUS源,使得电源输入设备可以被供电。此外,控制器检测到电缆没有翻转,并且CC2引脚连接到VCONN,以为主动电缆提供电源。在这种切换后,接收方设备可以请求枚举,就像在以前的USB版本中一样。 DRP 连接 UFP DRP可以被配置为作为DFP工作。在这种情况下,CC引脚连接到上拉电阻。在检测到CC1电压变化后,设备的USB控制器可以激活VBUS源和CC2处的VCONN。 DFP 连接 DRP DRP(双角色端口)还可以配置为作为UFP。在这种情况下,CC引脚连接到下拉电阻器。在检测到CC电压变化后,DRP设备的USB控制器可以切换VBUS输入,使其能够由DFP设备供电。 DRP 连接 DRP 在这个配置中,其中一个设备在CC引脚上启用了下拉电阻,而另一个设备在CC引脚上启用了上拉电阻。作为电源输出的设备然后激活VBUS输出,而作为电源输入的设备则激活VBUS输入。 错误的连接 - 由于USB-C连接器在电缆的两端都是相同的,有可能会不经意地将电源输入设备和电源输入设备,或者电源输出设备和电源输出设备连接在一起。在两种情况下,通信都无法进行,但不会对设备造成损坏。 电源输出端连接电源输出端 由于CC引脚没有电压变化,因此VBUS电源未被激活。 电源输入端连接电源输入端 没有 VBUS 输出,因此不存在电压输出源冲突的可能。 传统设备 传统电源输入端连接到 USB-C 电源输出端 适配器图片参考链接: https://www.hardware-wallets.net/wp-content/uploads/2017/05/ledger-otg-kit-adapters-large-360x181.png 为了提供与前几代 UFP 设备的兼容性,可以使用一个简单的适配器。 此适配器需要在 CC 信号上使用下拉电阻,以便 USB-C 源设备可以检测适配器并启用 VBUS 电源。 连接到 USB-C 电源输入端的传统电源 相反的情况也是可行的:USB-C 电源输入设备可以使用 type-A 转 type-C 电缆连接到前几代的电源输出设备。 它需要在 CC 线内部有一个上拉电阻,以便 USB-C 设备可以检测其 CC 引脚上的电压变化。 供电 USB-C 提供多种供电配置。 前三个级别向后兼容非 USB-C 设备(例如,使用 Type-A 连接器)。 向后兼容的 Power Delivery 电源模式 CC 用途 检测 电压 最大电流 最大功率 默认 USB 2.0 DFP 端使用 56kΩ 上拉电阻或者 Type-A 适配器 需要通过 USB 2.0 信号进行 USB 枚举。没有枚举时,只允许 100 mA(休眠模式下 2.5mA ) 5 V 0.5 A 2.5 W 默认 USB 3.x DFP 端使用 56kΩ 上拉电阻或者 Type-A 适配器 需要通过 USB 信号进行 USB 枚举。没有枚举时,只允许 150 mA 5 V 0.9 A 4.5 W USB BC 1.2 DFP 端使用 56kΩ 上拉电阻或者 Type-A 适配器 通过测量 USB 2.0 信号的 D+ 和 D- 线之间的电阻来检测电池充电器主机是否存在 5 V 1.5 A 7.5 W Type-A 转 type-C 电缆提供向后兼容的供电配置。 请注意,USB 枚举过程是必需的 ,USB BC 1.2 模式除外 ,对于电池充电器,放置一个只为枚举的芯片是不现实的。 在这种情况下,通过电源适配器上的 D+ 和 D- 之间的短连接向电源输入设备宣布电池充电器的存在。 这允许在不进行 USB 枚举的情况下输出最高 1.5A 的电流。 简单 Power Delivery 电源模式 CC 用途 检测 电压 最大电流 最大功率 USB-C 5V/1.5A DFP 端使用 22kΩ上拉电阻 UFP检测CC脚的上拉电阻值 5 V 1.5 A 7.5 W USB-C 5V/3A DFP 端使用 10kΩ上拉电阻 UFP检测CC脚的上拉电阻值 5 V 3 A 15 W USB-C 引入了两种简单的供电模式,只需要在 DFP 端使用不同值的上拉电阻。 这些模式仅适用于电缆两端都是 USB-C 连接器。 它不适用于传统的 type-A 转 type-C适配器电缆。 高级 Power Delivery 电源模式 CC 用途 检测 电压 最大电流 最大功率 USB PD Bus DFP、UFP 和标记电缆之间的总线通信 5-20 V 5 A 100 W USB PD Extended Power Range Bus DFP、UFP 和标记电缆之间的总线通信 5-48 V 5 A 240 W 使用 CC 通道作为通信总线来协商电压和电流,可以获得更高功率。如果电流高于 3A 或电压高于 20V,则电缆需要标记芯片进行通信并允许这些更高功率的模式。被动电缆仅支持最高 60W (3A/20V)。 我们可以用下图来总结上述表: 可以使用不同值的电阻宣布最高为 15W (5V/3A) 的供电能力 - 仅使用 5V 电压。 更高的电压和功率需要通过配置通道总线协商。高于 3A 的电流需要内部带有标记芯片的电缆。 您现在了解 USB-C 的基本原理、角色定义和功率传输。 请继续关注我们的下一篇博客,我们将在其中提供真实示例并讨论 USB-C 中的数据信号。