韌體公升級相關接觸與request firmware

產品在送樣除錯後，測試發現的問題需要解決和優化，可以除錯單樣品，也可以整機除錯（整機公升級韌體）。

我不清楚有多少種韌體公升級方法，接觸的幾個是 *.h、*.i、*.bin、*.img 等。前兩個放入驅動中，後兩者提供介面由應用層呼叫執行（不知是否正確）。

有人說高通平台採用img方式，去了解了一下，發現此乃較嚴謹的商業做法趨向。

前兩種的思路大致如下：

你可能想解決韌體問題使用這樣的乙個宣告

static char my_firmware = ;

但是, 這個方法幾乎肯定是乙個錯誤. 將韌體編碼到乙個驅動擴大了驅動的**, 使韌體公升級困難, 並且非常可能產生許可問題. **商不可能已經發布韌體映象在 gpl 之下, 因此和 gpl-許可的**混合常常是乙個錯誤. 為此, 包含內嵌韌體的驅動不可能被接受到主流核心或者被 linux 發布者包含.

後兩者在實際中得到了大力賞識和「正道」之稱，便接觸到了我此時最為關注的函式 request_firmware

正確的方法是當你需要它時從使用者空間獲取它. 但是, 請抵制試圖從核心空間直接開啟包含韌體的檔案的**; 那是乙個易出錯的操作, 並且它安放了策略(以乙個檔名的形式)到核心. 相反, 正確的方法時使用韌體介面, 它就是為此而建立的:

#include int request_firmware(const struct firmware **fw, char *name, 
struct device *device);

呼叫 request_firmware 要求使用者空間定位並提供乙個韌體映象給核心; 我們一會兒看它如何工作的細節. name 應當標識需要的韌體; 正常的用法是**者提供的韌體檔名. 某些象 my_firmware.bin 的名子是典型的. 如果韌體被成功載入, 返回值是 0(負責常用的錯誤碼被返回), 並且 fw 引數指向乙個這些結構:

struct firmware ;

在你已經傳送韌體到裝置前, 你應當釋放 in-kernel 結構, 使用:

void release_firmware(struct firmware *fw);

因為 request_firmware 請求使用者空間來幫忙, 它保證在返回前睡眠. 如果你的驅動當它必須請求韌體時不在睡眠的位置, 非同步的替代方法可能要使用:

int request_firmware_nowait(struct module *module,
char *name, struct device *device, void *context,
void (*cont)(const struct firmware *fw, void *context));

這裡額外的引數是 moudle( 它將一直是 this_module), context (乙個韌體子系統不使用的私有資料指標), 和 cont. 如果都進行順利, request_firmware_nowait 開始韌體載入過程並且返回 0. 在將來某個時間, cont 將用載入的結果被呼叫. 如果由於某些原因韌體載入失敗, fw 是 null.

韌體子系統使用 sysfs 和熱插拔機制. 當呼叫 request_firmware, 乙個新目錄在 /sys/class/firmware 下使用你的驅動的名子被建立. 那個目錄包含 3 個屬性:

這個屬性應當被載入韌體的使用者空間程序設定為 1. 當載入程序完成, 它應當設為 0. 寫乙個值 -1 到 loading 會中止韌體載入程序.

data

data 是乙個二進位制的接收韌體資料自身的屬性. 在設定 loading 後, 使用者空間程序應當寫韌體到這個屬性.

device

這個屬性是乙個符號連線到 /sys/devices 下面的被關聯入口項.

一旦建立了 sysfs 入口項, 核心為你的裝置產生乙個熱插拔事件. 傳遞給熱插拔處理者的環境包括乙個變數 firmware, 它被設定為提供給 request_firmware 的名子. 這個處理者應當定位韌體檔案, 並且拷貝它到核心使用提供的屬性. 如果這個檔案無法找到, 處理者應當設定 loading 屬性為 -1.

如果乙個韌體請求在 10 秒內沒有被服務, 核心就放棄並返回乙個失敗狀態給驅動. 超時週期可通過 sysfs 屬性 /sys/class/firmware/timeout 屬性改變.

使用 request_firmware 介面允許你隨你的驅動發布裝置韌體. 當正確地整合到熱插拔機制, 韌體載入子系統允許裝置簡化工作"在盒子之外" 顯然這是處理問題的最好方法.

請允許我們提出多一條警告: 裝置韌體沒有製造商的許可不應當發布. 許多製造商會同意在合理的條款下許可它們的韌體, 如果客氣地請求. 無論如何, 在沒有許可時拷貝和發布它們的韌體是對版權法的破壞並且招致麻煩.

由個人需要，參考他人之言，至於此處，形成成長流水日記。

韌體公升級相關接觸與request firmware

韌體公升級 A9韌體公升級來啦！！！

韌體公升級思路

韌體公升級 DFU OTA

韌體公升級相關接觸與request firmware

韌體公升級 A9韌體公升級來啦！！！

韌體公升級思路

韌體公升級 DFU OTA

相關推薦