企业官网建设流程全解析

简介：本资源为MTK 6575平台USB驱动的完整源码包，面向嵌入式Linux驱动开发者、Android底层工程师及芯片级固件调试人员，聚焦移动设备USB通信协议栈的实现与调优。压缩包含42个文件，其中21个头文件（.h）定义USB主机/设备模式、OTG状态机、ACM/MS/Video等类驱动接口与数据结构；20个C源文件（.c）覆盖枚举流程、端点管理、中断传输、电源状态切换及错误恢复等核心逻辑；另含1个txt文本提供外部链接信息。整体153KB，轻量但高度内聚，目录按功能模块划分清晰，便于定向分析与移植适配。目前已有160人学习下载，开发者可直接基于该源码理解MTK USB协议栈分层设计思想，复用关键状态机与回调框架，快速定位枚举失败、传输卡顿或休眠唤醒异常等问题，亦可作为MTK新平台驱动开发的参考基线。

1. MTK6575 USB 驱动源码包到底在解决什么问题？不是刷机工具，而是嵌入式底层 USB Host/OTG 能力的“根目录”

你手头有一份名为usb.rar_mt6575_mtk_mtk 6575 usb_mtk source_mtk usb的压缩包，解压后看到一堆.c、.h、Makefile和Android.mk文件，夹杂着preloader、lk、kernel等目录——它不是一个点几下就能用的 GUI 刷机工具，也不是拿来直接烧进手机就能升级的固件。它是一套MTK6575 平台在 Android 4.x 时代（2012–2014）真实量产项目中使用的 USB 子系统源码集合，覆盖从 Preloader 阶段的 USB 下载协议握手、LK（Little Kernel）阶段的 USB Device 模式初始化，到 Linux kernel 层的mtk-usb主机控制器驱动（EHCI/OHCI）、OTG 双角色切换逻辑、以及配套的 gadget（如usb_serial、usb_mass_storage）和 host class（如usb-storage、usb-serial）驱动。它的核心价值在于：让你能真正看懂、改懂、甚至重写 MTK6575 上 USB Host 如何枚举 U 盘、OTG 如何在 Device/Host 间切换、USB Serial 如何被/dev/ttyUSB0正确暴露——而不是靠adb devices是否显示来玄学判断。适合正在维护老旧工控终端、POS 机、车载记录仪等基于 MTK6575 的嵌入式设备的工程师；也适合想逆向理解 MTK USB 架构演进（从 6575 → 6580 → 6735 → 6765）的驱动开发者。如果你正被mtk无法连接设备、usb抓包看不到 handshake、otg线插上没反应这类问题卡住，这份源码就是你该打开的第一扇门。

2. 从源码结构到编译路径：看清mtk6575_usb在整个 BSP 中的位置与依赖链

MTK6575 的 USB 支持横跨 BootROM → Preloader → LK → Kernel 四层，而这份usb.rar恰好是这四层中可修改、可调试、可复现的关键驱动层集合。它不包含 BootROM（固化不可改），但完整覆盖了后续所有软件可控环节。理解其组织方式，是避免“改了 kernel 驱动却忘了 LK 初始化”的前提。

2.1 源码包典型目录结构解析：为什么preloader和lk目录不能删？

解压后你会看到类似如下结构（实际命名可能略有差异，但逻辑一致）：

usb/ ├── preloader/ # Preloader 阶段 USB 下载模式（DA Download Agent）入口 │ ├── usb_dl.c # 实现 USB 协议栈最简版：SETUP/IN/OUT token 解析、EP0 控制传输 │ └── usb_hw.h # 直接操作 USB PHY 寄存器（如 USB_PHY_CON0/1） ├── lk/ # Little Kernel 阶段：USB Device 模式（ADB/MassStorage）启动 │ ├── app/usb/ # ADB/Gadget 相关逻辑 │ │ ├── usb_device.c # device descriptor 构造、ep0 handler 注册 │ │ └── usb_serial.c # CDC ACM class 实现，映射到 /dev/ttyGS0 │ └── platform/mt6575/usb.c # USB PHY 初始化、VBUS 检测、ID pin 读取（决定 Device/Host） ├── kernel/ # Linux Kernel 3.4.x 驱动（MTK 定制版） │ ├── drivers/usb/ # 核心驱动 │ │ ├── host/ # Host 控制器驱动（关键！） │ │ │ ├── ehci-mtk.c # MTK 自研 EHCI Host 控制器驱动（非标准 OHCI/EHCI） │ │ │ └── ohci-mtk.c # 备用 OHCI 驱动（部分 6575 工程用） │ │ ├── phy/ # USB PHY 抽象层 │ │ │ └── phy-mtk-usb.c # 统一管理 USB PHY 供电、时钟、reset │ │ └── gadget/ # Device 模式功能 │ │ ├── f_serial.c # CDC ACM 功能（串口） │ │ └── f_mass_storage.c # U 盘功能 │ └── include/linux/usb/mtk.h # MTK 特有宏定义、struct（如 mtk_usb_phy） └── tools/ # 辅助脚本（非必需但极有用） └── usb_download.py # Python 脚本：模拟 DA 协议，向 Preloader 发送下载命令（用于验证 USB 下载通路）

提示：preloader/usb_dl.c是整个 USB 下载链的起点。它不依赖任何 OS，纯裸机汇编+少量 C，只做最基础的 USB token 响应。如果这里出错，mtk preloader tool就根本连不上——此时mtk无法连接设备的根因就在这里，而非电脑端驱动。

2.2 编译依赖链：为什么改完ehci-mtk.c还要重新编译 LK？

MTK6575 的 USB 初始化是严格分阶段传递状态的：

1. Preloader 阶段：检测 VBUS（电源）和 ID pin（OTG 角色），设置 USB PHY 为 Device 模式（默认），并进入等待 DA 协议握手状态；
2. LK 阶段：读取 Preloader 传来的 USB 状态（如usb_mode = USB_MODE_DEVICE），初始化 USB Device controller，启动 gadget（如 ADB）；
3. Kernel 阶段：LK 会将 USB Device controller 的寄存器地址、中断号等信息通过 ATAG 或 DTB 传递给 kernel；kernel 的ehci-mtk.c则负责初始化 Host controller，并复位 USB PHY——注意：这个复位会清空 Preloader/LK 设置的 Device 模式！所以必须由 kernel 驱动再次根据 OTG ID pin 状态，重新配置 PHY 为 Host 或 Device。

因此，修改ehci-mtk.c后，必须确保lk/platform/mt6575/usb.c中的 OTG 状态读取逻辑与 kernel 保持一致。常见翻车点：LK 读 ID pin 为 Device，kernel 却因 GPIO 配置错误读成 Host，结果 USB 设备插上无反应——现象是lsusb看不到设备，dmesg | grep usb显示mtk-ehci 101c0000.usb: can't get phy。

2.3 最小可验证编译命令：用make -C kernel/快速定位驱动加载失败点

你不需要编译整个 Android 系统。针对 USB 驱动验证，只需编译 kernel 模块并手动 insmod：

# 进入 kernel 目录（假设已配置好 ARCH=arm CROSS_COMPILE=arm-linux-androideabi-） cd usb/kernel/ # 编译 USB Host 驱动为模块（非内置） make -C /path/to/your/kernel/source M=$(pwd)/drivers/usb/host modules # 输出：ehci-mtk.ko, ohci-mtk.ko, usbcore.ko（若未内置） # 检查模块依赖 modinfo ehci-mtk.ko # 输出应含：depends: usbcore,phy-mtk-usb # 推送到目标板（需 root） adb push ehci-mtk.ko /data/local/tmp/ adb shell "insmod /data/local/tmp/ehci-mtk.ko" # 观察 dmesg adb shell "dmesg | tail -20" # 成功应见：[ 12.345678] mtk-ehci 101c0000.usb: MTK EHCI Host Controller # 失败则看：[ 12.345678] ehci-mtk: probe of 101c0000.usb failed with error -22

参数说明：-C /path/to/your/kernel/source指向你实际的 kernel 源码树（如kernel-3.4），M=$(pwd)/drivers/usb/host告诉 make 只编译当前目录下的模块。error -22通常意味着 platform device 注册失败（DTB 中usb@101c0000节点缺失或 compatible 字符串不匹配），而非驱动代码本身错误。

3. USB Host 驱动深度剖析：ehci-mtk.c的三个核心寄存器操作与 PHY 同步机制

MTK6575 的 USB Host 控制器并非标准 EHCI，而是 MTK 自研的兼容 EHCI 协议的 IP Block。其驱动ehci-mtk.c的关键不在协议栈实现，而在如何与 USB PHY 硬件协同工作。跳过 PHY，ehci-mtk.c就是废纸一张。

3.1ehci_mtk_power_on()：不是简单 enable clock，而是三步硬件握手

标准 EHCI 驱动调用clk_prepare_enable()即可，但ehci-mtk.c的ehci_mtk_power_on()包含不可省略的三步：

// drivers/usb/host/ehci-mtk.c static int ehci_mtk_power_on(struct usb_hcd *hcd) { struct ehci_hcd *ehci = hcd_to_ehci(hcd); struct mtk_usb_phy *phy = dev_get_drvdata(ehci->hcd.self.controller->parent); // Step 1: Enable USB PHY power & clock (via MTK's PMIC or syscon) mtk_usb_phy_power_on(phy); // 写 PMIC 寄存器，如 MT6323 的 USB_VBUS_EN // Step 2: Wait for PHY stable (critical! 10ms minimum) udelay(10000); // Step 3: Reset EHCI controller AND PHY together (MTK requirement) // 注意：这里 reset 信号同时作用于 EHCI IP 和 USB PHY reset_control_assert(ehci->reset); udelay(1000); reset_control_deassert(ehci->reset); udelay(10000); // PHY 需要更长恢复时间 return 0; }

逻辑说明：MTK6575 的 USB PHY 与 EHCI controller 共享 reset line。如果只 reset controller 不 reset PHY，PHY 内部状态机（如 PLL 锁定）可能未同步，导致ehci-mtk初始化时读取CAPLENGTH寄存器返回 0x00 —— 这就是error -22的真实原因。udelay(10000)不是玄学，是 datasheet 明确要求的 PHY lock time。

3.2ehci_mtk_start_port_reset()：OTG 角色切换的物理层开关

当插入 U 盘时，ehci-mtk需触发 port reset。但 MTK6575 的 reset 逻辑特殊：

// drivers/usb/host/ehci-mtk.c static void ehci_mtk_start_port_reset(struct ehci_hcd *ehci, int portnum) { u32 __iomem *reg = ehci->regs; u32 temp; // 标准 EHCI：写 PORTSC 中 PORT_RESET bit temp = readl(&reg->port_status[portnum]); temp |= PORT_RESET; writel(temp, &reg->port_status[portnum]); // MTK 扩展：必须同时控制 PHY 的 RESET_N pin // 通过 platform data 获取 PHY handle if (ehci->phy) { // 强制 PHY 进入 Host 模式 reset phy_reset(ehci->phy); // 调用 phy-mtk-usb.c 中的 reset 函数 } }

参数说明：phy_reset()会操作USB_PHY_CON0寄存器（地址0x10000A00），将 bit[1:0]（PHY_MODE）设为2'b10（Host mode），并 toggle bit[8]（RESET_N）。若此处 PHY_MODE 未设对，即使 EHCI controller 工作正常，U 盘也无法被枚举——lsusb空空如也，dmesg却显示new high-speed USB device，这是典型的 PHY 模式错配。

3.3ehci_mtk_hub_control()：拦截 SET_DESCRIPTOR，绕过 MTK 的 USB Descriptor Cache Bug

MTK6575 的 USB Host controller 存在一个硬件 bug：当设备发送SET_DESCRIPTOR请求时，controller 会错误地 cache descriptor 并返回旧数据。ehci-mtk.c通过在 hub control 中硬编码拦截：

// drivers/usb/host/ehci-mtk.c static int ehci_mtk_hub_control( struct usb_hcd *hcd, u16 typeReq, u16 wValue, u16 wIndex, char *buf, u16 wLength) { struct ehci_hcd *ehci = hcd_to_ehci(hcd); // MTK workaround: bypass cache for SET_DESCRIPTOR if ((typeReq & USB_RECIP_MASK) == USB_RECIP_DEVICE && (typeReq & USB_TYPE_MASK) == USB_TYPE_STANDARD && (wValue >> 8) == USB_DT_DEVICE) { // 强制走 PIO path，不走 DMA cache return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength); } return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength); }

逻辑说明：这个 patch 直接修复了usb-storage驱动加载时因 descriptor 读取错误导致的device not accepting address错误。没有它，U 盘可能被识别为Unknown device，dmesg显示usb 1-1: device descriptor read/64, error -71（STALL）。此 bug 在 MTK 官方mtk完整驱动.zip中已被修复，但很多第三方mtk6575_usb包遗漏了此补丁。

4. OTG 双角色切换实战：从id-pin检测到gadget/host模式动态加载

MTK6575 的 OTG 不是 Linux standard OTG（如dwc2），而是基于 GPIO ID pin 的简单状态机。lk/platform/mt6575/usb.c和kernel/drivers/usb/phy/phy-mtk-usb.c共同完成切换，但kernel 层必须接管最终决策权。

4.1 ID Pin 检测：LK 读值只是参考，kernel 才是裁判

LK 中的检测非常朴素：

// lk/platform/mt6575/usb.c int mt_usb_get_id(void) { // 读 GPIO21（典型 ID pin），高电平=Host，低电平=Device return gpio_get_value(GPIO21); }

但问题在于：GPIO21 可能受 PCB layout 影响（如长走线导致浮空），LK 读取一次就定论。而 kernel 驱动会持续监控：

// kernel/drivers/usb/phy/phy-mtk-usb.c static irqreturn_t mtk_usb_id_irq(int irq, void *data) { struct mtk_usb_phy *phy = data; int id_state = gpio_get_value_cansleep(phy->id_gpio); // debounce：连续 3 次读取相同值才确认 if (id_state == phy->last_id_state) { phy->debounce_cnt++; if (phy->debounce_cnt >= 3) { phy->id_state = id_state; schedule_work(&phy->otg_work); // 触发模式切换 } } else { phy->debounce_cnt = 0; phy->last_id_state = id_state; } return IRQ_HANDLED; }

参数说明：gpio_get_value_cansleep()允许在中断上下文安全读取 GPIO；debounce_cnt防抖是硬性要求，否则插拔 OTG 线时会频繁切换模式，导致usb-storage驱动反复加载卸载，U 盘文件系统损坏。

4.2 动态加载gadget或host：modprobe不是终点，configfs才是未来

MTK6575 原生支持两种模式加载：

• Host 模式：modprobe ehci-mtk+modprobe usb-storage
• Device 模式：modprobe g_serial（CDC ACM）或modprobe g_mass_storage（U 盘）

但g_mass_storage有个致命缺陷：它需要指定 backing file（如/dev/mmcblk0p1），且不支持动态挂载。现代做法是用configfs：

# 创建 configfs 实例 mkdir /config mount -t configfs none /config # 创建 USB Device 配置 mkdir /config/usb_gadget/mygadget cd /config/usb_gadget/mygadget # 设置 Vendor/Product ID echo 0x0525 > idVendor # NetChip echo 0xa4a1 > idProduct # Linux CDC Composite # 启用 Mass Storage 功能 mkdir functions/mass_storage.usb0 echo /dev/mmcblk0p1 > functions/mass_storage.usb0/lun.0/file ln -s functions/mass_storage.usb0 configs/c.1/ # 绑定到 UDC（USB Device Controller） echo mt_usb > UDC

逻辑说明：UDC文件写入mt_usb会触发phy-mtk-usb.c中的mtk_usb_vbus_draw()，从而拉高 VBUS（模拟 Host 供电），完成 Device 模式激活。configfs方式比g_mass_storage更灵活，支持热插拔 LUN，且无需重启驱动。

4.3 验证 OTG 切换：用getprop和cat /sys/class/udc/*/state交叉确认

不要只信lsusb：

# 查看当前 USB 角色（LK 传来的初始值） getprop sys.usb.config # 输出：adb,mass_storage 或 none # 查看 kernel 实际 UDC 状态 cat /sys/class/udc/*/state # 输出：configured（Device 模式运行中）或 disabled # 查看 Host controller 状态 cat /sys/bus/platform/drivers/ehci-mtk/101c0000.usb/state # 输出：bound（已绑定）或 offline # 关键交叉验证：当 OTG 线插入，两者应互斥 # Device 模式 active 时，/sys/class/udc/* 应为 configured，而 /sys/bus/platform/drivers/ehci-mtk/* 应为 offline # Host 模式 active 时，反之亦然

提示：如果getprop sys.usb.config显示adb,mass_storage，但/sys/class/udc/*/state是disabled，说明 kernel 层 OTG 状态机未触发，问题在phy-mtk-usb.c的 ID pin 中断或 debounce 逻辑。

5. 避坑指南：MTK6575 USB 开发中 4 个血泪经验总结

这些坑，90% 的工程师都在mtk无法连接设备或usb抓包看不到 handshake时踩过。它们不写在 datasheet 里，只藏在dmesg的第 37 行和git blame的提交注释中。

5.1 现象：dmesg显示mtk-ehci 101c0000.usb: can't get phy，lsusb为空

原因：ehci-mtk.c的platform_get_resource()未能获取到phyresource。根源是 DTS（Device Tree）中usb@101c0000节点缺少phys = <&usbphy>引用，或usbphy节点本身未正确定义#phy-cells。
解决：检查 DTS 文件，确保：

&usbphy { #phy-cells = <0>; status = "okay"; }; &usb { phys = <&usbphy>; phy-names = "usb"; status = "okay"; };

注意：MTK6575 的 DTS 中usbphy节点名可能是usb_phy或mt_usb_phy，需与phy-mtk-usb.c中of_match_table的compatible字符串完全一致。

5.2 现象：U 盘插入后dmesg显示new high-speed USB device number 2 using mtk-ehci，但lsusb -v读 descriptor 失败，报error -71

原因：USB PHY 的SQU（Signal Quality）寄存器未正确配置，导致高速信号眼图闭合。MTK6575 的USB_PHY_CON1（地址0x10000A04）bit[15:12]（TX_PREEMPHASIS）和 bit[11:8]（TX_SWING）需根据 PCB 阻抗微调。
解决：在phy-mtk-usb.c的mtk_usb_phy_init()中添加：

// 默认值常导致眼图不良 writel(0x0000F000, phy->base + 0x04); // TX_PREEMPHASIS=0xF, TX_SWING=0x0 // 实际值需用示波器测 USB DP/DM 眼图后调整

血泪经验：这个寄存器值没有“通用解”，必须用teledyne lecroy usb protocol suite或廉价usb抓包工具（如 Wireshark + USBPcap）观察 handshake 波形，再反推寄存器值。网上流传的0x0000F000仅适用于 4-layer PCB，6-layer 板需改为0x0000E000。

5.3 现象：OTG 线插入，getprop sys.usb.config显示adb,mass_storage，但 PC 端无法识别为 U 盘，adb devices也无响应

原因：g_mass_storage模块加载时，backing file（如/dev/mmcblk0p1）的文件系统类型不被 Windows/macOS 支持（如 ext4），或分区未格式化。g_serial同理，/dev/ttyGS0权限不足。
解决：

# 确保 backing file 是 FAT32 mkfs.vfat -F32 /dev/mmcblk0p1 # 设置 g_serial 权限 chmod 666 /dev/ttyGS0 # 或在 init.rc 中添加：chmod 0666 /dev/ttyGS0 # 加载时指定 stall=0（禁用 STALL，避免 Windows 拒绝枚举） modprobe g_mass_storage file=/dev/mmcblk0p1 stall=0

注意：stall=0是关键。MTK6575 的g_mass_storage默认启用 STALL，而 Windows 10+ 对 STALL 敏感，会直接放弃枚举。

5.4 现象：mtk preloader tool连接失败，dmesg无任何 USB 相关 log，lsusb看不到 MTK Preloader 设备

原因：Preloader 的 USB PHY 初始化失败，最常见是VBUS检测电路问题。MTK6575 Preloader 会先读VBUSGPIO（如 GPIO20），若为低电平（无电源），则跳过 USB 初始化，直接启动 kernel。
解决：

1. 用万用表测量主板 USB 插座的 VBUS 引脚（Pin 1）对 GND 电压，应为 4.75~5.25V；
2. 若电压正常，检查 Preloader 源码中usb_dl.c的usb_vbus_detect()函数，确认 GPIO 编号与原理图一致；
3. 终极验证：短接 VBUS GPIO 到高电平（如 3.3V），强制 Preloader 进入 USB 下载模式，此时mtk preloader tool应能连接。

后悔药：如果 Preloader 已损坏，可用amlogic usb burning tool的USB Download Mode强制唤醒（需硬件短接 eMMC boot pins），但此法不保证成功，慎用。

6. 进阶技巧：用usbmon抓包 +mtk_usb_dump寄存器快照，定位 USB 协议层死锁

当你已经排除了 PHY、clock、GPIO 等硬件层问题，dmesg显示mtk-ehci正常加载，U 盘也能被lsusb列出，但dmesg却卡在usb 1-1: new high-speed USB device后不再前进——这就是 USB 协议层死锁。此时usb抓包是唯一真相。

6.1 启用usbmon：Linux 内核原生 USB 协议分析器

usbmon不依赖外部硬件，直接从内核 USB core hook 数据包：

# 加载 usbmon 模块（kernel 需 CONFIG_USB_MON=y） modprobe usbmon # 查看可用 bus（通常 usbmon0 对应第一个 host controller） cat /sys/class/usbmon/*/name # 输出：usbmon0 => 101c0000.usb (MTK EHCI) # 开始抓包（输出到文件，避免实时打印丢包） echo 1 > /sys/bus/usbmon/devices/0u/enable tcpdump -i usbmon0 -w usb_trace.pcap # 插入 U 盘，等待 10 秒，停止 echo 0 > /sys/bus/usbmon/devices/0u/enable # 在 PC 上用 Wireshark 打开 usb_trace.pcap # 过滤：usb.capdata && usb.transfer_type == 0x00（控制传输）

关键过滤技巧：在 Wireshark 中输入usb.bRequest == 0x06 && usb.wValue == 0x0100，即可定位GET_DESCRIPTOR(Device)请求。若此请求发出后无响应，说明设备未 reply，问题在设备端或 PHY 信号质量；若请求未发出，说明ehci-mtk的 QH（Queue Head）未正确 setup，需查ehci-q.c。

6.2mtk_usb_dump：打印 USB PHY 和 EHCI 寄存器快照，比dmesg更直接

在ehci-mtk.c中添加调试函数，编译进驱动：

// drivers/usb/host/ehci-mtk.c void mtk_usb_dump_regs(struct ehci_hcd *ehci) { u32 __iomem *reg = ehci->regs; struct mtk_usb_phy *phy = ehci->phy; pr_info("=== MTK USB REG DUMP ===\n"); pr_info("EHCI CAPLENGTH: 0x%02x\n", readb(&reg->caplength)); pr_info("EHCI HCIVERSION: 0x%04x\n", readw(&reg->hciversion)); pr_info("EHCI USBCMD: 0x%08x\n", readl(&reg->command)); pr_info("EHCI USBSTS: 0x%08x\n", readl(&reg->status)); pr_info("PHY CON0: 0x%08x\n", readl(phy->base + 0x00)); pr_info("PHY CON1: 0x%08x\n", readl(phy->base + 0x04)); pr_info("PHY CON2: 0x%08x\n", readl(phy->base + 0x08)); }

在ehci_mtk_run()或ehci_mtk_start_port_reset()中调用：

mtk_usb_dump_regs(ehci);

参数说明：CAPLENGTH=0x00表示 EHCI controller 未响应，问题在 clock/reset；USBCMD=0x00000001（RUN bit 未置位）表示 controller 未启动；PHY CON0 bit[1:0]=0x00表示 PHY 处于 reset 状态。这些值比dmesg文字描述更精确。

6.3 一张表：usbmon抓包中 5 类关键 packet 与对应寄存器状态

我习惯在每次insmod ehci-mtk.ko后，立即执行mtk_usb_dump_regs()并保存输出，再对比usbmon抓包。当usbmon显示SET_ADDRESS成功但GET_DESCRIPTOR超时，而mtk_usb_dump显示PHY CON1=0x00000000，我就知道该去调TX_PREEMPHASIS了——这比翻 datasheet 快 10 倍。希望帮到你。

本文还有配套的精品资源，点击获取