一，轉載：(6條消息) 關於驅動程序與BSP的區別_嵌入式Linux系統開發的博客-CSDN博客_bsp驅動
BSP即Board Support Package，板級支持包。它來源於嵌入式操作系統與硬件無關的設計思想，操作系統被設計為運行在虛擬的硬件平台上。對於具體的硬件平台，與硬件相關的代碼都被封裝在BSP中，由BSP向上提供虛擬的硬件平台，BSP與操作系統通過定義好的接口進行交互。BSP是所有與硬件相關的代碼體的集合。
BSP在嵌入式系統中的角色，很相似於在PC系統中的BIOS和驅動程序的地位。
BSP就看成BIOS+驅動或者bootloader+驅動
BSP和驅動的區別：bsp還包括了bootloader，或者bsp是包含了cpu、電源管理這些比驅動更深層次的硬件支持包。
驅動的話，一般崗位要求你熟悉IIC、SPI等通信協議呀什么的，讓你驅動某個外設，某個芯片。
1、BSP是一般是芯片原廠提供的，驅動是自己寫的。
2、bsp是保證os啟動前所作的必須工作，包括初始化工作，引導os啟動起來，也包括一些用戶的配置信息。 os啟動后，可以認為bsp已經不再起作用了，os會調相應的驅動來重新初始化系統。驅動可以認為是os內核中的一部分。
3、 BSP是嵌入式系統中介於硬件平台和操作系統之間的中間層軟件，主要目的是為了屏蔽底層硬件的多樣性，根據操作系統的要求完成對硬件的直接操作，向操作系統提供底層硬件信息並最終啟動操作系統。BSP具有硬件相關性和操作系統相關性的特點，其主要作用包括：
(1)初始化底層硬件，為操作系統提供底層硬件信息；
(2)初始化相關硬件設備，主要是存儲設備、通信設備；
(3)檢測系統硬件是否正常；
(4)加載操作系統並啟動系統運行。
4、BSP（Board Support Package），板級支持包，也稱為硬件抽象層HAL或者中間層。
它將系統上層軟件和底層硬件分離開來，使系統上層軟件開發人員無需關系底層硬件的具體情況，根據BSP層提供的接口開發即可。
BSP是相對於操作系統而言的，不同的操作系統有不同定義形式的BSP，要求BSP所實現的功能也有所不同。
在嵌入式Linux系統中，主要是初始化底層硬件並引導操作系統；同時，BSP又是和硬件相關的，還要考慮對硬件的初始化操作。這些初始化操作主要是對CPU、內存、中斷等相關的寄存器及協處理器進行正確的配置。
在不同的開發階段，因為核心和文件系統所處的位置不同，BSP所要完成的工 作也有所不同；在開發調試階段，BSP要能夠與主機通信並從主機下載核心；在目標產品中，BSP要能夠從非易失存儲設備中加載核心。
舉例
BSP驅動開發崗位職責
崗位職責:
負責Linux內核與驅動程序的開發維護工作,包括:
1、為新的硬件平台開發bootloader和firmware;
2、為新的硬件設計、開發和測試設備驅動,並撰寫文檔;
3、編寫、調試和測試設備驅動、各種協議棧(例如,USB,SATA,network,Wi-Fi,Streaming);
4、分析和解決在系統集成期間發現的問題;
5、優化Linux內核和驅動;
6、熟悉高通平台者優先
任職要求:
1、本科及以上學歷,計算機科學或相關專業;
2、 2年以上LINUX驅動經驗,熟悉嵌入式軟件調試實時操作系統;擁有豐富的ASM/C/C++開發經驗;熟悉ARM架構,ARM匯編,仿真器/ JTAG調試器;
3、熟悉LINUX和android體系架構者優先;
4、具備良好的職業素養和團隊協作精神,較強的學習和溝通能力。
參考：(6條消息) BSP_我還不懂，所以在學-CSDN博客
二，轉載：(6條消息) 【嵌入式系統】板級支持包BSP和硬件抽象層HAL的區別和關聯_歡迎光臨-CSDN博客
板級支持包（BSP）是介於主板硬件和操作系統中驅動層程序之間的一層，一般認為它屬於操作系統一部分，主要是實現對操作系統的支持，為上層的驅動程序提供訪問硬件設備寄存器的函數包，使之能夠更好的運行於硬件主板。在嵌入式系統軟件的組成中，就有BSP。BSP是相對於操作系統而言的，不同的操作系統對應於不同定義形式的BSP，例如VxWorks的BSP和Linux的BSP相對於某一CPU來說盡管實現的功能一樣，可是寫法和接口定義是完全不同的，所以寫BSP一定要按照該系統BSP的定義形式來寫（BSP的編程過程大多數是在某一個成型的BSP模板上進行修改）。這樣才能與上層OS保持正確的接口，良好的支持上層OS。
板級支持包BSP（Board Support Package）是外設、硬件的驅動軟件集合。單獨使用BSP即可在嵌入式系統上開發應用。BSP也可以按照規范編寫為操作系統（VxWorks、Linux等）提供接口。
但是由於日益增長的芯片種類和芯片復雜度，每種芯片的外設寄存器地址和控制方式都各不一樣，針對每種Board編寫BSP工作量很大。一般公司例如ST會提供HAl庫，用戶可以忽略寄存器的繁雜操作，直接調用HAL庫函數即可進行芯片內部外設操作，大大降低BSP軟件的開發周期。加入HAL庫之后的系統軟件結構如下圖所示：
引入HAL之后操作系統將會使用相對更為統一的HAL接口來實現對硬件的操作，而不是直接使用BSP庫。
hardware --> hardware abstract layer --> board support package --> driver --> operating system --> application
當然嵌入式系統中操作系統並不是必須的，並且在操作系統和應用程序之間可以在有一層中間件Middleware層，用於提供更多的系統功能，這個中間件Middleware層也被稱作SDK。
三，
SDK在基於BSP生成的。
過程大概是：安裝PB和相應的BSP，在BSP的基礎之上建立工程，進行CE定制。
定制完成后，先要編譯成功，然后才能生成SDK。
四，轉載：(6條消息) BootLoader,BSP,SDK嵌入式系統名詞_Mage的專欄-CSDN博客_bsp和sdk
BootLoader
一． BootLoader簡介
在專用的嵌入式板子運行GNU/Linux系統已經變得越來越流行。一個嵌入式Linux系統從軟件的角度看通常可以分為四個層次：
1、 引導加載程序。包括固化在固件(firmware)中的boot代碼(可選)，和BootLoader兩大部分。
2、 Linux內核。特定於嵌入式板子的定制內核以及內核的啟動參數。
3、 文件系統。包括根文件系統和建立於Flash內存設備之上文件系統。通常用ramdisk來作為rootfs。
4、 用戶應用程序。特定於用戶的應用程序。有時在用戶應用程序和內核層之間可能還會包括一個嵌入式圖形用戶界面。常用的嵌入式GUI有：MicroWindows和MiniGUI懂。
引導加載程序是系統加電后運行的第一段軟件代碼。PC機中的引導加載程序由BIOS(其本質就是一段固件程序)和位於硬盤MBR中的OS BootLoader（比如，LILO和GRUB等）一起組成。BIOS在完成硬件檢測和資源分配后，將硬盤MBR中的BootLoader讀到系統的RAM中，然后將控制權交給OS BootLoader。BootLoader的主要運行任務就是將內核映象從硬盤上讀到 RAM 中，然后跳轉到內核的入口點去運行，也即開始啟動操作系統。
而在嵌入式系統中，通常並沒有像BIOS那樣的固件程序（注，有的嵌入式CPU也會內嵌一段短小的啟動程序），因此整個系統的加載啟動任務就完全由BootLoader來完成。比如在一個基於ARM7TDMI core的嵌入式系統中，系統在上電或復位時通常都從地址0x00000000處開始執行，而在這個地址處安排的通常就是系統的BootLoader程序。
簡單地說，BootLoader就是在操作系統內核運行之前運行的一段小程序。通過這段小程序，我們可以初始化硬件設備、建立內存空間的映射圖，從而將系統的軟硬件環境帶到一個合適的狀態，以便為最終調用操作系統內核准備好正確的環境。
通常，BootLoader是嚴重地依賴於硬件而實現的，特別是在嵌入式世界。因此，在嵌入式世界里建立一個通用的BootLoader幾乎是不可能的。盡管如此，我們仍然可以對BootLoader歸納出一些通用的概念來，以指導用戶特定的BootLoader設計與實現。
二、常見bootloader介紹
1．U-BOOT介紹
uboot是一個龐大的公開源碼的軟件。他支持一些系列的arm體系，包含常見的外設的驅動，是一個功能強大的板極支持包。其代碼可以從http://sourceforge.net/projects/u-boot下載
U-BOOT是由PPCBOOT發展起來的，是PowerPC、ARM9、Xscale、X86等系統通用的Boot方案，從官方版本 0.3.2開始全面支持SC系列單板機。u-boot是一個open source的bootloader，目前版本是0.4.0。u-boot是在ppcboot以及armboot的基礎上發展而來，雖然宣稱是0.4.0版本，卻相當的成熟和穩定，已經在許多嵌入式系統開發過程中被采用。由於其開發源代碼，其支持的開發板眾多。唯一遺憾的是並不支持我們現在學習所用samsung 44B0X的開發板。
為什么我們需要u-boot？顯然可以將ucLinux直接燒入flash，從而不需要額外的引導裝載程序（bootloader）。但是從軟件升級的角度以及程序修補的來說，軟件的自動更新非常重要。事實上，引導裝載程序（bootloader）的用途不僅如此，但僅從軟件的自動更新的需要就說明我們的開發是必要的。
同時，u-boot移植的過程也是一個對嵌入式系統包括軟硬件以及操作系統加深理解的一個過程。
2。vivi介紹（下載地址http://www.mizi.com/developer）
vivi是韓國mizi 公司開發的bootloader, 適用於ARM9處理器。 Vivi有兩種工作模式：啟動加載模式和下載模式。啟動加載模式可以在一段時間后（這個時間可更改）自行啟動linux內核，這時vivi的默認模式。在下載模式下，vivi為用戶提供一個命令行接口，通過接口可以使用vivi提供的一些命令，如下：
命令
功能
Load
把二進制文件載入Flash或RAM
Part
操作MTD分區信息。顯示、增加、刪除、復位、保存MTD分區
Param
設置參數
Boot
啟動系統
Flash
管理Flash，如刪除Flash的數據
vivi代碼分析
vivi的代碼包括arch，init，lib，drivers和include等幾個目錄，共200多條文件。
Vivi主要包括下面幾個目錄：
arch：此目錄包括了所有vivi支持的目標板的子目錄，例如s3c2410目錄。
drivers：其中包括了引導內核需要的設備的驅動程序（MTD和串口）。MTD目錄下分map、nand和nor三個目錄。
init：這個目錄只有main.c和version.c兩個文件。和普通的C程序一樣，vivi將從main函數開始執行。
lib：一些平台公共的接口代碼，比如time.c里的udelay()和mdelay()。
include：頭文件的公共目錄，其中的s3c2410.h定義了這塊處理器的一些寄存器。Platform/smdk2410.h定義了與開發板相關的資源配置參數，我們往往只需要修改這個文件就可以配置目標板的參數，如波特率、引導參數、物理內存映射等。
BSP
BSP板級支持包（board support package），是介於主板硬件和操作系統中驅動層程序之間的一層，一般認為它屬於操作系統一部分，主要是實現對操作系統的支持，為上層的驅動程序提供訪問硬件設備寄存器的函數包，使之能夠更好的運行與硬件主板。在嵌入式系統軟件的組成中，就有BSP。BSP是相對於操作系統而言的，不同的操作系統對應於不同定義形式的BSP,例如VxWorks的BSP和Linux的BSP相對於某一CPU來說盡管實現的功能一樣，可是寫法和接口定義是完全不同的，所以寫BSP一定要按照該系統BSP的定義形式來寫（BSP的編程過程大多數是在某一個成型的BSP模板上進行修改）。這樣才能與上層OS保持正確的接口，良好的支持上層OS。
SDK
百科名片
SDK（Software Development Kit, 即軟件開發工具包 ）一般是一些被軟件工程師用於為特定的軟件包、軟件框架、硬件平台、操作系統等建立應用軟件的開發工具的集合。
基本信息
SDK，Software Development Kit 的縮寫，中文即“軟件開發工具包”。廣義上指輔助開發某一類軟件的相關文檔、范例和工具的集合。一般而言，SDK即開發 Windows 平台下的應用程序所使用的SDK。
相關背景
API
API”，也就是 Application Programming Interface，其實就是操作系統留給應用程序的一個調用接口，應用程序通過調用操作系統的 API 而使操作系統去執行應用程序的命令（動作）。其實早在 DOS 時代就有 API 的概念，只不過那個時候的 API 是以中斷調用的形式（INT 21h）提供的，在 DOS 下跑的應用程序都直接或間接的通過中斷調用來使用操作系統功能，比如將 AH 置為 30h 后調用 INT 21h 就可以得到 DOS 操作系統的版本號。而在 Windows 中，系統 API 是以函數調用的方式提供的。同樣是取得操作系統的版本號，在 Windows 中你所要做的就是調用 GetVersionEx() 函數。
可以這么說，DOS API 是“Thinking in 匯編語言”的，而 Windows API 則是“Thinking in 高級語言”的。
DOS API 是系統程序的一部分，他們與系統一同被載入內存並且可以通過中斷矢量表找到他們的入口，那么 Windows API 呢？要說明白這個問題就不得不引入我們下面要介紹得這個概念——DLL。
DLL
DLL，即 Dynamic Link Library（動態鏈接庫）。在windows環境下含有大量 .dll 格式的文件，這些文件就是動態鏈接庫文件，其實也是一種可執行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接執行，他們通常由 .exe 在執行時裝入，內含有一些資源以及可執行代碼等。其實 Windows 的三大模塊就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），里面就含有了 API 函數的執行代碼。為了使用 DLL 中的 API 函數， 必須要有 API 函數的聲明（.H）和其導入庫（.LIB），導入庫可以先這樣理解：導入庫是為了在 DLL 中找到 API 的入口點而使用的。
為了使用 API 函數，我們就要有跟 API 所對應的 .H 和 .LIB 文件，而 SDK 正是提供了一整套開發 Windows 應用程序所需的相關文件、范例和工具的“工具包”。。
SDK 包含了使用 API 的必需資料，所以人們也常把僅使用 API 來編寫 Windows 應用程序的開發方式叫做“SDK 編程”。而 API 和 SDK 是開發 Windows 應用程序所必需的東西，所以其它編程框架和類庫都是建立在它們之上的，比如 VCL 和 MFC，雖然他們比起“SDK 編程”來有着更高的抽象度，但這絲毫不妨礙它們在需要的時候隨時直接調用 API 函數 。