i.MX6是Freescale推出的ARM架構高端多媒體處理器，與常規(guī)的ARM處理器不同的是，i.MX6具有非常實用的PCI Express接口，這對于從事WiFi行業(yè)的人士來說具有非常大的吸引力。通常的基于WLAN SoC進行無線產品設計，很難具備高性能多媒體處理能力；通常的基于ARM處理器進行多媒體處理器平臺設計，又很難實現高性能無線傳輸。i.MX6的出現使得高性能無線多媒體平臺的設計大大簡化。其實此前也使用過TI AM3894進行無線媒體服務器的設計，但是其過大的發(fā)熱量極大地限制了其應用，Mindspeed公司也具有PCI-e接口的ARM處理器，但畢竟不是主流廠商，所以i.MX6深深地贏得了廣大工程師的喜愛，包括我本人。
說了這么多，開始進入本文的主題。做過Qualcomm Atheros平臺的讀者一定知道，WiFi產品出廠前需要在產線通過復雜的產測環(huán)節(jié)，主要包括射頻校準，測試，參數寫入等步驟，未寫入射頻參數的WiFi產品是無法正常使用的。如果是基于Qualcomm Atheros WLAN SoC做的無線產品，官方會有移植完成的ark.ko內核模塊，nart.out應用程序及各種所需的庫文件，Freescale i.MX6不在官方支持的范圍內。因此，如果想順利產測，就必須自行移植驅動程序及測試程序。
鄭重聲明：本文關于驅動移植部分寫得很不專業(yè)，并且是以流水賬的方式記錄，主要是想幫助面臨同樣問題的讀者，所以還請讀者海涵。
1 此前調試i.MX6驅動程序時已經搭建好i.MX6的開發(fā)環(huán)境，因此本文不進行搭建過程的描述，讀者可以訪問https://www.witimes.com/imx6-build-environment/了解大致過程。
2 首先編譯art.ko 模塊。將ART2 2.28源代碼解壓在ltib/rpm/BUILD目錄下 ，進入driver/linux目錄，更改makefile.artmod文件，指定Linux內核路徑及工具鏈的路徑，如下：
KDIR:=/home/tom/ltib/rpm/BUILD/linux-3.0.35
PWD:=$(shell pwd)
ROOTDIR:=$(PWD)/modules
ifeq($(ARM),1)
ARC:=arm
CROSS_CC:=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro
toolchain/bin/arm-none-linux-gnueabi-
DEBUG:=0
endif
其中，將DEBUG改為1可以開啟調試模式。
3 使用make –f makefile.artmod命令即可開始編譯，但是會遇到很多的問題。
3.1. error: 'phys_t' undeclared (first use in this function)，含義是phys_t數據類型未定義，查看Atheros SDK中關于phys_t數據類型的定義，將phys_t的定義復制到/modules/include/ dk_flash.h中，此錯誤不再出現。
3.2. modules/dk_func.c:468:2: error: unknown field 'ioctl' specified in initializer，這是由于2.6.36內核之后 去掉了原來的ioctl，添加兩個新的成員，所以會出錯：
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
修改modules/ dk_func.c中的ioctl為compat_ioctl，編譯通過。
3.3 modules/dk_event.c:21:26: error: 'SPIN_LOCK_UNLOCKED' undeclared here (not in a function)，含義是SPIN_LOCK_UNLOCKED未聲明，修改modules/dk_event.c中的
spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
為
static DEFINE_SPINLOCK(driver_lock);
編譯通過，得到art.ko。
4 將編譯得到的art.ko模塊下載到目標板中，insmod art.ko命令插入模塊，出現一條錯誤信息“Could not find flash device!”，這是flash_init()函數報出的錯誤。考慮到PCIe網卡的驅動程序不應該初始化Flash設備，因為PCIe網卡的校準信息保存在EEPROM或者OTP中，推測必定有配置錯誤導致了這條錯誤信息。
5 仔細閱讀makfile.artmod文件，發(fā)現意一條重要的注釋信息“Making generic AP art module build. This build target is used for 3rd party AP processor”，即“編譯用于第三方處理器的目標文件”，對應的編譯命令為
make ARCH=$(ARC) PB42=1 DEBUG=$(DEBUG) CROSS_COMPILE=$(CROSS_CC) -C $(KDIR) M=$(PWD)/modules modules
很明顯，問題就出在這里。再次編譯，得到了可以正確加載的內核模塊。
6 接下來就是nart的移植。遇到了諸多的問題。
6.1 /home/tom/ltib/rpm/BUILD/art2_ver_2_20ap_src/art/../wlan/hal/nartlinux/ah_osdep.h:93:15: error: conflicting types for 'va_list',
/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/../arm-fsl-linux-gnueabi/multi-libs/usr/include/stdio.h:80:20: note: previous declaration of 'va_list' was here，含義為va_list數據類型定義沖突。既然工具鏈中已經定義了va_list，那么最簡單的辦法自然是屏蔽nart中對于va_list的定義，更改wlan/hal/nartlinux/ah_osdep.h文件
#ifndef __LINUX_POWERPC_ARCH__
//typedef void *va_list;
#endif
再次編譯，問題不再出現。
6.2 uint32_t數據類型未聲明的錯誤，我的解決辦法是將uint32_t類型重命名為uint32_imx，并修改nart源碼中所有涉及到uint32_t的部分。
6.3 經過6.1，6.2的調整，編譯過程可以完成大部分，但在最后的link環(huán)節(jié)，出現了大堆的關于readl，writel的錯誤。折騰了大概1天的時間，此問題一直沒有解決。
7 由于本人水平十分有限，所以不得不放棄在ART2 2.28版本上的嘗試，開始使用ART2 4.6版本，好在這個版本未在link環(huán)節(jié)，現了關于readl，writel的錯誤，順利地得到nart.out及各種庫文件。
8 將第7步得到的art.ko ,nart.out及各種庫文件下載到目標板中，nart.out可以正常運行。然而悲劇的是，更大的問題來了。每當我嘗試使用artgui load dut時，總會出現“Error: get version ioctl failed !”，這個問題大概困擾了我3-4天的時間。期間非常仔細地閱讀了源代碼得知這條打印信息出現在get_version_info()函數中：
if ((status=get_version_info(hDevice, pDrvVer)) != A_OK) {
close(hDevice);
A_FREE(pdevInfo->pdkInfo);
A_FREE(pdevInfo);
return status;
}
說明，如果get_version_info()返回的不是OK，則關閉設備，這部分代碼出現在common/linux_hw.c中。get_version_info()在get_device_client_info()中被調用，get_device_client_info()在deviceInit()中被調用看字面意思就是初始化設備，deviceInit()在setupDevice()函數中被調用。跟蹤調試get_version_info()，發(fā)現其通過以下語句獲得version的值
if (ioctl(hDevice,DK_IOCTL_GET_VERSION,&version) < 0)
那么問題應該就是出在ioctl函數這里。
9 是時候了解一下ioctl函數了（做驅動開發(fā)的讀者可不要見笑，哈哈）。ioctl是設備驅動程序中對設備的I/O通道進行管理的函數。所謂對I/O通道進行管理，就是對設備的一些特性進行控制，例如串口的傳輸波特率、馬達的轉速等等。它的調用方式如下：
int ioctl(int fd, ind cmd, …)；
其中fd是用戶程序打開設備時使用open函數返回的文件標示符，cmd是用戶程序對設備的控制命令，至于后面的省略號，那是一些補充參數，一般最多一個，這個參數的有無和cmd的意義相關。
ioctl函數是文件結構中的一個屬性分量，就是說如果你的驅動程序提供了對ioctl的支持，用戶就可以在用戶程序中使用ioctl函數來控制設備的I/O通道。
分析一下nart代碼，的確符合這樣的調用過程，下圖（不知道原作者是哪位，如有侵權，請聯系無線時代）很好地展示了這一過程。
那么，根據本人的粗淺理解，用戶空間的ioctl調用通過內核向驅動程序傳遞了fd，cmd兩個重要參數，其余的參數是可選的。那么ioctl(hDevice,DK_IOCTL_GET_VERSION,&version)主要就是將hDevice及DK_IOCTL_GET_VERSION命令傳遞給驅動程序，其中DK_IOCTL_GET_VERSION定義在driver/linux/modules/include/dk_ioctl.h中。查看驅動程序中對于cmd的處理
switch (cmd) {
case DK_IOCTL_GET_VERSION:
#ifdef DK_DEBUG
printk("DK:: DK_IOCTL_GET_VERISION n");
#endif
data = (DRV_MAJOR_VERSION << 16) | (DRV_MINOR_VERSION);
ret = put_user(data, (INT32 *)arg);
break;
case DK_IOCTL_GET_CLIENT_INFO:
#ifdef DK_DEBUG
printk("DK:: DK_IOCTL_GET_CLIENT_INFO n");
#endif
在驅動程序的編譯過程中已經開啟了DEBUG功能，那么應該打印出“DK:: DK_IOCTL_GET_VERISION”這條信息，然而實際的log中并不存在——ioctl沒有將參數傳遞至驅動程序！
10 回想3.2中的改動，一定引起了內核與驅動程序不匹配，才導致fd及cmd無法正確傳遞，看來2.3中的改動無法根本解決問題，需要對驅動程序進行大幅度調整才行。可是想想自己的軟件水平，實在是對自己沒有信心。
然而，我承諾的事情一定兌現，絕不能輕易放棄。
萬般無奈之下，我想到了Qualcomm Atheros的IPQ8064也是ARM架構，如果Qualcomm想在自己的Demo板上運行ART，就必須經歷同樣的過程！于是托朋友弄到了最新版本的nart及驅動程序源代碼，此處不便透露版本信息，需要做的主要工作就是仿照AP148的config文件及makefile文件編寫Freescale i.MX6的config文件及makefile文件，問題終于解決！
11 以下是nart正常運行dut上的打印信息。
以下是artgui的截圖。
使用artgui讀取EEPROM，發(fā)現其內容完全正確，其中MAC地址為“7C:C3:A1:B7:F2:5B”。
正常加載ath9k驅動程序，MAC地址同樣為“7C:C3:A1:B7:F2:5B”，至此，為Freescale i.MX6處理器移植ART驅動程序已全部完成。
