在上一篇文章中,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)境,我決定為開源固件庫 libopencm3 貢獻(xiàn) Vybrid 支持。該庫在 LGPL 版本 3 下獲得許可,因此明確允許將封閉源應(yīng)用程序與該庫鏈接。盡管它的名字,這個(gè)庫也支持各種 Cortex-M4 微控制器,因此它非常適合 Vybrid 的 Cortex-M4 內(nèi)核。使用該庫,我們可以利用對(duì) Cortex-M4 內(nèi)核外設(shè)的支持,例如系統(tǒng)滴答定時(shí)器或嵌套中斷控制器。有人可能會(huì)爭(zhēng)辯說,使用庫并不是真正的裸機(jī),但是由于庫的幾乎所有組件都是完全可選的,因此與使用完整的 RTOS 相比,它更接近于裸機(jī)。
該代碼尚未合并到上游項(xiàng)目中,但已經(jīng)可以從 Github 獲得(切換到 fsl-vf6xx 分支):https ://github.com/falstaff84/libopencm3和https://github.com/falstaff84/libopencm3-examples 。 此處的詳細(xì)構(gòu)建說明: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ǔ)器通常可在控制器的線性地址空間中訪問,從而允許它執(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)樗诔叽绾退俣确矫嫣峁┝肆己玫恼壑浴ow思卡爾提供了一份詳盡的文檔,討論了可用內(nèi)存類型的速度和建議(請(qǐng)參閱 AN4947,了解 Vybrid 架構(gòu))。
另一方面是 Cortex-M4 的哈佛式架構(gòu),它由兩條總線組成,一條用于數(shù)據(jù),一條用于指令。為了確保硬件相應(yīng)地使用這兩條總線,內(nèi)存映射提供別名以使用兩條總線訪問相同的內(nèi)存位置:
OC-RAM Code-Bus: 0x1f000000-0x1f03ffff
OC-RAM System-Bus: 0x3f000000-0x3f03ffff
為獲得最佳性能,應(yīng)在鏈接器文件的內(nèi)存描述中考慮到這一點(diǎn);libopencm3 庫定義了兩個(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) 來定義向量表的自定義位置。在上面的鏈接器文件中,向量表明確放置在固件的開頭。lib/vf6xx/vector_chipset.c 中的初始化代碼確保在啟動(dòng)時(shí)設(shè)置 VTOR 寄存器。
對(duì)于 Cortex-M4 微控制器,入口點(diǎn)(也稱為復(fù)位向量)是向量表的一部分。這引入了對(duì) Vybrid 的循環(huán)依賴,因?yàn)槲覀儚墓碳a中初始化向量表(無法從 Cortex-A5 內(nèi)核訪問 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 訪問。在本例中,這是 SRAM 的開始。但是,入口點(diǎn)地址是僅適用于 Cortex-M4 內(nèi)核的代碼總線別名。
由于 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è)可以從雙方訪問的共享內(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。可以下載最近的 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
審核編輯:郭婷
-
微控制器
+關(guān)注
關(guān)注
48文章
7908瀏覽量
153720 -
控制器
+關(guān)注
關(guān)注
114文章
16973瀏覽量
182975 -
寄存器
+關(guān)注
關(guān)注
31文章
5421瀏覽量
123398
發(fā)布評(píng)論請(qǐng)先 登錄
請(qǐng)問OpenVINO?工具套件是否支持使用非對(duì)稱卷積的支持模型?
分享!基于NXP i.MX 8M Plus平臺(tái)的OpenAMP核間通信方案

瑞芯微RK3568正式開放RISC-V核心啦,也支持非對(duì)稱AMP雙系統(tǒng)!

“國(guó)產(chǎn)雙系統(tǒng)”出爐!復(fù)旦微FMQL20SM非對(duì)稱AMP:Linux + 裸機(jī)

ARM + RISC-V核間通信方案,基于全志T113-i的OpenAMP非對(duì)稱架構(gòu)

Littelfuse推出新型TPSMB非對(duì)稱TVS二極管
Littelfuse推出TPSMB非對(duì)稱TVS二極管系列
“雙系統(tǒng)”出爐!瑞芯微RK3562J非對(duì)稱AMP:Linux+RTOS/裸機(jī)
對(duì)稱多處理器的特點(diǎn)是什么
對(duì)稱多處理器系統(tǒng)中的進(jìn)程分配包括
對(duì)稱多處理器和非對(duì)稱多處理器的區(qū)別
OPA828運(yùn)放非對(duì)稱電源供電有什么好處嗎?
TL084能否采用-5V和+ 32V的非對(duì)稱雙電源供電呢?
【本周六-上海】SMP對(duì)稱多處理 線下培訓(xùn)

評(píng)論