軟硬件介紹

CPU：雙核Coretx-A7 + Cortex-M33的多核異構(gòu)芯片
Cortex-M33：已移植好了rt-thread，相關(guān)的硬件外設(shè)由Cortex-M33負責初始化。
Cortex-M33負責啟動Cortex-A7

目標
支持浮點 FPU
支持 NEON
支持MMU
rt-thread 開啟SMP能正常運行
coremark、內(nèi)存讀寫等跑分測試達到相同等級硬件平臺的水平

移植步驟

一、參考合適的BSP

選擇參考bsp目錄下qemu-vexpress-a9的代碼，因為cortex-A9體和cortex-A7差異不大，而且這個bsp默認開啟了SMP，對移植有一定的價值。
這個bsp 是在qemu下運行的，外設(shè)相關(guān)的依賴比較少，可以避免一些坑。

二、編譯運行

找到參考的bsp后，首先要修改link.lds腳本中的鏈接地址，因為每個平臺的代碼運行空間不一樣。
將. = 0x60010000;
修改為. = 0x3c000000; //這個地址類似于STM32H750的0x08000000
MMU配置，MMU的初始化大佬們已經(jīng)整好了，我只需要在board.c中改一下頁表配置,將原來qemu A9的改成現(xiàn)在平臺的
struct mem_desc platform_mem_desc[] = {
{0x00000000, 0xFFFFFFFF-1, 0x00000000, NORMAL_MEM},
{0x50000000, 0x50300000-1, 0x50000000, DEVICE_MEM}, // SRAM
{0x3C000000, 0x3C800000-1, 0x3C000000, NORMAL_MEM}, // PSRAM 代碼空間
{0x40000000, 0x40100000-1, 0x40000000, DEVICE_MEM}, // peripheral 外設(shè)空間
};

添加打印日志的代碼，開始采用寫共享內(nèi)存，由M33輪訓(xùn)并輸出的方式，事實證明這種方式?jīng)]有串口輸出更直接，對調(diào)試效率造成了一定的影響， 所以一種好用得調(diào)試手段很重要。如果有JTAG或者SWD這種接口，就先把這種調(diào)試環(huán)境搭建起來，不要想偷懶，人生沒有捷徑。因為后面遇到棘手的問題，這些高級的調(diào)試手段，會事半功倍。

去除掉一些和外設(shè)相關(guān)的代碼，編譯運行（滿懷歡喜的等待），結(jié)果沒跑起來，繼續(xù)查原因，這里折騰了一周多。

三、踩坑過程

本來想著大佬們已經(jīng)把體系相關(guān)的整好了，如GIC初始化、中斷的壓棧，進程調(diào)度等，到我這里就是簡單的改改，事實證明，工資不是那么好拿的，需要掉點頭發(fā)。

1. 通過日志查看，代碼能運行到rtthread_startup中，但是有個很詭異的情況。增加或者刪除日志打印的代碼后，有時能進入，有時候不能，這玩意顛覆認知啊。事實證明這世界沒有鬼的，這種問題一般都是和硬件有關(guān)，經(jīng)過一周多的時間終于發(fā)現(xiàn)了，原來我手上的cortex-a7雙核啟動與qemu-vexpress-a9不一樣。

qemu-vexpress-a9啟動流程

關(guān)鍵代碼實現(xiàn)：

void rt_hw_secondary_cpu_up(void)
{
extern void set_secondary_cpu_boot_address(void);
set_secondary_cpu_boot_address();
asm volatile ("dsb":::"memory");
rt_hw_ipi_send(0, 1 << 1);
}
void secondary_cpu_c_start(void)
{
rt_hw_vector_init();
rt_hw_spin_lock(&_cpus_lock);
arm_gic_cpu_init(0, REALVIEW_GIC_CPU_BASE);
arm_gic_set_cpu(0, IRQ_PBA8_TIMER0_1, 0x2);
timer_init(0, 10000);
rt_hw_interrupt_install(IRQ_PBA8_TIMER0_1, rt_hw_timer2_isr, RT_NULL, "tick");
rt_hw_interrupt_umask(IRQ_PBA8_TIMER0_1);
rt_system_scheduler_start();
}

友商雙核cortex-A7啟動流程

從啟動流程可以看出，我手上的這個cortex-a7在啟動時，兩個核心啟動時是運行的同一份代碼，導(dǎo)致了整個代碼運行全亂了，出現(xiàn)了很多詭異的現(xiàn)象，所以需要修改啟動代碼。

修改啟動代碼，插入對cpu 編號的判斷

//讀取cpu編號
@ get cpu id, and subtract the offset from the stacks base address
MRC P15, 0, R5, C0, C0, 5 @ read multiprocessor affinity register
AND R5, R5, #3 @ mask off, leaving CPU ID field

CMP R5, #0
BEQ normal_setup //CPU0 跳轉(zhuǎn)到正常啟動流程

//下面是cpu1的流程

ifdef RT_USING_SMP
ldr r0, =secondary_cpu_entry
mov r1, #0
str r1, [r0] / clean secondary_cpu_entry /

endif / RT_USING_SMP /
secondary_loop:
@ cpu core 1 goes into sleep until core 0 wakeup it
wfe //休眠，等待cpu0 發(fā)送sev事件

ifdef RT_USING_SMP
ldr r1, =secondary_cpu_entry
ldr r0, [r1]
cmp r0, #0
//跳轉(zhuǎn)到CPU0設(shè)置的入口地址
blxne r0 /* if(secondary_cpu_entry) secondary_cpu_entry(); */
endif / RT_USING_SMP /
b secondary_loop
##### 2. 解決完了啟動問題后，每次都能正常進入到`rt_hw_board_init`中了,這個函數(shù)一般在board.c中實現(xiàn)，每個芯片會有一些差異。
```c
/**
 * This function will initialize beaglebone board
 */
void rt_hw_board_init(void)
{
    /* initialize hardware interrupt */
    rt_hw_interrupt_init();
    /* initialize system heap */
    rt_system_heap_init(heap_start, &heap_start[heap_len/sizeof(uint32_t)]);
    //rt_system_heap_init(HEAP_BEGIN, HEAP_END);
    rt_components_board_init();
    //SystemClock_Init();
    rt_console_set_device(RT_CONSOLE_DEVICE_NAME);
    rt_thread_idle_sethook(idle_wfi);
    rt_hw_systick_init(RT_TICK_PER_SECOND);
#ifdef RT_USING_SMP
    /* install IPI handle */
    rt_hw_ipi_handler_install(RT_SCHEDULE_IPI, rt_scheduler_ipi_handler);
#endif
}
結(jié)果在調(diào)用rt_hw_interrupt_init 時掛了，繼續(xù)加日志打印唄。

/**
 * This function will initialize hardware interrupt
 */
void rt_hw_interrupt_init(void)
{
    rt_uint32_t gic_cpu_base;
    rt_uint32_t gic_dist_base;
    rt_uint32_t gic_irq_start;
    /* initialize vector table */
    rt_hw_vector_init();
    /* initialize exceptions table */
    rt_memset(isr_table, 0x00, sizeof(isr_table));
    /* initialize ARM GIC */
    gic_dist_base = platform_get_gic_dist_base();
    gic_cpu_base = platform_get_gic_cpu_base();
    gic_irq_start = GIC_IRQ_START;
    arm_gic_dist_init(0, gic_dist_base, gic_irq_start);
    arm_gic_cpu_init(0, gic_cpu_base);
}
日志顯示，是在arm_gic_dist_init(0, gic_dist_base, gic_irq_start); 這句代碼掛了，是訪問了GIC控制器的基地址，等等GIC控制器基地址不應(yīng)該都是一樣的嗎，我的第一反應(yīng)這些屬于arm的應(yīng)該都一樣。既然掛了，就得查資料, 最后在Cortex-A7 MPCore Technical Reference Manual中看到描述。
*
The GIC registers are memory-mapped, and the base address is specified by PERIPHBASE[39:15]. This input must be tied to a constant value. The PERIPHBASE value is sampled during reset into the Configuration Base Address (CBAR) for each processor in the cluster. See Configuration Base Address Register on page 4-83.

果然這里有毒，需要讀取CBAR寄存器獲取GIC基地址，bsp引用的是realview.h中定義好的。

#define REALVIEW_GIC_CPU_BASE       0x1E000100  /* Generic interrupt controller CPU interface */
#define REALVIEW_GIC_DIST_BASE      0x1E001000  /* Generic interrupt controller distributor */
CBAR寄存器是通過CP15協(xié)處理訪問，具體指令如下：

MRC p15, 4, r0, c15, c0, 0 ;
讀出來果然不是0x1E000100，更新GIC基地址后能過了。到這里兩個周過去了，emmm，忍無可忍了，我終于把串口打印整上了，出現(xiàn)異常是又可以看到熟悉的打印了，真香。

3. 到這里串口能看到熟悉的shell了。
  | /
- RT -     Thread Operating System
 / |      4.0.3 build Apr 10 2021
 2006 - 2021 Copyright by rt-thread team
hello rt-thread
msh >
4. 前面都是在單核下運行的，現(xiàn)在使能SMP。惴惴不安，使能SMP后，main線程不運行，代碼如下：
int main(void)
{
    int count = 0;
    printf("hello rt-threadn");
    rt_kprintf("a7 mian up %srn", __TIME__);
    while (1)
    {
        rt_kprintf("a7 mian loop %drn", count);
        count++;
        rt_thread_delay(1000);
        if(count > 10000)
        {
            break;
        }
    }
    return 0;
}
  | /
- RT -     Thread Operating System
 / |      4.0.3 build Apr 10 2021
 2006 - 2021 Copyright by rt-thread team
hello rt-thread
a7 mian up 06:1s: 3 >
a7 mian loop 0
沒有實現(xiàn)1s打印一次的效果，直覺是中斷沒有觸發(fā)，卡死在rt_thread_delay中了。經(jīng)過幾天的排查，發(fā)現(xiàn)在mmu配置忘記把定時器相關(guān)的地址段配置成設(shè)備內(nèi)存屬性，導(dǎo)致定時器有時候沒有初始化成功。
細節(jié)很重要, 這個問題在移植前期MMU配置就有異常，粗心把問題放過去了，后面導(dǎo)致涉及的點太多，排查了很久。

內(nèi)存段宏定義
```c
define DESC_SEC (0x2)
define MEMWBWA ((1< 12)|(3< 2)) / write back, write allocate /
define MEMWB (3< 2) / write back, no write allocate /
define MEMWT (2< 2) / write through, no write allocate /
define SHAREDEVICE (1< 2) / shared device /
define STRONGORDER (0< 2) / strong ordered /
define XN (1< 4) / eXecute Never /
define AP_RW (3< 10) / supervisor=RW, user=RW /
define AP_RO (2< 10) / supervisor=RW, user=RO /
define SHARED (1< 16) / shareable /
define DOMAIN_FAULT (0x0)
define DOMAIN_CHK (0x1)
define DOMAIN_NOTCHK (0x3)
define DOMAIN0 (0x0< 5)
define DOMAIN1 (0x1< 5)
define DOMAIN0_ATTR (DOMAIN_CHK< 0)
define DOMAIN1_ATTR (DOMAIN_FAULT< 2)
/ device mapping type /

define DEVICE_MEM (SHARED|AP_RW|DOMAIN0|SHAREDEVICE|DESC_SEC|XN)
/ normal memory mapping type /

define NORMAL_MEM (SHARED|AP_RW|DOMAIN0|MEMWBWA|DESC_SEC)
* mmu頁表配置， `rt_hw_init_mmu_table`初始化時使用
struct mem_desc platform_mem_desc[] = {
{0x00000000, 0xFFFFFFFF-1, 0x00000000, NORMAL_MEM},
{0x50000000, 0x50300000-1, 0x50000000, DEVICE_MEM}, // SRAM
{0x3C000000, 0x3C800000-1, 0x3C000000, NORMAL_MEM}, // PSRAM
{0x40000000, 0x40100000-1, 0x40000000, DEVICE_MEM}, // peripheral
{0x58000000, 0x58100000-1, 0x58000000, DEVICE_MEM}, // 定時器地址空間的內(nèi)存描述
{0x58300000, 0x58400000-1, 0x58300000, DEVICE_MEM},
};

經(jīng)過增加`0x58000000` 定時器外設(shè)基地址的的描述后，在每次都能穩(wěn)定運行了。
##### 5. neon使能
a7是需要跑算法的，所以neon必須打開，將`rtconfig.py`編譯參數(shù)修改下。
* qemu A9 BSP中的原參數(shù)
import os

DEVICE = ‘ -march=armv7-a -marm -msoft-float’

* 使能neon后的參數(shù)
import os

DEVICE = ‘ -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -ftree-vectorize -mfloat-abi=softfp -ffunction-sections -fdata-sections ‘

* 參數(shù)介紹, [neon編譯參數(shù)介紹](https://blog.csdn.net/u014470361/article/details/87931856)
Cortex-A7
-mcpu=cortex-a7
-mfpu=vfpv4
-mfpu=vfpv4-d16
-mfpu=neon-vfpv4 // 使能neon與vfp編譯
-fp16表明支持16bit半精度浮點操作

運行就炸了，哎，仰天長嘆。
```c
  | /
- RT -     Thread Operating System
 / |      4.0.3 build Apr  6 2021
 2006 - 2020 Copyright by rt-thread team
undefined instruction:
Execption:
r00:0x00000000 r01:0x3c0447a8 r02:0x3c03bbac r03:0x3c0446dc
r04:0xdeadbeef r05:0xdeadbeef r06:0xdeadbeef r07:0xdeadbeef
r08:0xdeadbeef r09:0xdeadbeef r10:0xdeadbeef
fp :0x3c044704 ip :0xfefefeff
sp :0x3c0446d8 lr :0x3c002228 pc :0x3c0360bc
cpsr:0x80000013
thread   pri  status      sp     stack size max used left tick  error
-------- ---  ------- ---------- ----------  ------  ---------- ---
sys_work  23  ready   0x00000044 0x00000800    03%   0x0000000a 000
mmcsd_de  22  ready   0x00000044 0x00000400    06%   0x00000014 000
tidle0    31  ready   0x00000048 0x00000400    07%   0x00000020 000
timer      4  suspend 0x0000007c 0x00000400    12%   0x0000000a 000
main      10  running 0x00000044 0x00000800    15%   0x00000014 000
shutdown...
反匯編看看掛掉的地方是啥，反匯編關(guān)鍵代碼：

3c0360a8 < rt_soft_rtc_init >:
3c0360a8:    e92d4800     push    {fp, lr}
3c0360ac:    e28db004     add    fp, sp, #4
3c0360b0:    e24dd028     sub    sp, sp, #40    ; 0x28
3c0360b4:    e24b3028     sub    r3, fp, #40    ; 0x28
3c0360b8:    f2c00050     vmov.i32    q8, #0    ; 0x00000000   //大致在這個位置掛掉了
3c0360bc:    f4430a0f     vst1.8    {d16-d17}, [r3]
3c0360c0:    f26021b0     vorr    d18, d16, d16
3c0360c4:    edc32b04     vstr    d18, [r3, #16]
3c0360c8:    f26021b0     vorr    d18, d16, d16
3c0360cc:    edc32b06     vstr    d18, [r3, #24]
3c0360d0:    edc30b07     vstr    d16, [r3, #28]
從pc :0x3c0360bc 向上查找可疑地方（arm流水線的原因PC值總比執(zhí)行的值大一些），看到3c0360b8處的代碼是一個vmov指令，帶V開頭的是neon與fpu的指令。這里證明neon編譯參數(shù)是OK的，那就是系統(tǒng)配置選項可能沒開，看了下RT_USING_FPU定義了。

日志顯示進入未定義指令中斷了，去看看

void rt_hw_trap_undef(struct rt_hw_exp_stack *regs)
{
#ifdef RT_USING_FPU
  {
      uint32_t ins;
      uint32_t addr;
      if (regs- >cpsr & (1 < < 5))
      {
          /* thumb mode */
          addr = regs- >pc - 2;
          ins = (uint32_t)*(uint16_t*)addr;
          if ((ins & (3 < < 11)) != 0)
          {
              /* 32 bit ins */
              ins < <= 16;
              ins += *(uint16_t*)(addr + 2);
          }
      }
      else
      {
          addr = regs- >pc - 4;
          ins = *(uint32_t*)addr;
      }
      if ((ins & 0xe00) == 0xa00)
      {
          /* float ins */
          uint32_t val = (1U < < 30);
          asm volatile ("vmsr fpexc, %0"::"r"(val):"memory");
          regs- >pc = addr;
          return;
      }
  }
#endif
  rt_kprintf("undefined instruction:n");
  rt_hw_show_register(regs);
#ifdef RT_USING_FINSH
  list_thread();
#endif
  rt_hw_cpu_shutdown();
}
這段代碼我找大佬問了下，大佬解釋說這是rt-thread為了節(jié)約?？臻g和壓棧的時間，默認沒開FPU，當產(chǎn)生異常時通過指令判斷是不是neon或者vfp指令造成的異常，是就開啟FPU，沒有用到neon和vfp的任務(wù)就不會開啟，確實是一個很巧妙的操作。

3c0360b8:    f2c00050     vmov.i32    q8, #0    ; 0x00000000 //異常的指令
//指令判斷條件
if ((ins & 0xe00) == 0xa00)
{
  /* float ins */
  uint32_t val = (1U < < 30);  //使能FPU
  asm volatile ("vmsr fpexc, %0"::"r"(val):"memory");
  regs- >pc = addr;
  return;
}
通過對比原判段條件不能覆蓋到所有的neon和fpu指令，所以直接改成判斷FPU是否開啟，如果開啟過還有異常，那就是真的未定義指令。優(yōu)化后的代碼:

uint32_t val;
asm volatile (“vmrs %0, fpexc” : “=r”(val)::”memory”);

if (!(val & 0x40000000))
{
/ float ins /
val = (1U << 30);

asm volatile ("vmsr fpexc, %0"::"r"(val):"memory");
regs->pc = addr;
return;
}

修改完畢后能正常啟動了。

6. 內(nèi)存性能測試

基礎(chǔ)系統(tǒng)的移植完成后，還需要性能測試保證移植的質(zhì)量，這里又搞了接近兩周。

• 內(nèi)存讀寫測試，使用的是軟件包中的MemoryPerf。

• 因為開始SMP使能后有問題，第一輪測試時沒有開啟SMP，測試結(jié)果為。	平臺	8bit讀寫(M/s)	16bit讀寫(M/s)	32bit讀寫(M/s)
  其他rtos同平臺	303.9 / 725.6	533.6 / 765.4	595.8 / 765.4
  rt-thread	5.3 / 15.9	10.6 / 31.9	21.2 / 63.7
  與相同平臺的其他rtos的測試結(jié)果對比差距很大，沒辦法只能對比原廠bsp，無數(shù)次測試后沒有效果。最后在cortex-A7的手冊中發(fā)現(xiàn)，開啟SMP是使能dcache的前提條件，然后開啟SMP。

mrc p15, 0, r1, c1, c0, 1
mov r0, #(1< 6)
orr r1, r0
mcr p15, 0, r1, c1, c0, 1 //enable smp

開啟后性能提升20多倍，但還有差距，原因后面慢慢到來。現(xiàn)在有點查不動了，跑個coremark。

7. coremark跑分測試
   coremark跑分也是使用的軟件包的工具Coremark，居然還有這么多小工具，不用自己擼了，對rt-thread愛意增加100分。

rt-thread跑分結(jié)果

Benchmark started, please make sure it runs for at least 10s.
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 16865
Total time (secs): 16
Iterations/Sec : 625
Iterations : 10000
Compiler version : GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags :
Memory location : STACK
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x988c
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 625 / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] / STACK
msh / >

結(jié)果625分，總感覺哪里不對，去[coremark網(wǎng)站](https://www.eembc.org/coremark/scores.php)看看其他的平臺跑分，居然還沒有stm32H7的跑分高，瑟瑟發(fā)抖，感覺無法說服領(lǐng)導(dǎo)了。還是需要對比下，在同平臺的其他rtos也跑一下。
```c
Benchmark started, please make sure it runs for at least 10s.
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 35038
Total time (secs): 35
Iterations/Sec   : 2857
Iterations       : 100000
Compiler version : GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags   : 
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0xd340
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 2857 / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
2875分，這個分數(shù)就很正常了，下面就查原因了，這時第4周已經(jīng)要結(jié)束了。

原因分析: 這時候系統(tǒng)已經(jīng)能穩(wěn)定運行，只是性能比較差，那是不是CPU主頻設(shè)置不對呢？接下來詢問原廠的兄弟，等待回復(fù)中。
這時不能閑著，反匯編代碼看看bsp在cortex-a7里面干了什么，屏蔽掉時鐘部分的設(shè)置，最后將測試代碼提前到匯編啟動代碼中，測出來分數(shù)還是2857分。完犢子了，路子完全走錯了。
最后想到，會不會是代碼優(yōu)化等級的問題，現(xiàn)在用的是-o0編譯，改成-o2整一把，跑分2941分了。沒想到優(yōu)化等級會造成5倍差距，認知不夠，被領(lǐng)導(dǎo)狠批了一頓（兩周前就叫看看的）。

Benchmark started, please make sure it runs for at least 10s.
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 17287
Total time (secs): 17
Iterations/Sec : 2941
Iterations : 50000
Compiler version : GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags :
Memory location : STACK
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0xa14c
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 2941 / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] / STACK

• rt-thread 編譯等級的修改在rtconfig.py，設(shè)置BUILD = 'release'就可以了。

python
import os
BUILD = 'debug'

generate debug info in all cases

AFLAGS += ' -gdwarf-2'
CFLAGS += ' -g -gdwarf-2'
if BUILD == 'debug':
CFLAGS += ' -O0'
else:
CFLAGS += ' -O2'

7. 收尾

上面還留了一個小尾巴，內(nèi)存性能測試有差距，最后在開啟SMP, -O2編譯的情況下測試一下。

內(nèi)存讀寫也正常了，到現(xiàn)在移植完成，所有的指標完成。