一 Wireless LAN简介

AP软件架构

    高通Atheros AP软件主要的组成部分包括Wireless LAN（无线局域网）、 Ethernet（以太网）、Router Stack(路由协议栈)、Hybrid Network（有线以太网/无线客户端混合应用）。 本文档主要关注的是“Wireless LAN”。

Wireless LAN

Wireless LAN（WLAN）是AP系统的主要组成部分。一般的AP平台支持单频段(2.4G)，其包含一个单频段WLAN电路； 而支持双频段(2.4G+5G)的AP平台则包含两个WLAN电路。这些WLAN设备可以通过legacy 802.11 a/b/g标准进行配置， 或者作为单空间流/双空间流/三空间流的802.11n设备来使用。

WLAN软件层，主要负责在逻辑上控制这些WLAN设备，为AP平台提供WLAN服务。

WLAN软件层主要分为下面两个部分：

• WLAN驱动层
• WLAN应用层

WLAN驱动是整个WLAN软件层的核心，它实现了各个802.11标准并为AP提供WLAN服务。WLAN应用层则包含许多 配置/调试WLAN驱动的工具，还包含了hostapd、supplicant这些用于802.1X/WPA/WPA2/EAP鉴权的进程。

通常，WLAN软件层比较复杂，运行时需要有高性能的CPU支持，但是有些平台的CPU负载有限，因此必要时， 需要根据目标平台对WLAN软件层进行优化。一般来讲，WLAN平台的CPU是一个集成了SoC（System on Chip） WLAN的芯片。 根据AP硬件平台和CPU的负载能力，WLAN软件层可以通过下面三种不同的模式，集成到AP软件系统中：

• Direct Attach模式
• Full Offload模式
• Partial Offload模式

注意：对于一些高通Atheros产品，命令行配置组件已经移到了UCI中，因此对于本文档的所有配置命令， 都有相应的UCI命令，除非其被标明“内部使用 或 仅用于调试”。

Direct Attach架构

在这个模式中，整个WLAN软件层运行在主机上，并通过PCIe或AXI总线与WLAN硬件交互 (参看图 1-1)。

Full Offload架构

在这个模式中，一部分WLAN驱动的组件和一部分WLAN应用层的软件如hostapd/supplicant等运行在主机上， 其他的WLAN应用层组件则运行在WLAN平台上。主机和WLAN平台在软件上，都会提出一层，对双方进行适配。 主机和WLAN平台之间的硬件接口可以是USB, MII, PCIe或AXI。

WLAN软件架构

WLAN驱动层被封装成数个部分，每个部分都提供了API，方便使用者定制自己的AP软件和进行二次开发。

硬件抽象层(HAL)

硬件抽象层(HAL)是驱动和硬件芯片之间的连接部分。如果有多个芯片同时使用，例如双AP的形态， 则每个芯片都会创建一个HAL实例与之对应，因此采用这样的设计，能使高通Atheros芯片和其他厂商的产品， 在软件上能更容易的适配到一起。

HAL的代码可以分为两个大块，1）通用HAL接口，为上层提供API与HAL交互；2）面向指定芯片的HAL模块， 主要是支持具体的硬件。目前高通Atheros芯片的HAL，主要有三个分支：AR5212, AR5416, 和AR9300。详述如下：

抽象出来的HAL转接层，是尽可能的，面向不同的操作系统（OS）和不同系列的芯片时，进行代码复用。 因此必须从HAL模块内部去调用这些函数，就显得尤为重要；同时HAL内部也不应该使用一些链接性质的代码， 因此这里使用ah_hal_printf函数来代替printk函数，用HDPRINTF宏代替DPRINTF宏。

HAL接口层（HAL API）

HAL提供了一系列统一的API，供LAMC层访问。这些API适用于面向不同芯片的HAL。

底端MAC层 (LMAC)

LMAC层包含Atheros设备对象(ATH)。ATH层负责管理硬件的输入队列数据流，同时也管理着底层的协议， 比如Block ACK（BA）处理。之所以设计LMAC层，是因为有Atheros硬件架构需要适配，而UMAC则更接近802.11协议的实现。 LMAC主要提供以下功能，并由UMAC和OSIF层控制：

• 整合了legacy和11n芯片组的传输、接收路径，包括缓冲区和队列的处理。
• 速率控制、DFS、频段扫描。
• 高级11n MAC特性如帧聚合（frame aggregation）、缩短帧间间隙（RIFS）、多路收发节电技术（MIMO power save）等。
• 802.11网络节能和设备电源状态（D0-D3）管理。
• Beacon帧的生成和时间同步（TSF）管理。
• 支持无线唤醒（Wake-On-Wireless）。
• RfKill、自定义LED和GPIO算法。
• 提供支持IQUE, 无线声传（VoW）, 智能天线（Smart Antenna）, 传输波束成形技术（TxBF）等功能的开关。

LMAC接口层（LMAC API）

LMAC API层为UMAC层提一些标准化的API。这样能方便用户替换自己的UMAC层。 因此从设计角度，应避免在UMAC层直接使用LMAC的数据结构，所以最好使用这些API来访问。

上端MAC层 (UMAC)

Upper MAC重要实现802.11协议的处理，并为OS接口层提供API。其主要功能有以下几点：

• AP状态机
• 连接状态机和节点管理
• MAC子层管理实体（MLME）服务
• 一些基本功能比如：扫描（scanning），加密（encryption），电源管理（power management），域管理（regulatory domain），资源管理（resource management）等。
• 与许多协议相关的特定功能如：P2P，通道直接链路建立（TDLS），WMM-AC，无线资源管理（RRM）等。
• 支持一些集中控制式的工作模式如WDS和EXTAP等。
• 提供支持访问控制列表（ACL），自选信道（ACS），IQUE，无线声传（VoW），智能天线（Smart Antenna），传输波束成形技术（TxBF）等功能的开关。

WLAN接口层（WLAN API）

这一层是UMAC层向OSIF层提供的接口层。OSIF应当使用这些API来访问UMAC的数据结构。

系统接口层 (OSIF)

系统接口层是系统适配的模块，为WLAN驱动提供网络协议栈接口和应用向的接口。 这一层使用UMAC提供的API来完成其提供的功能。每个系统都应该适配自己的接口层。

高通驱动架构层(QDF)

这部分代码，提供了一整套驱动相关的接口，方便适配不同的操作系统。这是一个抽象层，由驱动调用， 提供诸如创建timer、tasklet等功能。这个抽象层可以灵活的修改去适配不同的操作系统。本文档使用的 操作系统是Linux 2.6。 任何硬件相关的和系统相关的，不属于OSIF层的内容，应当放到这一层（QDF）。 另外，如果扩展了一些新的接口，也要确保这些函数包含在QDF层的文件中。

Atheros服务架构层 (ASF)

这一部分的代码，提供了一些列基本服务相关的接口，方便对不同操作系统的适配。这一层提供了一些基本服务的接口， 如内存相关接口、debug相关接口等。这个抽象层可以灵活的修改去适配不同的操作系统。本文档使用的操作系统是Linux 2.6。

WLAN应用层（WLAN Application）

Wireless LAN应用层运行在用户空间，其包括以下内容：

• Wireless工具：用于WLAN驱动的配置
• apcfg：AP平台的配置文件
• hostapd：AP模式下的802.1X/WPA/WPA2/EAP鉴权，以及WPS。
• wpa_supplicant：STA模式下的802.1X/WPA/WPA2/EAP鉴权，以及WPS。
• radartool：radar检测的测试/调试工具。
• Spectral守护进程。
• spectraltool：配置/调试spectral扫描的工具。
• athssd：一个用于导出Spectral扫描和分析结果的工具，还可以输出干扰信息。
• pktlog：采集WLAN MAC收发包的debug信息。

统一WLAN软件架构（Unified Software WLAN Architecture）

这一章节主要是在AP和STA模式下，对高吞吐量（VHT）场景的软件结构，有一个更详细的介绍。这些统一提出的栈一样的分层， 支持所有的QCA软件结构，不论用户采用何种方式集成他的AP软件系统（direct attach模式或者Full/Partial offload模式）。

Offload模式分层（Offload stack）

• OS接口层（OS Interface）：为WLAN驱动提供网络栈和应用向的接口。
• WSI层：WLAN Service API，由UMAC封装，供OSIF层调用（避免直接访问UMAC的数据结构）。
• UMAC层：多数802.11协议在这一层实现（AP状态机，连接状态机，MLME服务）
• 目标UMAC：处理低级别的MAC功能。管理数据流（Tx和Rx）到硬件的输入队列中，buffer管理，速率控制，Aggregation，MIMO节能。
• WAL层：对不同MAC的高级别的功能的抽象
• HAL层：硬件抽象层，实现底层的硬件功能，如创建descriptor，创建加密key，创建channel等。

Unified UMAC支持项

• 新的结构基于间接化的函数指针的动态链接，同时支持direct attach和offload解决方案。
• 在direct attach方案中，使用的是旧有的IF_LMAC函数指针。而在offload结构中，使用的是OL_WMI函数指针。
• UMAC封装的功能（函数）可以根据需要进行开启或关闭，不论在主机端运行还是在目标端运行。

基于当前这种模块化的架构，新的offload WMI层可以很容易的继承进去。

11AC offload host-target interface

Host与target之间通过这些已经划分好的各个软件接口层，协作通信。本章节介绍的就是这些软件接口层

Host接口层 (HIF)

这一层对host和target之前的总线接口进行抽象，并提供了一套二者可以互相通信的机制。

Bootloader消息接口层(BMI)

在初始化过程中，host可以使用Bootloader消息接口层(BMI)提供的一些功能，比如获取target的版本信息； 从target的内存中上传（或读取）一些代码和数据；读/写target寄存器；运行target上指定地址的程序等。 BMI层可以下载指定的应用程序、测试程序还有补丁到代码和数据中，有时候也会设置一些target应用程序中的全局变量。

Host Target通信层 (HTC)

HTC层用于WMI和HTT二者进行发送、接收一些控制类/数据类消息，这些消息的源头的目的是target和host系统的11ac设备之间的纽带部分。

无线消息接口层(WMI)

Host与target之间的控制通路由WMI接口来完成。一些预先定义好的WMI消息，用于host WLAN与target WLAN之间交互。

Host Target传输层(HTT)

Host与target之间的数据通路由WMI接口来完成。一些预先定义好的HTT消息，用于host WLAN与target WLAN之间交互。

QCA_Networking_2016.SPF.2.0版本的WLAN驱动模块架构

这一章节主要介绍Direct-Attach和Off-load模式芯片组的，WLAN驱动的内核模块。参看下面这个框图：

WLAN驱动模块包含下面的内核obj：

1. asf.ko – 基本框架模块
2. qdf.ko – 基本框架模块
3. ath_spectral.ko – 支持Spectral
4. ath_dfs.ko – 支持DFS
5. umac.ko – 通用802.11协议管理
6. ath_hal.ko – Direct-Attach硬件虚拟层
7. ath_rate_atheros.ko – 支持Direct-Attach速率控制
8. hst_tx99.ko – 支持Direct-Attach Tx99
9. ath_dev.ko – Direct-Attach LMAC层
10. qca_da.ko – 支持Direct-Attach驱动
11. qca_ol.ko – 支持Offload驱动
12. smart_antenna.ko – 支持Smart Antenna
13. ath_pktlog.ko – 支持Direct-Attach Packet日志

通用WLAN驱动模块

通用WLAN驱动模块用于Direct-Attach和Off-load芯片组。 asf.ko，qdf.ko，ath_dfs.ko，ath_spectral.ko和umac.ko这些，对于Direct-Attach和Off-load芯片组都是需要的。

Direct-Attach WLAN驱动模块

以下这些模块只在Direct-Attach芯片组适用： ath_hal.ko，ath_rate_atheros.ko，hst_tx99.ko，ath_dev.ko，qca_da.ko 这些obj可以在umac.ko安装后使用。qca_da.ko集成了内核PCI子系统接口。加载qca_da.ko后，才能识别Direct-Attach芯片组。

Offload specific WLAN驱动模块

qca_ol.ko用于支持Offload芯片组。其在umac.ko安装后使用。加载qca_ol.ko后，才能识别Offload芯片组。 qca_ol.ko同时还支持NSS Wifi-Offload功能。

Offload和direct-attach两种模式下驱动的模块化

这一章节主要描述当前WLAN驱动，模块化的设计与实现。Offload后续缩写为OL，Direct-Attach缩写为DA。 WLAN驱动的不断发展，驱动的模块化逐步退出历史舞台，但是，OL需求，其本质是仅需要UMAC模块的一部分。 如果实际应用场景中，同时需要OL和DA两种模式，那么模块化就没有什么意义，但是对于特定的驱动（OL和DA二选一）， 模块化的处理方法，就很有帮助，因为这样可以不必全部夹在WLAN的驱动，仅按需取用即可。

新的QCA芯片组没有基于DA模型来，而是使用了通用kernel模块、DA模块与OL模块分离的模式来实现。这样可以使一些通用的模块， 能够根据QCA无线设备的平台，灵活的使用DA或者OL。

这个架构，同样能够满足未来QCA芯片组的需要，虽然其可能并不按照DA或者OL的思路来做。下面是就截止到 QCA_Networking_2016.SPF.2.0版本发布时的一些设计概要：

• OL的代码是UMAC的一部分，并依赖于DA模块（LMAC，HAL）。
• UMAC模块包含的代码应该按照模块化思想划分到OL或DA的模式中去。

如上图所示，所有的模块都应用于DA或OL硬件。如果所有平台都有DA和OL硬件，那么这样的设计是没问题的。 但如果目标平台只使用其中一部分，那么包含所有这些模块的驱动体量，就不太合适。客户只想使用DA或者OL模式， 就被迫使用上面列出的所有模块，这大概需要4M大小的固件。

上图主要表现的是，为适配不同的驱动模型，而进行的模块划分。 以下设计点需要考虑到：

• asf和adf是核心框架的一部分，这两个模块必不可少。
• ath_dfs和ath_spectral模块对OL和DA芯片组是通用的，如果不使用，可以在编译的时候禁用掉。
• umac模块对OL和DA通用，它实现了协议的一部分和Host层的数据通路。
• 一些可选的模块可以根据需求来选用。
• 其他的模块需要根据HW的类型来使用。
  • DA类型的硬件使用到HAL，rate，LMAC(ath_dev) 和qca_da模块。
  • OL类型的硬件将使用qca_ol模块。
• qca_da和qca_ol实现指定类型的硬件功能，独立于其他模块。

旧框图 Vs 新框图

上面的框图说明了了QCA_Networking_2016.SPF.3.0版本的WLAN驱动，各个模块之间的关系。 下面这些点需要关注：

• asf和adf是核心框架的一部分，这两个模块必不可少。
• spectral和dfs的用途不变，OL和DA都需要。
• OL模块是UMAC的一部分，跟当前一样。
• 所有DA模块中依赖UMAC的部分将从UMAC中移除。
• UMAC中所有DA相关的功能，将被移到qca_da模块中。
• DA驱动依赖于OL驱动。

WLAN驱动的模块化

在第一阶段(QCA_Networking_2016.SPF.3.0版本), OL模块是独立于DA模块的。 下面是这一阶段主要的修改内容：

• 通用的LMAC (ath_dev)功能 (非DA相关的)移到了UMAC.
• LMAC中DA相关的功能。移到了qca_da模块中。
• UMAC中DA相关的功能，做的更通用了，并移到了ieee80211层。

下面这个图描述了上述修改。

注意 这个图并没有表现出所有的模块，只是列出了涉及到修改的模块。

LMAC (ath_dev) 功能迁移到UMAC

既然UMAC独立于LMAC，那么一些功能就需要移到UMAC中。这些功能是不依赖DA相关的，所以可以安全的移到UMAC中。 这样做也是为了保持OL驱动的独立性。

下面这些是移到UMAC的模块：

• ath_timer
• ath_green_ap
• th_wbuf
• if_bus
• ath_pci
• ath_ahb

下面这些功能，将做成通用层，并移到ieee80211层，这样他们就可以直接被OL层调用。

• ath_new_opmode -> ieee80211_new_opmode
• ath_vap_iter_new_opmode -> ieee80211_vap_iter_new_opmode

UMAC中的DA功能，移到qca_da

所有的DA相关的功能，将被整合到一个新的模块：qca_da。这个模块和ath_hal，ath_rate，ath_dev，tx99一样，都是面向DA的。

下面这些是移到qca_da模块的内容：

• ath_linux
• ieee80211_aponly
• if_ath
• if_ath_amsdu
• ath_cwm
• ath_cwm_project
• if_ath_uapsd
• if_ath_dfs
• if_ath_aow
• if_ath_quiet
• if_ath_mat

UMAC中的DA功能，做成通用层，并移到ieee80211层

目前这些功能处在UMAC模块里，面向DA的层次中 (if_lmac layer)，但是这些功能也同样被OL层使用。 由于if_lmac移到了qca_da模块，这些功能将被做到ieee80211层。

下面这些功能将被移到ieee80211层：

• find_alternate_mode_channel
• ieee80211_random_channel
• ieee80211_get_test_mute_chan
• ieee80211_vap_iter_update_bss_chan
• ieee80211_dfs_action
• ieee80211_mark_dfs
• ath_net80211_buffull_handler renamed to ieee80211_buffull_handler. ic_notify_buffull will be removed.
• ath_net80211_get_ald_statistics renamed to ieee80211_get_ald_statistics. ic_get_ald_statistics will be removed.
• ath_net80211_add_hmmc renamed to ieee80211_add_hmmc . ic_add_hmmc will be removed
• ath_net80211_del_hmmc renamed to ieee80211_del_hmm ic_del_hmmc will be removed

内核PCI/AHB接口

PCI设备的注册将独立与OL和DA硬件完成。UMAC模块将之注册OL设备。qca_da模块将只注册DA设备。 每个模块都有它自己的PCI probe函数，并且各自独立的完成对设备的初始化。

这一点也对给予OK和DA的AHB设备适用。例如，QCA9558是基于DA的，IPQ4018是基于OL的。

WLAN驱动模块化的一些其他修改

从QCA_Networking_2016.SPF.4.0版本开始，OL和DA驱动相互独立，并新建了一个UMAC模块，作为通用层，并独立于OL和DA的模块。

因为DA驱动已经独立于“UMAC+OL”驱动结构，所以将UMAC和OL模块划分成两个不同的模块是必须的。

• 将所有的OL文件都放到一个新模块（qca_ol）中。这个模块将独立于UMAC模块。
• 建立一个独立的UMAC模块，独立于OL和DA模块。

区分Offload相关的文件

当前的UMAC模块包含通用层，以及Offload的函数和文件。

当前的Offload文件

所有的Offload文件在WLAN驱动的源码中，都放在了“offload”目录中，这些文件在一起组成一个新的“qca_ol”模块。

Kernel PCI/AHB接口文件

在独立的DA设备注册过程中使用的PCI和AHB初始化文件，都作为UMAC模块的一部分，被移到了新的qca_ol模块中。

独立的UMAC模块

设置一个独立的UMAC模块的目的，是可以将Offload和Direct-Attach之间的共通部分做到一个模块中， 这样Offload和Direct-Attach模块就可以独立的使用这部分共通代码。同时，这样做也能减少驱动的image大小。

由于所有的offload文件移到了qca_ol模块中，所以由UMAC直接调用的offload函数，将被归结到下面内容中：

• OL参数函数，从UMAC中调用
• OL函数通过“ic”指针访问OL层
• 在UMAC中的，并且是OL相关的函数
• 独立于OL的函数，但当前处在OL层。
• OL和DA模块使用到的UMAC函数
• NSS (WiFi OL)模块化

从UMAC调用的OL参数函数

用很多OL函数由UMAC直接调用，用于配置OL驱动的参数。 作为独立的UMAC，不能直接调用OL层的函数，而是回调的办法，来访问OL或DA层。 ic_vap_get_param不能用时，可以添加这个函数功能。 对于“set”函数，将使用“ic_vap_set_param”。

其他一些类似的函数：

ol_txrx_clear_rawmode_pkt_sim_stats
ol_txrx_host_stats_get
ol_tx_rst_tso_stats
ol_txrx_print_rawmode_pkt_sim_stats
ol_ath_set_vap_cts2self_prot_dtim_bcn
ol_tx_rst_sg_stats
ol_tx_print_sg_stats
ol_rst_rx_cksum_stats
ol_tx_print_tso_stats
ol_txrx_host_msdu_ttl_stats
ol_txrx_debug
ol_txrx_fw_stats_get
ol_ath_ucfg_reset_peer_mumimo_tx_count
ol_txrx_aggr_cfg
ol_rate_is_valid_basic
ol_ath_net80211_get_vap_stats
ol_txrx_host_me_stats
ol_txrx_fw_stats_cfg
ol_txrx_host_stats_clr
ol_print_rx_cksum_stats

OL函数通过传递“ic”指针来访问OL层

所有UMAC访问OL或DA层使用的函数，都应当以回调的方式完成，比如使用“ic”函数指针。 任何绕过这种策略访问OL或DA层的函数，都会被判断出来。所以要么通过“ic”指针来访问，或者干脆将整个模块都移到OL层。

通过以下步骤完成通过“ic”指针访问。

1. 添加一个“struct ieee80211com”结构体的函数指针。
2. 在OL设备attach时，注册到OL函数中 (初始化函数指针) 。
3. 需要访问OL曾是，调用这个函数指针。

比如:

ol_ll_pdev_tx_lock
ol_ll_pdev_tx_unlock
ol_txrx_osif_vdev_register
ol_tx_tso_sg_process_skb
ol_ath_ucfg_get_peer_mumimo_tx_count
ol_net80211_set_mu_whtlist

在UMAC中的，并且是OL相关的函数

许多到OL层数据通路相关的函数，都在osif_umac文件中，这是UMAC模块的一部分。这些文件都是OL设备相关的，所以会被移到offload模块。

比如:

osif_ol_ll_vap_hardstart
osif_ol_hadstart_vap_vow_debug
osif_deliver_data_ol

独立于OL的函数，但当前处在OL层

有一些函数是处在OL层的，但却和OL层没什么关系，这些可以作为通用部分和UMAC模块的一部分。这些函数可以移到UMAC模块。

比如:

transcap_nwifi_to_8023
dscp_tid_map

OL和DA模块使用到的UMAC函数

因为UMAC在OL或DA模块之前启动，所以OL或DA模块需要的函数，需要开放出来。 在开发的阶段1，创建了一个新的umac_exports.c文件，用于开发一些必要的函数。

NSS (WiFi OL)模块化

osif_nss文件将会是“umac”模块的一部分，但是osif_nss_wifiol相关的文件，将被移到“qca_ol”模块中，因为这些是OL芯片组相关的。

这样就增加了一个限制，“umac”不能直接调用osif_nss_wifiol函数，因为“umac”模块将在“qca_ol”前启动。 为了避免这样的限制，osif_nss_ol_pdev_attach函数调用时，将会携带一个函数数组指针，这个函数指针数组将会初始化 成相应的osif_nss_wifiol函数。

下面这个nss_wifi_offload_funcs结构体，用于就是含有相应函数指针的数组。这个结构体在 osif_nss_ol_pdev_attach函数中，会被传递到ic->nss_funcs。

struct nss_wifi_offload_funcs nss_wifi_funcs = {
    osif_nss_ol_store_other_pdev_stavap,
    osif_nss_vdev_me_reset_snooplist,
    osif_nss_vdev_me_update_member_list,
    osif_nss_ol_vap_xmit,
    osif_nss_vdev_me_update_hifitlb,
    osif_nss_vdev_me_dump_denylist,
    osif_nss_vdev_me_add_deny_member,
    osif_nss_ol_vdev_set_cfg,
    osif_nss_vdev_process_mpsta_tx,
    osif_nss_ol_wifi_monitor_set_filter,
    osif_nss_vdev_get_nss_id,
    osif_nss_vdev_process_extap_tx,
    osif_nss_vdev_me_dump_snooplist,
    osif_nss_ol_vap_delete,
    osif_nss_vdev_me_add_member_list,
    osif_nss_vdev_vow_dbg_cfg,
    osif_nss_ol_enable_dbdc_process,
    osif_nss_vdev_get_nss_wifiol_ctx,
    osif_nss_vdev_me_delete_grp_list,
    osif_nss_vdev_me_create_grp_list,
    osif_nss_vdev_me_delete_deny_list,
    osif_nss_vdev_me_remove_member_list
};

“qcawifi.sh”脚本的变化

qcawifi.sh脚本用于安装WLAN驱动模块，传递模块参数，它也同样需要修改去使用这种模块化。

UMAC和OL模块之间的模块参数划分

所有的模块参数但前都被传递到了UMAC模块。因为qca_ol和qca_da模块分开的关系，qcawifi.sh脚本也应该做相应的变化， 根据当前的模块传递参数。

下面是一些传递到相应模块的模块参数。

模块启动顺序

asf
adf
ath_dfs
ath_spectral
umac
ath_hal
ath_rate_ahteros
hst_tx99
ath_dev
qca_da
qca_ol (这个模块可以在umac之后启动)

qca_ol模块将启动OL设备，qca_da模块将启动DA设备。他们之间互相独立，设备的启动顺序，将取决于谁先被检测到。这也会决定radio的名字。

WLAN驱动固件大小

图 1-12 WLAN驱动固件大小

OL和DA芯片组，都使用的平台。

只使用OL芯片组的平台。

只使用DA芯片组的平台。

Wi-Fi校准数据映射

为了使WLAN驱动获得正确的校准数据，必须满足下面这些条件：

• 校准数据存储在flash上
• 预初始化脚本
• Wi-Fi脚本

校准数据存储在flash上

对于有多radio的平台，校准数据按照特定的顺序存储在flash上。这个特定的顺序由校准时决定。

预初始化脚本

这些脚本从flash上读取校准数据，然后写到文件中。通常，数据会写到”tmp”目录下。 文件名通常被命名为wifi0.caldata，wifi1.caldata。这些脚本必须能够得到flash上的校准数据以及 哪个WLAN驱动对应哪个radio。这些必须根据上面的规则写文件，以确保WLAN驱动启动时加载正确的校准文件。

预初始化脚本一般会在下面的路径：

• IPQ平台：qsdk/target/linux/ipq806x/base-files/lib/read_caldata_to_fs.sh
• QCA9531/QCA9558/QCA9563平台：qsdk/target/linux/ar71xx/base-files/lib/preinit/81_load_wifi_board_bin

这些脚本需根据/tmp/sysinfo/board_name的文件名，得到板子的类型。根据board_name，决定按照什么样的顺序去写校准数据。

Wi-Fi脚本

Wi-Fi脚本负责安装WLAN模块，并按顺序启动radio。如果有多个radio（Offload和Direct-attach）， 安装模块的顺序，取决于radio启动的顺序，同时也决定了radio的名字（比如wifi0、wifi1）.

qca_ol.ko初始化offload radio。qca_da.ko初始化direct-attach radio。正如本章节前面所述， 预初始化脚本能够得到WLAN模块安装的顺序，和依赖此顺序生成的文件名。

文档信息
--------------
* 作者:
* 版权声明：自由转载-非商用
* 转载: []

VI_