bootloader
關注創建者：匿名 創建時間：2022-02-22
bootloader的實例教程
一旦出現售后質量問題，如果召回的話，零部件供應商和整車廠將面臨嚴重的經濟損失，因此設計基于CAN總線的ECU在線程序更新Bootloader可以很好的解決這一問題，將零部件供應商和整車廠的損失降低到最小。目前國外大部分汽車整機廠（主機廠）和全球的一級汽車零部件供應商 (Tier 1) 都要求在其設計的ECU實現Bootloader功能。
圖1-3 Bootloader簡易框圖
假如使用CAN，框架則會設計成如圖1-3。
2.3 Bootloader框架
Bootloader由主機廠或者自己，可以選擇用或者不用，本次主要針對使用Bootloader情況進行分析。主機使用協議由自己進行定義，ECU啟動模式選擇由芯片廠商進行技術支持（如果沒有廠商支持是不可以的，是不被主機廠認可的，大多數是購買商業軟件包，由服務商進行技術支持與芯片廠商共同支持的）。內部編寫均需要遵循協議，大多數開發都是由多年開發經驗沉淀下來，修改而成的，協議依然在進步，代碼可能無法維護而無法支持，主機廠也會被迫選擇使用舊版協議。
圖1-4 Bootloader架構
2.4 ECU Bootloader原理
主機廠規定不可把擦寫內部代碼的功能直接寫入程序中，因此，只能每次用時才能將代碼放入ECU，ECU內部可以有Bootloader，但不可以有擦寫內部代碼的功能，擦寫代碼的功能稱作NVM (None Valitale Momory–非易失性存儲器)驅動程序。
圖1-5 NVM驅動示意圖
主機將NVM驅動程序下載到RAM區域，用NVM驅動程序對內部NVM進行擦除寫入新數據等，在最后跳轉即可完成更新。
展開 bootloader程序架構
略有簡化的bootloader圖
這張圖和恒潤教程中的BootLoader流程大體是一致的。
疑問點
Q:圖中的燒寫順序是34-36-34-36-34-36-37，但另一些材料中的順序是34-36-36-36-37。
A:這個問題這樣理解，34-36-36-36-37的前提是你要下載的數據是連續的數據，每個36所使用的地址信息，都是34中包含的地址信息再加上一定的偏移量。
如果需要下載不連續的數據，就需要重新進行34服務或31（擦除）-34服務。
1、為什么要搞Bootloader？為什么要基于UDS搞Bootloader
假如你的控制器有外殼，卻沒有設計bootloader的話，每次更新ECU的程序，你都需要把外殼拆開，用燒寫器來更新程序。有了bootloader，你就可以通過CAN線來更新程序了。更方便些的話，甚至可以通過OTA進行遠程升級。
那為什么使用UDS呢？主要是為了規范bootloader的全過程。比如燒寫小明牌ECU時，我們肯定希望其他牌子的ECU處于一個靜默的狀態，都歇一歇，這就需要一個大家共同執行的標準來進行規范，什么時候停發數據，什么時候不能再儲存DTC了等等。
又比如在調試時，大家肯定希望你的控制器經由CAN燒寫的過程是大家都能看得懂的，是滿足于某種規范的。由此，UDS在設計時考慮了bootloader的需求，專門為bootloader設計了幾個服務，供大家使用。主機廠在發需求時自然就要求大家要在UDS規范的基礎上完成bootloader功能了。
展開 2、BootLoader自更新需求
對于刷寫流程和刷寫規范，主機廠通常有自己的一套，而在開發階段，為了防止因早期boot中存在BUG而需要更新Boot，供應商通常會做Boot更新功能。
通常的做法是做兩級Boot，分別為供應商自己的Boot和主機廠的Boot，具體如圖1所示，其中SB為供應商自己的Boot，而CB為主機廠的Boot。除此之外還有其他很多方法，感興趣的可以戳回送門—>如何實現BootLoader自更新呢？
圖1 兩級boot
3、更新速率需求
在當前主機廠都在追求整車OTA能力的情形下，主機廠開始在意軟件的更新時間，盡量減少對用于的影響，也就是所謂的無感更新，提高用于體驗，畢竟誰也不想出現幾年前蔚來在長安街上等半天更新軟件情形。
對此需要熟讀芯片手冊的Flash部分以及數據下載協議，多為UDS，目前通常采用的方法就是Flash執行多頁寫入，采取最大化的連續幀數量，也就是減少流控制的數量，亦或是提高總線速率等。
BootLoader程序流設計
ECU上電后，程序從鏈接文件中定義的RESET入口進入Boot，Boot在做完基本的初始化之后，會檢查軟件刷新標志位和App有效標志位，如果有效，則停留在Boot中等待執行軟件刷寫任務，如果無效，則跳轉至App的入口地址，啟動App。Boot的具體流程圖如圖2所示。
圖2 Bootloader軟件流程圖
軟件刷新標志位被置位通常有兩種方式，其一為當App正常運行的時候，如果此時收到10 02切換至編程會話的命令，在App會將軟件刷新標志位進行置位，通常寫入至NVM，寫入成功后，軟件進行復位。
展開 其中引導加載程序(BootLoader)是系統加電后運行的第一段代碼，主要是通過設置寄存器初始化硬件的工作方式，如設置時鐘、中斷控制寄存器等，完成內存映射、初始化MMU等。其次是系統執行環境的初始化，將系統內核(Kernel)和應用程序的映像從只讀存儲器加載或拷貝到系統的RAM中執行，完成系統內核的加載以及應用程序的啟動等。
1.1 BootLoader的啟動
BootLoader是在操作系統內核運行之前運行的一段小程序，它可以初始化硬件設備、建立內存空間的映射圖，從而將系統的軟硬件環境帶到一個合適的狀態，為調用操作系統內核準備好環境。引導程序完成自己的任務后，就將控制權移交給內核。通常引導程序是放置在不易丟失的快閑存儲器的開始地址或者是系統冷啟動時PC寄存器的初始值。
1.2 內核啟動時加載過程
BootLoader按照Windows CE啟動方式的不同可分為2大類：下載模式和啟動加載模式。當BootLoader把nk.bin解壓到RAM后就把CPU控制權交給Windows CE內核。
啟動加載模式是BootLoader的正常加載模式，BootLoader從存儲介質將操作系統加載到RAM中，并從RAM中啟動運行操作系統。該過程并沒有用戶的介入。
下載模式則是BootLoader從開發工作站下載操作系統映像文件到目標設備的RAM，然后再將它寫到目標設備的FLASH等存儲介質中。該過程要通過串口線或網絡連接等通信手段從主機(Host)下載文件。因此，不同的加載模式會直接影響內核啟動加載時間。
2 影響Windows CE啟動速度的主要因素
影響系統啟動時間的因素可以從系統本身和硬件2個方面考慮。
展開 在嵌入式領域，根據嵌入式系統的MCU存儲結構和更新原理，提出了通過加密方式升級設備功能的方法，其中最常用的方法為BootLoader加密升級。
Bootloader 是在操作系統或用戶應用程序運行之前執行的一小段程序，通過這一小段程序，我們可以初始化硬件設備（如 CPU、SDRAM、Flash、串口等）、建立內存空間的映射表，從而將系統的軟硬件環境帶到一個合適的狀態，為最終調用操作系統內核或者用戶應用程序準備好正確的環境。
如何使用BootLoader加密升級可以防止競爭對手/惡意用戶獲得對固件代碼的訪問權限？
首先是使用代碼加密來保護固件。這里需要實現對稱密碼，以及私鑰的引導加載程序中的生成和包含。在制造商方面，需要保護相同的私鑰，用于加密新固件版本。如圖1所示，一般對稱加密算法流程。
圖1對稱加密算法流程
對于常見的AES-128加密算法，由于AES處理的單位是字節，128位的輸入明文或固件P和輸入的密鑰K都被分為16個字節，一般我們會將明文分組用字節為單位的正方形狀態矩陣來描述，在每一輪的算法中，狀態矩陣的內容不斷發生變化，最終的結果作為密文輸出。如圖2所示，AES-128分塊加密。
圖2 AES-128加密過程
AES算法是基于置換和代替的，置換是數據的重新排列，而代替是用一個單元數據替換另一個。
展開 
bootloader的相關專題、標簽、搜索
bootloader的最新內容
? 嵌入式控制器：這類控制器基于BootLoader進行刷寫，一般需要先執行擦除例程，再使用0x34、0x36、0x37服務請求進行文件寫入。
? 帶有文件管理系統的控制器：一般為使用OS操作系統的控制器，先使用0x38、0x36、0x37服務進行程序的下載，再由文件管理系統通過安裝例程進行安裝操作。
經緯恒潤可以為國產芯片提供MCAL開發、CDD開發、Bootloader開發、AutoSAR及OS適配、功能安全流程共建以及組件開發、信息安全組件開發、培訓服務等各種生態合作可能，為國產車規芯片賦能。
經緯恒潤國產芯片軟件生態合作圈，自建立以來，已經獲得了大批國產芯片廠商的積極支持。未來，我們希望能與更多優秀的國產芯片廠商成為合作伙伴，助力中國國產芯片行業高效、快速發展。
class1、class2、class3
接收靈敏度（典型值）DH1：-88dBm、2DH5：-88dBm、3DH5：-82dBm、BLE：-92dBm
支持 A2DP/AVRCP/HFP/HSP/OPP/HID/SPP/PBAP/GATT/SM 等協議支持PLC
固件燒錄和保護：
◆支持調試器、專用燒錄器或Flash Burner Lite燒錄 Flash
◆Bootloader
由此，UDS在設計時考慮了bootloader的需求，專門為bootloader設計了幾個服務，供大家使用。主機廠在發需求時自然就要求大家要在UDS規范的基礎上完成bootloader功能了。
2、Bootloader應支持的UDS服務
顯然bootloader不需要支持19/14等故障類服務。
即MCU采用bootloader單區+app雙區部署方式，bootloader一般沒有升級需求。因此，對MCU的升級過程只需要對雙區部署的APP進行即可。
其自主研發推出的AUTOSAR工具鏈為ORIENTAIS AUTOSAR，能為用戶提供了操作系統、底層驅動、通信協議棧、診斷協議棧、網絡管理、測量標定、復雜驅動、Bootloader 、FOTA 、功能安全、信息安全等基礎軟件模塊及集成開發環境。
- 外部燈光：遠光燈、近光燈、位置燈、轉向燈、前后霧燈、晝行燈、倒車燈、制動燈等
- 內部燈光：室內燈、背光燈、門燈等
- 雨刮洗滌系統、喇叭控制等
- 門控邏輯、胎壓監控等整車控制策略
- CAN和LIN通訊
- ISO15765診斷
- J1939_DM1診斷
- OSEK/AUTOSAR網絡管理
- BootLoader
圖1-3 Bootloader簡易框圖
假如使用CAN，框架則會設計成如圖1-3。
2.3 Bootloader框架
Bootloader由主機廠或者自己，可以選擇用或者不用，本次主要針對使用Bootloader情況進行分析。
產品功能
- 基本功能
報文 / 信號路由功能
速率轉換與協議翻譯
整車網絡相關診斷
網關自診斷
網絡管理
本地喚醒
Bootloader
開關采集
總線喚醒
- 特色功能
整車節點配置
整車數據信息備份
整車對外診斷接口
整車運輸模式控制
信息安全
產品特點
產品平臺化，
遠光燈、近光燈、小燈、轉向燈、前后霧燈、晝行燈、倒車燈、制動燈等
內部燈光：室內燈、背光燈、門燈
雨刮洗滌系統、喇叭控制等
自動空調控制、門控邏輯、胎壓監控、PEPS等整車控制策略
CAN / LIN通訊
預留以太網通訊
ISO15765 診斷
J1939_DM1 診斷
OSEK / AUTOSAR 網絡管理
BootLoader
