引導加載程序和固件常見用法和固件升級

Question

在嵌入式系統上工作有兩種情況。 嵌入式系統的資源有限，例如帶有12 K閃存的ARM Cortex M0微控制器。

案例1： 常用功能/模塊使用的引導程序和固件： 引導程序和固件可能需要使用相同的模塊和功能，以防止代碼重複。否則，相同的代碼將包含固件和Bootloader兩次。 我們可以通過指定函數地址來防止這種情況，並通過調用地址函數來調用該函數。這是解決方案之一。

有沒有什麼聰明的方法來提供常見的功能用法？

案例2： 有時候，我們需要升級固件。引導程序的職責之一是固件升級。我們可以通過覆蓋舊版本來輕鬆升級固件。

正如我們所看到的，兩種情況可以分開實施。但是當我們合併它們時，會出現一些問題。

問題： 引導加載程序通常是靜態對象，但固件是可以修改的。因此，通用函數通常位於Bootloader中。但是當我們需要更新一個通用模塊/功能時，我們該怎麼做？

什麼是通用或智能方法哪個引導程序，固件結構化的嵌入式系統？另外，對於有限的資源。

對於離散的通用模塊/功能，可以有一個或多個附加區域解決此問題。 固件，引導加載程序和庫（新區域）？

我想學習一般方法。有沒有關於高級固件管理的文章，書籍和源文件？

感謝

Answer 1

如果你分享你的bootloader和你的主線固件應用之間的代碼，那麼你的引導程序將在它閃爍的應用空間使用此代碼。爲了防止這種情況，您必須犧牲更新通用代碼的能力，否則您的引導加載程序將崩潰。

只有12k的閃存，期待引導加載程序和主線應用程序的安裝非常有雄心。你可以考慮用匯編語言編寫引導程序（gasp！）。某些Cortex M0部件（如恩智浦LPC11xx系列）具有一個額外的引導ROM，用於存儲一些有用的功能，並有助於緩解一些內存限制。

Answer 2

你的問題正確指出了問題 - 你不能吃你的蛋糕和它。或者：
1.您需要佔用較小的內存，並且不要在引導加載程序中包含固件升級邏輯（即引導加載程序可能只是驗證應用程序圖像CRC等，但不會更復雜）。在這裏你可以共享功能來節省空間。 OR
2.自舉程序具有固件升級功能。在這裏，您必須將共享函數編譯到應用程序和引導加載程序中。共享功能應該很小 - 可能不是一個巨大的開銷，但你需要這個空間 - 如果你沒有它，那麼你需要去尋找更多的內存。
無法可靠地共享功能並從bootloader進行固件升級。

Answer 3

在當前討論的燈在固件更新過程約安全我想補充以下澄清：引導裝載程序和應用程序將打開另一個門的潛在攻擊之間 共享代碼，所以你真的想避免這種情況。

引導加載程序部分是您實際上不想更改的部分，它應該儘可能靜態。如果引導加載程序中斷，則現場更新幾乎變得不可能或至少不安全。

話雖如此，您可能想要使用不同的方法。 您可以爲您的設備創建維護模式。 該模式打開JTAG接口並允許直接訪問內存。比服務技術人員可以應用更新。

現在你「只」需要保護維護模式的激活。 以下內容可以工作： 使用UART接口傳輸激活。

1. 維護系統發送它自己的ID，並通過UART
請求維護模式
2. 維護系統，隨機數和獨特的系統ID的ID被送回維修系統。
3. 維護系統將此序列號發送到您的認證服務器。
4. 如果唯一的系統ID和維護系統ID是正確的，服務器將創建收到的信息的簽名並將其發送回維護系統。
5. 您的系統現在將通過UART接收簽名
6. 您的系統驗證與生產
7. 期間存儲在一個全成驗證維護模式的公鑰對先前發送ID字符串簽名輸入

爲了增加安全性，您肯定希望按照類似的方案在維護系統ID中付出一些努力。該ID應基本上取決於MAC地址或另一個唯一的硬件ID和相同的簽名。在維護系統的生產過程中，應該在安全的環境中創建ID。唯一的硬件ID應該是外部可見的東西，所以服務器可以實際驗證接收的ID是否與維護系統與服務器通信相匹配。

這整個設置將給你一個安全的固件更新，無需引導程序。 要獲得安全的固件更新，常見的理解是，您需要基於非對稱加密（如RSA）的認證系統。如果您仍然需要驗證碼，上面將通過一個簡單的UART接口來交換能夠接受更新的引導加載程序，從而節省一些資源。

這是你正在尋找的東西嗎？

根據我的經驗，一個商業啓動引導程序使用4到8k的閃存，具體取決於閃存算法和其他一些事情。我一直堅持使用同一家供應商，因此這可能與您的經驗有所不同。

針對嵌入式系統優化的數字簽名系統在閃存中使用大約4.5kByte（例如，請參閱：https://www.segger.com/emlib-emsecure.html），並且不會有比堆棧更多的RAM。

你會發現，12k的系統真的很低，可以在現場進行安全更新。更甚者，如果您希望使用引導加載程序更新系統。