在上一篇文章中，Valter Minute 討論了總體架構(gòu)以及非對(duì)稱（也稱為異構(gòu)）多核 SoC 的優(yōu)勢(shì)。對(duì)于次要 Cortex-M4 內(nèi)核的操作平臺(tái)有多種選擇：Valter 文章中討論的示例使用 eCos RTOS，飛思卡爾推廣自己的 RTOS MQX。

然而，根據(jù)應(yīng)用程序的不同，人們甚至可能更喜歡裸機(jī)解決方案，例如移植舊版固件或?yàn)榱似浜?jiǎn)單性。但是，也有缺點(diǎn)，最突出的是缺少外圍設(shè)備的驅(qū)動(dòng)程序。本文展示了為 Vybrid 的 Cortex-M4 內(nèi)核創(chuàng)建定制的裸機(jī)固件時(shí)的一些技術(shù)缺陷。

作為一個(gè)示例環(huán)境，我決定為開(kāi)源固件庫(kù) libopencm3 貢獻(xiàn) Vybrid 支持。該庫(kù)在 LGPL 版本 3 下獲得許可，因此明確允許將封閉源應(yīng)用程序與該庫(kù)鏈接。盡管它的名字，這個(gè)庫(kù)也支持各種 Cortex-M4 微控制器，因此它非常適合 Vybrid 的 Cortex-M4 內(nèi)核。使用該庫(kù)，我們可以利用對(duì) Cortex-M4 內(nèi)核外設(shè)的支持，例如系統(tǒng)滴答定時(shí)器或嵌套中斷控制器。有人可能會(huì)爭(zhēng)辯說(shuō)，使用庫(kù)并不是真正的裸機(jī)，但是由于庫(kù)的幾乎所有組件都是完全可選的，因此與使用完整的 RTOS 相比，它更接近于裸機(jī)。

該代碼尚未合并到上游項(xiàng)目中，但已經(jīng)可以從 Github 獲得（切換到 fsl-vf6xx 分支）：https ：//github.com/falstaff84/libopencm3和https://github.com/falstaff84/libopencm3-examples 。 此處的詳細(xì)構(gòu)建說(shuō)明：http： //falstaff.agner.ch/2014/07/10/libopencm3-bare-metal-vybrid-examples/

內(nèi)存和閃存

標(biāo)準(zhǔn)微控制器和 Vybrid 的 Cortex-M4 之間的第一個(gè)也是最顯著的區(qū)別是不同的內(nèi)存和閃存架構(gòu)。在微控制器上，非易失性存儲(chǔ)器通常可在控制器的線性地址空間中訪問(wèn)，從而允許它執(zhí)行就地固件 （XIP）。在 Vybrid 上，非易失性內(nèi)存通常不會(huì)以允許其就地執(zhí)行的方式實(shí)現(xiàn)。相反，固件由主操作系統(tǒng)（例如 Linux）從存儲(chǔ)介質(zhì)（例如 NAND 閃存）加載到 RAM 中，隨后由 Cortex-M4 內(nèi)核執(zhí)行。

有不少于三種內(nèi)存類型可供運(yùn)行：緊密耦合內(nèi)存、片上內(nèi)存 （OC-RAM/SRAM） 和外部 （DDR） 內(nèi)存。緊密耦合內(nèi)存 （TCM） 是可用的最快內(nèi)存，因?yàn)樗苯舆B接到 Cortex-M4 內(nèi)核。但是，可用的內(nèi)存量也非常有限。片上存儲(chǔ)器 SRAM 是一種流行的選擇，因?yàn)樗诔叽绾退俣确矫嫣峁┝肆己玫恼壑浴ｏw思卡爾提供了一份詳盡的文檔，討論了可用內(nèi)存類型的速度和建議（請(qǐng)參閱 AN4947，了解 Vybrid 架構(gòu)）。

另一方面是 Cortex-M4 的哈佛式架構(gòu)，它由兩條總線組成，一條用于數(shù)據(jù)，一條用于指令。為了確保硬件相應(yīng)地使用這兩條總線，內(nèi)存映射提供別名以使用兩條總線訪問(wèn)相同的內(nèi)存位置：

OC-RAM Code-Bus： 0x1f000000-0x1f03ffff

OC-RAM System-Bus： 0x3f000000-0x3f03ffff

為獲得最佳性能，應(yīng)在鏈接器文件的內(nèi)存描述中考慮到這一點(diǎn)；libopencm3 庫(kù)定義了兩個(gè)內(nèi)存區(qū)域，代碼總線 （pc_ram） 和系統(tǒng)總線 （ps_ram）。在以下示例中，可用內(nèi)存被分成兩半，每個(gè)部分有 256K 的 RAM。由于地址是整個(gè)內(nèi)存范圍的別名，因此可以根據(jù)項(xiàng)目需要自由調(diào)整這兩個(gè)部分的大小。

鏈接器控制文件片段：examples/vf6xx/colibri-vf61/colibri-vf61.ld

MEMORY

{

pc_ram （rwx） ： ORIGIN = 0x1f000000， LENGTH = 256K

ps_ram （rwx） ： ORIGIN = 0x3f040000， LENGTH = 256K

}

在節(jié)部分，我們需要將代碼節(jié)（文本）和數(shù)據(jù)節(jié)（例如 bss）的位置分配給這兩個(gè)內(nèi)存區(qū)域。

鏈接器控制文件片段：lib/vf6xx/libopencm3_vf6xx.ld

SECTIONS

{

.text ： {

*（.vectors） /* Vector table */

。 = ALIGN（0x400）;

*（.text.reset_handler） /* Force reset handler at start */

*（.text*） /* Program code */

。 = ALIGN（4）;

} 》pc_ram

。..

.bss ： {

*（.bss*） /* Read-write zero initialized data */

*（COMMON）

。 = ALIGN（4）;

_ebss = 。;

} 》ps_ram

。..

}

向量表和入口地址

另一個(gè)重要方面是向量（中斷）表。在 Cortex-M4 上，向量表0x00000000在復(fù)位時(shí)讀取。在微控制器上，這通常位于非易失性存儲(chǔ)器中。在 Vybrid 上，Cortex-M4 內(nèi)核最初是關(guān)閉的。在固件的初始化代碼中，我們可以使用向量表偏移寄存器 （VTOR） 來(lái)定義向量表的自定義位置。在上面的鏈接器文件中，向量表明確放置在固件的開(kāi)頭。lib/vf6xx/vector_chipset.c 中的初始化代碼確保在啟動(dòng)時(shí)設(shè)置 VTOR 寄存器。

對(duì)于 Cortex-M4 微控制器，入口點(diǎn)（也稱為復(fù)位向量）是向量表的一部分。這引入了對(duì) Vybrid 的循環(huán)依賴，因?yàn)槲覀儚墓碳a中初始化向量表（無(wú)法從 Cortex-A5 內(nèi)核訪問(wèn) VTOR 寄存器）。為了解決這個(gè)難題，輔助內(nèi)核的入口點(diǎn)（“復(fù)位向量”）由系統(tǒng)復(fù)位控制器 （SRC） 模塊的寄存器在外部定義。對(duì)于飛思卡爾的啟動(dòng)實(shí)用程序“mqxboot”，在 Cortex-A5 內(nèi)核上運(yùn)行的 mcc 內(nèi)核模塊中的啟動(dòng)實(shí)現(xiàn)可確保相應(yīng)地設(shè)置此寄存器。用戶需要將入口點(diǎn)作為參數(shù)傳遞給“mqxboot”。注意：地址需要將位 0 設(shè)置為 1，以告訴 CPU 目標(biāo)是 Thumb 代碼（另請(qǐng)參閱參考手冊(cè)的“運(yùn)行輔助內(nèi)核”一章）。

例如，要將固件 demo.bin 加載到 SRAM 并在輔助內(nèi)核上啟動(dòng)它，可以在主內(nèi)核上運(yùn)行的 Linux 上使用 mqxboot：

mqxboot

mqxboot demo.bin 0x3f000000 0x1f000401

加載地址需要可從 Cortex-A5 訪問(wèn)。在本例中，這是 SRAM 的開(kāi)始。但是，入口點(diǎn)地址是僅適用于 Cortex-M4 內(nèi)核的代碼總線別名。

時(shí)鐘

由于 Cortex-M4 在源自 Cortex-A5 內(nèi)核時(shí)鐘的系統(tǒng)時(shí)鐘上運(yùn)行，因此從 Cortex-M4 側(cè)更改時(shí)鐘并不是一個(gè)好主意。然而，為了計(jì)算時(shí)序，讀取時(shí)鐘寄存器以獲得當(dāng)前速度是必要的。在libopencm3中，計(jì)算邏輯在lib/vf6xx/ccm.c下實(shí)現(xiàn)。主要時(shí)鐘是 ARM 內(nèi)核時(shí)鐘 （ccm_core_clk）、平臺(tái)總線時(shí)鐘（也是 Cortex-M4 內(nèi)核時(shí)鐘 （ccm_platform_bus_clk） 以及 IPS（外設(shè)）時(shí)鐘 （ccm_ipg_bus_clk））。

溝通

另一方面是與運(yùn)行在 Cortex-A5 上的主操作系統(tǒng)進(jìn)行通信的通信基礎(chǔ)設(shè)施。libopencm3 實(shí)現(xiàn)目前不支持通信?？赡茏詈?jiǎn)單的通信實(shí)現(xiàn)是定義一個(gè)可以從雙方訪問(wèn)的共享內(nèi)存區(qū)域（考慮使用使用獨(dú)占加載/存儲(chǔ)指令 LDREX/STREX 的同步機(jī)制）。更復(fù)雜一點(diǎn)的是 MQX RTOS 的多核通信 （MCC） 組件的實(shí)現(xiàn)。該組件利用硬件信號(hào)量模塊 （SEMA4） 以及四個(gè) CPU 到 CPU 中斷之一在有新消息可用時(shí)通知另一個(gè) CPU?？梢韵螺d最近的 MQX 版本（4.0.2 及更高版本）以獲取 MCC 的源代碼（驗(yàn)證許可證是否涵蓋您的用例）。

結(jié)論

在 Vybrid 上移植或?qū)崿F(xiàn)裸機(jī)固件是可能的，而且不是很復(fù)雜。畢竟，Vybrid 內(nèi)部的 Cortex-M4 仍然是執(zhí)行 ARMv7-M 架構(gòu)的 Cortex-M4 內(nèi)核。除了外圍驅(qū)動(dòng)程序，鏈接器文件以及初始設(shè)置代碼需要一些特殊考慮。

作者：Stefan Agner， Toradex

審核編輯：郭婷