linuxsdio驅動下載

❶ 為什麼SD卡在linux下/dev下的設備名叫mmcblk0p1

SD/MMC 卡的設備構造差不多，MMC 應該是 SD 的前身，不過 MMC 當時的設計比 SD 小一半。

所以，SD/MMC 的驅動通用，進一步的，Linux 的設備節點就延續了 MMC 的這個名字，後面的 blk 是塊設備這個英文的簡寫， mmcblk 也就是「 mmc/sd 塊設備」，0 就是這個 mmc/sd 設備的順序編號，p1 就是第一個分區。

mmc卡與sd卡的區別:

1、mmc卡和sd卡的長寬是一樣的，SD卡略厚。

2、SD卡的觸點比MMC卡多一個，是用於數字版權保護（DRM）的。

3、SD卡的側邊比MMC卡多一個防寫的開關。

(1)linuxsdio驅動下載擴展閱讀：

SD模式

驅動模式

SD卡有兩種驅動模式：SPI模式與SDIO模式。它們所使用的介面信號是不同的。在SPI模式下，只會用到SD卡的4根信號線，即CS、DI、SCLK與DO(分別是SD卡的片選、數據輸入、時鍾與數據輸出)。

傳輸模式

SD卡共支持三種傳輸模式：SPI模式（獨立序列輸入和序列輸出），1位SD模式 （獨立指令和數據通道，獨有的傳輸格式）， 4位SD模式 （使用額外的針腳以及某些重新設置的針腳。支持四位寬的並行傳輸）。

❷ 如何學習Linux設備驅動

通常，內核的升級對從事linux應用程序開發的人員來說影響較小，因為系統調用基本保持兼容，影響比較大的是驅動開發人員。每次內核的更新都可能導致許多內核函數原型上的變化，其中既有內核本身提供的函數，也有硬體平台代碼提供的函數，後者變化的更加頻繁。這一點從許多經典書籍就可驗證，當你按照手裡的經典著作，如：Alessandro的《linux設備驅動程序》，編寫驅動時，發現並不能夠成功的在你的linux平台上編譯通過、或不能正常執行，原因就在於你用的內核和書里的不一致。
本文從兩個方面去解釋這個問題，一方面是如何寫好linux設備驅動，另一方面是如何應對不斷升級的內核。
如何寫好Linux設備驅動
Linux設備驅動是linux內核的一部分，是用來屏蔽硬體細節，為上層提供標准介面的一種技術手段。為了能夠編寫出質量比較高的驅動程序，要求工程師必須具備以下幾個方面的知識：
● 熟悉處理器的性能
如：處理器的體系結構、匯編語言、工作模式、異常處理等。對於初學者來說，在還不熟悉驅動編寫方法的情況下，可以先不把重心放在這一項上，因為可能因為它的枯燥、抽象而影響到你對設備驅動的興趣。隨著你不斷地熟悉驅動的編寫，你會很自然的意識到此項的重要性。
● 掌握驅動目標的硬體工作原理及通訊協議
如：串口控制器、顯卡控制器、硬體編解碼、存儲卡控制器、I2C通訊、SPI通訊、USB通訊、SDIO通訊、I2S通訊、PCI通訊等。編寫設備驅動的前提就是需要了解設備的操作方法，所以這些內容的重要程度不言而喻。但不是說要把所有設備的操作方法都熟悉了以後才可以寫驅動，你只需要了解你要驅動的硬體就可以了。
● 掌握硬體的控制方法
如：中斷、輪詢、DMA 等，通常一個硬體控制器會有多種控制方法，你需要根據系統性能的需要合理的選擇操作方法。初學階段以實現功能為目的，掌握的順序應該是，輪詢->中斷->DMA。隨著學習的深入，需要綜合考慮系統的性能需求，採取合適的方法。
● 良好的GNU C語言編程基礎
如：C語言的指針、結構體、內存操作、鏈表、隊列、棧、C和匯編混合編程等。這些編程語法是編寫設備驅動的基礎，無論對於初學者還是有經驗者都非常重要。
● 良好的linux操作系統概念
如：多進程、多線程、進程調度、進程搶占、進程上下文、虛擬內存、原子操作、阻塞、睡眠、同步等概念及它們之間的關系。這些概念及方法在設備驅動里的使用是linux設備驅動區別單片機編程的最大特點，只有理解了它們才會編寫出高質量的驅動。
● 掌握linux內核中設備驅動的編寫介面
如：字元設備的cdev、塊設備的gendisk、網路設備的net_device，以及基於這些基本介面的framebuffer設備的fb_info、mtd設備的mtd_info、tty設備的tty_driver、usb設備的usb_driver、mmc設備的mmc_host等。
Linux內核為設備驅動編寫者提供了標準的介面，驅動編寫者無需精通內核的各個部分，只需要明確內核提供給我們的介面，並實現此介面就可以了。內核提供的介面採用的是面向對象的思路，即把目標設備抽象成一個對象，通常利用一個結構體來描述這個對象。驅動工程師的任務就是實現這個對象。這個結構體中會包含設備的屬性（用變數表示）和操作方法（用函數指針表示）。如：字元設備的cdev
struct cdev {
struct kobject kobj;
struct mole *owner;
const struct file_operations *ops; // 操作方法結合，其它項都是屬性
struct list_head list;
dev_t dev;
unsigned int count;
};
開始階段可以以模仿為主，即套用一些固定的模板、參考常式。
如何應對不斷升級的內核
內核升級對驅動的影響主要體現在，（1）驅動介面定義的變化；（2）內核的一些功能函數的名稱、參數、頭文件、宏定義的變化；（3）平台代碼關於硬體操作方面封裝的一些函數的變化；（4）設備模型的影響。
● 驅動介面定義的變化
如：2.4內核中字元設備驅動的注冊介面是：
int register_chrdev(unsigned int major, const char * name, struct file_operations *fops)
而2.6內核中已經不建議使用這種方法了，改為：
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
這種介面定義及注冊方法帶來的變化，發生的並不頻繁。解決方案是：參考內核中的代碼。這種介面定義及注冊方法在內核中非常容易找到，如：字元設備驅動的注冊方法及介面定義可以參照內核driver/char/目錄下的很多實例。
● 內核的一些功能函數的名稱、參數、頭文件、宏定義的變化
如：中斷注冊函數的格式及參數在2.4內核、2.6內核低版本和高版本之間都存在差別，在2.6.8中，中斷注冊函數的定義為：
int request_irq(unsigned int irq, irqreturn_t (*handler)(int, void *, struct pt_regs *),unsigned long irq_flags, const char * devname, void *dev_id)
irq_flags的取值主要為下面的某一種或組合： SA_INTERRUPT、SA_SAMPLE_RANDOM、SA_SHIRQ
在2.6.26中，中斷注冊函數的定義為：
int request_irq(unsigned int irq, irq_handler_t handler,unsigned long irqflags, const char *devname, void *dev_id)
typedef irqreturn_t (*irq_handler_t)(int, void *); irq_flags的取值主要為下面的某一種或組合：（功能和2.6.8的對應）IRQF_DISABLED、IRQF_SAMPLE_RANDOM、IRQF_SHARED
當出現這些問題時，編譯過程中，編譯器會給我們比較明確的錯誤提示，根據這些提示你可以判斷出是否是缺少頭文件問題、是否是函數參數定義有誤等。解決問題的最好辦法還是到你的目標內核中找信息。此時找問題的方法可以藉助於搜索，如：你可以在新的內核中搜索request_irq，看新內核中的驅動是如何使用它的，這種方法非常有效。
● 平台代碼關於硬體操作方面封裝的一些函數的變化
內核中，硬體平台相關的代碼在內核更新過程中變化比較頻繁，和我們的設備驅動也是息息相關，所以在針對一個新內核編寫設備驅動前，一定要熟悉你的平台代碼的結構。有時平台雖然提供了內核要求的介面函數，但使用起來功能卻並不完善。下面還是先舉個例子說明平台代碼更新對設備驅動的影響。
如：在linux-2.6.8內核中，調用set_irq_type(IRQ_EINT0,IRQT_FALLING);去設置S3C2410的IRQ_EINT0的中斷觸發信號類型，你會發現不會有什麼效果。跟蹤代碼發現內核的set_irq_type函數需要平台提供一個針對硬體平台的實現函數
static struct irqchip s3c_irqext_chip = {
.mask = s3c_irqext_mask,
.unmask = s3c_irqext_unmask,
.ack = s3c_irqext_ack,
.type = s3c_irqext_type
};
s3c_irqext_type就是linux內核需要的實現函數，而s3c_irqext_type在2.6.8中的實現為： static int s3c_irqext_type(unsigned int irq, unsigned int type)
{
irqdbf("s3c_irqext_type: called for irq %d, type %d\n", irq, type);
return 0;
}
原來並沒有實現。而在較高版本的內核，如2.6.26內核中，這個函數是實現了的。所以你一定要小心。當平台函數不好用時，一定要查查原因，或者直接操作硬體寄存器來達到目的。
● 2.6內核設備模型對驅動的影響
在2.6內核中寫設備驅動和在2.4內核中有著很大的不同，主要就是在設備驅動中融入了比設備驅動本身結構還復雜、還難以理解的設備模型。初學驅動時你可以不理會設備模型，但你會發現內核里的驅動代碼基本上都是融入了設備模型的了。所以很多時候你不得不面對現實，還是要弄懂它，並且它也的注冊方法也會隨著內核的升級而發生變化。解決此類問題的最好方法還是參考目標內核驅動代碼。

❸ linux下如何開發sdio設備驅動

以LinuxKernelSdioMx28 / LinuxKernelSdioMx53項目代碼為例：

- mole_init(DibBridgeTargetMoleInit)
驅動模塊初始化入口

- DibBridgeTargetMoleInit()：模塊初始化函數。
1.調用sdio_register_driver()注冊sdio介面驅動，
2.調用register_chrdev()注冊驅動模塊為字元設備。

- sdio_register_driver()：向系統注冊sdio介面驅動，調用以後，系統會觸發sdio設備id檢測，如果設備id和介面驅動里.id_table里定義的id一致，則系統調用probe函數。
1. 可以在DibBridgeTargetMoleInit()里調用，這樣insmod之後，驅動介面即被注冊（設備id被注冊），有相應設備插入則probe會被調用（此種做法參考LinuxKernelSdioMx28）
2. 也可以在sdio初始化時調用，這樣設備插入時，probe不會被調用，只有在sdio初始化，sdio_register_driver()被調用時，系統才會重新檢測設備id，並調用probe。（此種做法好處是，模塊初始化不涉及何種設備，具有更好的通用性。參考LinuxKernelSdioMx53）

- static struct sdio_driver Dib_sdio_driver
是sdio介面驅動的結構體,包括.id_table, .probe()函數等，如下
static struct sdio_driver Dib_sdio_driver = {
.name = "Dib_sdio",
.id_table = Dib_sdio_ids,
.probe = Dib_sdio_probe,
.remove = __devexit_p(Dib_sdio_remove),
};
其中.id_table很重要，它裡面定義了此sdio驅動模塊關心的sdio設備id號，只有插入的sdio設備的id號和這裡面定義的id對應上，系統才會調用.probe函數。

- register_chrdev()
將驅動模塊向系統注冊為字元設備，並將操作該設備的介面函數file_operations也一起注冊了。
1.可以在DibBridgeTargetMoleInit()里調用。（參考LinuxKernelSdioMx53/LinuxKernelSdioMx28代碼）
2.也可以在probe函數里調用，即只有在系統檢測到硬體設備時才去注冊字元設備（參考sdk8remote代碼）

- struct file_operations
包含如下最基本的文件操作函數，
struct file_operations fops =
{
.ioctl = DibBridgeTargetMoleIoctl, //控制命令傳輸或數據傳輸
.open = DibBridgeTargetMoleOpen,
.read = DibBridgeTargetMoleReadData, //數據傳輸
.write = DibBridgeTargetMoleWriteData
.release = DibBridgeTargetMoleRelease,
};

- .ioctl/.read 等等

user space和kernel space的傳輸通道，通過使用_from_user和_to_user這樣的函數來實現數據傳遞
Linux方面的想相關知識可以網路搜索《Linux就該這么學》進行學習了解