再來一份關(guān)于米爾MYS-8MMX開發(fā)板試用體驗測評報告——robe.zhang

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

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

01

【米爾MYS-8MMX試用】重新編譯 uboot 添加網(wǎng)絡(luò)功能

筆者想用 nfs 文件系統(tǒng)，方便后續(xù)開發(fā)，試了一下開發(fā)板預(yù)裝系統(tǒng)uboot 不支持網(wǎng)絡(luò)功能，編譯前，不支持網(wǎng)絡(luò)

重新編譯 uboot 增加網(wǎng)絡(luò)功能：

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

02

【米爾MYS-8MMX試用】跑起網(wǎng)絡(luò)文件系統(tǒng)Ubuntu20.04

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

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

Uubntu 文件系統(tǒng)在電腦上，在這里：

以下是啟動記錄：

boot_log.txt

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

03

【米爾MYS-8MMX試用】修復(fù)WiFi上網(wǎng)功能

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

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

/lib/firmware/bcmd/fw_bcm43456c5_ag_apsta.bin

/lib/firmware/bcmd/nvram_ap6256.txt

直接從 eMMC 復(fù)制過來，復(fù)制到 nfs ubuntu 文件系統(tǒng)中同樣的路徑下

重啟生效，就能驅(qū)動了，也能連上 WiFi 網(wǎng)絡(luò)

文中提到的內(nèi)容只是需要調(diào)整修改的，其他沒說的不用動。

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

HDMI 顯示器也正常工作

網(wǎng)絡(luò)文件系統(tǒng) ubuntu 20.04 基本就緒，沒啥大問題了

04

【米爾MYS-8MMX試用】如何向設(shè)備樹添加節(jié)點

本文重點內(nèi)容有三個：1，驅(qū)動模型如何建立2，設(shè)備樹如何被解析3，在理解 1 和 2 基礎(chǔ)上，會很自然的理解如何向設(shè)備樹添加節(jié)點platform 驅(qū)動模型建立

內(nèi)核驅(qū)動模型中有 bus，device，driver，分別對應(yīng) struct bus_type，struct device，struct device_driver 三個結(jié)構(gòu)體，或者說三個對象也行，platform_bus , platform_device, platform_driver 是對 struct bus_type，struct device，struct device_driver 的繼承，可以把 platform 平臺看作是bus，device，driver的更高一級對象。

Platform 驅(qū)動中的 bus 和 device 是內(nèi)核創(chuàng)建的，比如以下代碼，注冊了 platform_bus

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

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

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

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

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

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

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

深入看 IIC 設(shè)備樹，i2c1 位于aips3 的一級子節(jié)點，i2c1 會被創(chuàng)建 platform_device，

I2c 驅(qū)動注冊為platform_driver：

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

(文章中的 i2c 適配器，就是 i2c 主機，i2c 控制器，對應(yīng)驅(qū)動中的 i2c adapter；文章中的 i2c 設(shè)備，是 i2c 從機，對應(yīng)驅(qū)動中的 i2c client)

i2c 驅(qū)動模型建立

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

i2c 總線用在哪呢？用在 i2c 設(shè)備上。

I2c 適配器的 platform_driver 會去注冊 adapter

解析 adapter 所有子節(jié)點注冊為 i2c client 設(shè)備 (i2c device)，現(xiàn)在有了 i2c device

內(nèi)核會注冊創(chuàng)建 i2c 總線

內(nèi)核也會注冊 client 驅(qū)動(i2c driver)注冊，如下;

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

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

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

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

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

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

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

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

沒有 設(shè)備樹 對應(yīng)的節(jié)點，就沒有 platform device，沒有 platform device 僅有 platform bus 和 platform driver 不能組成完整的驅(qū)動模型，就無法工作。無法工作，platform driver 就不能 match 就無法 probe，無法 probe 就不能添加 i2c device，僅有 i2c 總線和 i2c driver 不能組成i2c 總線完整的驅(qū)動模型，i2c 也就不能工作。所以向設(shè)備樹添加節(jié)點，很重要，相當(dāng)于給驅(qū)動模型添加 device。

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

長按二維碼 關(guān)注我們