米爾MYS-8MMX開發板試用體驗測評二

近期，米爾科技發布新品“MYS-8MMX”開發板的評測，吸引了廣大開發者的圍觀，上周小編在公眾號發布1篇優秀的測評報告，后臺收到了各位小伙伴的留言和咨詢，想必還有很多的疑問，為加深各位對米爾MYS-8MMX開發板的了解，再同步一篇電路城優秀測評者的測評報告，希望能幫助各位開發者縮短開發周期。

01

【米爾MYS-8MMX試用】重新編譯 uboot 添加網絡功能

筆者想用 nfs 文件系統，方便后續開發，試了一下開發板預裝系統uboot 不支持網絡功能，編譯前，不支持網絡

重新編譯 uboot 增加網絡功能：

編譯 uboot 的過程廢了點時間，由于米爾 SDK使用 yocto 作為開發工具，yocto是個集成的開發工具，功能大而全，好處多多，也有不方便的地方，國內工程師估計都知道，那就是拉取源碼太難了，筆者沒用 yocto 而是一個個單獨編譯，然后再手工打包，這個環節廢了點時間。

02

【米爾MYS-8MMX試用】跑起網絡文件系統Ubuntu20.04

跑起網絡服務器上的 ubuntu 20.04 系統，也就是把 uboot 放在 sd 卡上，其他的所有一切包括內核、驅動、設備樹、文件系統等等所有的東西都放在服務器上，這種方式好處很明顯，對開發過程極其友好，比如修改內核，服務器編譯后，板子重啟搞定，不用自己再把內核復制到板子上，比如修改設備樹，服務器編譯后，板子重啟搞定，不用自己復制，比如調整驅動，比如寫個應用程序，只要編譯完，服務器上有的東西，板子上也能找到，就是這么方便。

比如筆者的 SD 卡，只燒寫 flash.bin文件，甚至一個分區都不存在，因為筆者壓根就不用 SD 卡的任何分區，所以 SD 卡有沒有分區無所謂

Uubntu 文件系統在電腦上，在這里：

以下是啟動記錄：

boot_log.txt

到此，整個開發環境搭建起來了，所有鏡像和文件重新調整添加網絡文件系統支持，并編譯出來，編譯的所有文件全部調試驗證成功了，接下來可以愉快的開發了筆者整個編譯過程是一個個手工單獨編譯的，手工單獨編譯要對各個文件包有所了解，編譯過程是有點繁瑣，優勢也很明顯，速度很快，非常快，大約 20 分鐘就可以全部編譯一遍，如果是增量編譯，1分鐘內搞定，再加上網絡文件系統加成，1分鐘內編譯完重啟完看到驗證的結果；筆者后續會頻繁編譯內核，調整設備樹，編譯速度快就能快速迭代加快開發速度。用 yocto 編譯的話，省事方便，但是速度慢，如果公司配有很牛逼的開發服務器集群，那可以。

03

【米爾MYS-8MMX試用】修復WiFi上網功能

適配了自己的 ubuntu 20.04 文件系統，WiFi 無法正常使用，檢查了一下，是因為內核需要兩個文件，ubuntu 系統鏡像中沒有。

一個文件是 firmware，另一個文件是 nvram，在 eMMC 中原文件系統如下路徑中：

/lib/firmware/bcmd/fw_bcm43456c5_ag_apsta.bin

/lib/firmware/bcmd/nvram_ap6256.txt

直接從 eMMC 復制過來，復制到 nfs ubuntu 文件系統中同樣的路徑下

重啟生效，就能驅動了，也能連上 WiFi 網絡

文中提到的內容只是需要調整修改的，其他沒說的不用動。

兩個 USB 接口也可以使用了：

HDMI 顯示器也正常工作

網絡文件系統 ubuntu 20.04 基本就緒，沒啥大問題了

04

【米爾MYS-8MMX試用】如何向設備樹添加節點

本文重點內容有三個：1，驅動模型如何建立2，設備樹如何被解析3，在理解 1 和 2 基礎上，會很自然的理解如何向設備樹添加節點platform 驅動模型建立

內核驅動模型中有 bus，device，driver，分別對應 struct bus_type，struct device，struct device_driver 三個結構體，或者說三個對象也行，platform_bus , platform_device, platform_driver 是對 struct bus_type，struct device，struct device_driver 的繼承，可以把 platform 平臺看作是bus，device，driver的更高一級對象。

Platform 驅動中的 bus 和 device 是內核創建的，比如以下代碼，注冊了 platform_bus

有了 platform_bus 之后，需要有 platform_device ，platform_device 也是內核模塊的形式注冊的

of_platform_default_populate_init 這個函數解析設備樹，解析時有規則的，結合imx8mm 平臺來說，解析了以下所有節點及其一級子節點，也就是設備書中的以下節點創建了 device 設備，并且創建他們子節點的 device 設備，子節點再往下的節點，不解析不創建device，留作 platform_driver 去解析創建。(設備樹如何被解析)

有了 platform_bus 也創建了 platform_device 設備，還差 platform_driver，platform_driver 就是驅動，并且是 SoC 芯片級別的驅動，這個有芯片原廠搞定，比如imx8mm 有以下 platform_driver：這個是 sdma 的驅動，以此為例，其他類同。

Platform 平臺 bus，device，driver 幾乎全部有廠商提供，用戶基本是無感的。他默默在背后工作，但是初學者根本不知道他的存在。這是platform 平臺完整的驅動模型。

理解此文基礎上，再繼續看筆者往期文章才能理解 IIC 總線框架：

【ALINX AXU2CGB試用】從linux 驅動模型的角度看 iic 總線框架

https://www.cirmall.com/bbs/thread-208032-1-1.html

深入看 IIC 設備樹，i2c1 位于aips3 的一級子節點，i2c1 會被創建 platform_device，

I2c 驅動注冊為platform_driver：

內核一開始注冊了 platform_bus，也創建了 i2c1 的 platform_device，也注冊了i2c1的 platform_driver，組成一個完整的 platform 驅動模型，他們就會工作了,i2c 適配器/主機能正常工作了。

(文章中的 i2c 適配器，就是 i2c 主機，i2c 控制器，對應驅動中的 i2c adapter；文章中的 i2c 設備，是 i2c 從機，對應驅動中的 i2c client)

i2c 驅動模型建立

I2c 適配器用的 platform 平臺驅動模型，對你沒有看錯，筆者也么有寫錯，i2c 適配器用的 platform 平臺驅動模型，和 i2c 總線沒有半毛錢關系。

i2c 總線用在哪呢？用在 i2c 設備上。

I2c 適配器的 platform_driver 會去注冊 adapter

解析 adapter 所有子節點注冊為 i2c client 設備 (i2c device)，現在有了 i2c device

內核會注冊創建 i2c 總線

內核也會注冊 client 驅動(i2c driver)注冊，如下;

有 i2c 總線，有 i2c device設備(i2c client 設備)，有 i2c driver (i2c client 驅動)，組成一個完整的 i2c 總線模型，這個總線主要為 i2c 設備服務。

i2c 主機使用 platform 平臺總線，i2c 從機使用 i2c 總線，是不是很難理解？驅動源碼就是這樣的。

linux 內核驅動中的總線，并不是硬件中的總線，也不是傳輸信息的，而是為了設備和驅動更容易的適配的，是設備和驅動的一種組織形式。

最難理解的地方就是 i2c 主機和 i2c 從機沒使用同一個總線，分別使用了 platform 總線和 i2c 總線，能問出這個問題的根源是用硬件總線的概念去想當然的理解驅動中的總線，潛意識完全錯誤，硬件總線和驅動中的總線，完全是兩個東西，應該這么去理解：1，硬件中的總線，是傳輸信息的，硬件上主從機位于同一條 i2c 總線，主從機是可以通信的。

2，驅動中的總線僅僅是設備和驅動的組織形式，方便設備和驅動適配的。只要 i2c 主機設備和驅動適配 ok 主機就會工作，i2c 從機設備和驅動適配 ok 從機就會工作。分別使用了 platform 總線和 i2c 總線，并不影響 i2c 主機和 i2c 從機正常適配，正常工作。

結果就是 linux 驅動讓 i2c 主從機都可以正常工作，硬件讓主從機又能相互通信，那就可以了。

linux 驅動僅僅是讓硬件工作起來，別強求 i2c 主從機必須位于同一條總線，不在同一條總線沒關系；硬件的總線是通信的，i2c 主從機要想通信必須位于同一條總線，沒的商量。

platform 是 arm linux 驅動中最基礎的平臺，用的多，也最容易追蹤分析，是軟件中驅動模塊部分抽象出來的一種模型，用于組織設備和驅動的一種方式，其他 i2c ，spi 總線和 platform 平臺驅動模型類似各有差異，i2c 和 spi 驅動模型都是在 platform 平臺驅動中再次建立起來的，platform 平臺驅動注冊 i2c / spi 設備，和內核注冊的 i2c 總線、i2c driver 組成 i2c 驅動模型。

沒有 設備樹 對應的節點，就沒有 platform device，沒有 platform device 僅有 platform bus 和 platform driver 不能組成完整的驅動模型，就無法工作。無法工作，platform driver 就不能 match 就無法 probe，無法 probe 就不能添加 i2c device，僅有 i2c 總線和 i2c driver 不能組成i2c 總線完整的驅動模型，i2c 也就不能工作。所以向設備樹添加節點，很重要，相當于給驅動模型添加 device。

如何向設備樹添加節點設備樹，這個名字說明他的數據結構是樹，樹中的每個節點是設備。向設備樹中添加節點，就是向 linux 中添加設備，樹，就要求你添加到合適的位置，合適的層級。向設備樹添加節點是有規則的，規則是由設備樹被解析的規則決定的，內核怎么解析設備樹你就怎么添加添加設備節點，必須添加到指定位置添加自己的設備節點，必須添加到文中圖片列出的節點的一級子節點，二級和再深的節點，添加了也沒用，因為內核根本不去創建更深層次節點設備。也不是完全不可以，你添加后節點還是存在的，只存在設備樹中，驅動模型中是不存在，需要你自己去建立驅動模型。接下來筆者運用設備樹等不同的方法自己創建一條總線，建立起這個總線的驅動模型，讓設備和驅動正常適配、probe、正常工作起來。

長按二維碼 關注我們