前端時(shí)間回來了一塊板子，于是各個(gè)團(tuán)隊(duì)都進(jìn)入了緊張的 Bringup 工作中。

這塊板子上的主芯片是一顆 Arm Cortex M3 + DSP 的異構(gòu)芯片，結(jié)構(gòu)大概是這樣的：

CM3 和 DSP 的固件獨(dú)立存儲(chǔ)在 Flash 中，上電后 CM3 先啟動(dòng)，然后 CM3 再把 DSP 的固件從 Flash 中加載到 Sram 中，最后再從 Sram 中拷貝到 DSP 的 ITCM 中，至于為什么不繞過 Sram 直接把 DSP 的固件從 Flash 中讀到 DSP 的 ITCM 中，我們這里先不討論。

Bringup 進(jìn)行到第二天的時(shí)候，負(fù)責(zé) DSP 的同學(xué)反饋說，DSP 的程序加載上去后，始終不能正常運(yùn)行 —— 觀察不到任何正常啟動(dòng)的現(xiàn)象。其實(shí)在 Bringup 剛開始階段，這種情況是經(jīng)常遇到的，我第一反應(yīng)就是，讓這位同學(xué)連上 DSP 的 JTAG 去單步調(diào)試，看到底發(fā)生了什么。

第三天的時(shí)候，我又找這位同學(xué)問了下，現(xiàn)在是什么情況了，這位同學(xué)一臉茫然的說：好奇怪，如果用 DSP 的 JTAG 直接下載固件到 ITCM，就能正常運(yùn)行，通過 Cortex M3 去加載，就不能正常運(yùn)行。聽到這個(gè)差別，我潛意識(shí)的問他：有沒有確認(rèn)過 CM3 加載到 ITCM 中的固件是否正常？這位同學(xué)說應(yīng)該不會(huì)有問題，這套流程他們之前在其他平臺(tái)上都驗(yàn)證過。他們還有一些其他的壞一點(diǎn)，準(zhǔn)備優(yōu)先就他們的懷疑點(diǎn)做一些實(shí)驗(yàn)排查，比如 DSP 的cache 啊，復(fù)位控制啊，PLL 頻率啊什么的。

因?yàn)?Bringup 階段事情比較多，我也就沒在追究去忙其他的事情了。

第四天，說所有懷疑的實(shí)驗(yàn)都做完了，還是沒進(jìn)展。我說確認(rèn)下 CM3 拷貝到 ITCM 里面的固件是否正常吧 —— CM3 把固件拷貝到 ITCM 后，在用 JTAG 讀出來，然后對(duì)比。

實(shí)驗(yàn)做完，這位同學(xué)蔫蔫的說，從 ITCM 中讀出來的固件數(shù)據(jù)和編譯出來的固件數(shù)據(jù)有一小部分對(duì)不上。而且這部分對(duì)上的數(shù)據(jù)位于固件尾巴上。

固件加載出錯(cuò)，程序肯定無法正常運(yùn)行！那就直接排查數(shù)據(jù)在哪個(gè)環(huán)節(jié)出錯(cuò)的吧！

固件從 Flash 中加載到 Sram 中后，也用 JTAG 讀出來和原始數(shù)據(jù)對(duì)比，結(jié)果正常！

那就是從 Sram 到 ITCM 的這個(gè)環(huán)節(jié)處了問題！

查看這段拷貝的代碼，原來就是一個(gè) rt_memcpy —— 我們?cè)?Cortex M3 上運(yùn)行的是 RT-Thread。

這位同學(xué)用 JLink 單步跟蹤這段代碼發(fā)現(xiàn)，每次程序運(yùn)行到第二部分的時(shí)候，拷貝就異常了，能看到程序執(zhí)行了，但是數(shù)據(jù)就是沒拷貝過去！而第一段的拷貝都是正常的。

事出異常必有妖，我決定反匯編看看這段代碼后面藏了什么玄機(jī)。

果真有貓膩，第一段代碼，對(duì)于大塊的 4 字節(jié)對(duì)齊的數(shù)據(jù)，CPU 是以 STR 這樣的指令超 ITCM 寫數(shù)據(jù)，即以 Word 為單位訪問 ITCM，對(duì)于第二段，也就是一段數(shù)據(jù)的尾巴，剩下的那些零零散的不夠四字節(jié)的數(shù)據(jù)，CPU 是以 STRB 這樣的指令超 ITCM 寫數(shù)據(jù)，即以字節(jié)為單位訪問 ITCM。

memcpy 這樣寫是為了提高數(shù)據(jù)搬運(yùn)的效率。對(duì)于按照 Word 對(duì)齊的數(shù)據(jù)，以 Word 的模式搬運(yùn)，對(duì)于剩下的非Word 對(duì)齊的數(shù)據(jù)，以 Byte 模式搬運(yùn)，一次搬運(yùn)四字節(jié)肯定比一次搬運(yùn)一字節(jié)要快。

但是我們這里踩了什么坑呢？以 Word 方式訪問 ITCM 就正常，以 Byte 的方式訪問就不成功？

為了進(jìn)一步確認(rèn)這個(gè)結(jié)論，我寫了一段測(cè)試代碼：

這段測(cè)試代碼構(gòu)造了一個(gè) memcpy 命令，我可以在命令行通過 memcpy cnt value 來控制每次超 ITCM 搬運(yùn)不同長度的數(shù)據(jù)，下面就開始測(cè)試：

一次寫 16 字節(jié)的 1 到 ITCM，然后通過 Jlink 可以看到 ITCM 這片區(qū)域被成功的寫入了 16 字節(jié)的 1。因?yàn)?16 是 4 個(gè) 4 字節(jié)，所以這次的 memcpy 是通過 STR 指令進(jìn)行的。

一次 copy 17 字節(jié)的 2 到 ITCM， 通過 JLink 觀察右下角的 ITCM，發(fā)現(xiàn)只寫進(jìn)去了 16 字節(jié)。根據(jù) memcpy 算法，前 16 字節(jié) 是以 Word 的形式通過 STR 指令寫入 ITCM 的，剩下的 一 字節(jié) 是以 STRB 的形式寫入 ITCM 的。

一次 Copy 18 字節(jié)，同樣發(fā)現(xiàn)只寫進(jìn)去了 16 字節(jié)。

一次 Copy 19 字節(jié)，還是只寫進(jìn)去了 16 字節(jié)！

一次 Copy 20 字節(jié)，全部寫入成功了！按照 memcpy 算法，20 字節(jié)是以 五次 STR 指令，以 Word 模式拷貝過去的。

一次 Copy 21 字節(jié)，發(fā)現(xiàn)還是只寫入了 20 字節(jié)！

一次 Copy 24 字節(jié)，全部拷貝成功！

到這里，我基本確認(rèn) Cortex M3 以 Byte 模式訪問 ITCM 會(huì)失?。?/p>

然后聯(lián)系 IC 設(shè)計(jì)方，確認(rèn)是什么原因。IC 設(shè)計(jì)方回復(fù)說：Cortex M3 確實(shí)無法以 Byte 模式訪問 ITCM，這是總線設(shè)計(jì)上限制的！

艾瑪呀！忽然有種想打人的沖動(dòng)，你文檔上根本沒提有這個(gè)限制?。?/p>

后來想想，在無數(shù)次的 Bringup 過程中，類似這種固件拷貝不完整的情況，似乎坑過我好幾次，有一次 Linux 內(nèi)核起來后，很多驅(qū)動(dòng)都加載失敗，我一路從 Linux Kernel 查找到 U-Boot，再查到下載，最后確認(rèn)是固件下載工具有問題，DTB 沒有下載完整，而且這尼瑪也是因?yàn)?flash 扇區(qū)對(duì)齊的問題導(dǎo)致的！還有一次從 U-Boot SPL 跳到 Arm turst firmware 后，總是卡死固定的位置，然后 Dump 發(fā)現(xiàn) ATF 固件加載不完整，最后確認(rèn)是 CLK 驅(qū)動(dòng)問題引起 eMMC 工作異常導(dǎo)致的。