【米尔MYS-8MMX开发板免费试用】+6.A53和M4双核通讯功能验证，分析

一、双核通讯功能验证
1.1TF卡方式A53和M4双核上电自动启动
    因为是试用的板子，所以自己没有尝试EMMC方式启动开发板，而坚持试用TFka方式，但是自己的TF卡1.8v的电压下，写功能异常，不得已只能将修改uboot的代码来默认支持A53和M4双核同时上电启动
2.uboot支持TF卡方式A53和M4双核上电自动启动
2.11uboot源代码修改  


2.2编译方法
    参考前面源代码编译的帖子。
2.3运行结果验证
    注意g7f045b4301代表的意义，“g”首字母后是uboot上git log的ID。


3.imx8mm-rpmsg框架分析
    Remote Processor Messaging (rpmsg) Framework，这是kernel中帮忙文件对rpmsg的定义。它的出现主要是为了满足多核异构CPU之间通讯的需求。
    随着时代的发展，人们对CPU的性能和功耗有越来越高的要求，多核异构架构应运而生。多核异构在手机CPU上尤其如此，将日常功能和通话功能分开在不同的CPU上处理，可以很好的获得性能和低功耗的平衡。
    rpmsg最初是由TI的工程师提出，很快应用到各个领域，当然人们也根据自己的需求进行修改。
    rpmsg是基于virtio消息传输机制，允许内核与远程处理器进行通讯。
3.1rpmsg框架加载过程
    rpmsg框架遵循linux总线，设备和驱动设备模型，下一个会详细分析一下。
    另外rpmsg是以virtio为基础，而virtio也是遵循linux总线，设备和驱动设备模型，而且virtio框架本身也由一些处理，这里不详细分析，下一节详细分析。

• 1rpmsg_init，可以理解为bus部分加载
• imx_rpmsg_init，可以理解driver部分加载
• virtio和virtio_ringinit，这里是为rpms做准备，包括rpmsg的bus，driver以及后面的device部分。
• 此时rpmsg框架可以正常使用了，我这次一直 卡在dev/ttyRPMSG30设备节点创建，为啥是30？跟TI的CPU的设备节点，跟imx6ul的设备节点都不一样。
  

3.2/dev/ttyRPMSG30设备节点创建过程分析
    rpmsg_tty_probe函数中使用tty_register_driver创建这个设备节点，这个很容易理解，那30是怎么来的呢？
    追代码找到rpmsg_recv_done，这里突然30就出现了，但是花费几天的时间还是没有找到正确的来源。
3.3A53和M4通讯功能验证
3.3.1modprobe imx_rpmsg_tty命令
    这个命令用来加载rpmsg设备的驱动，rpmsg_tty_probe函数被调用，同时会发送一个“hello world!”的字符串， 如果此时M4接了串口就可以看到这个字符串被接收。我这里没有给M4接串口，所以没有double check，但是理论上应该是这样的。
3.3.2输入echo "this is a test from toradex" > /dev/ttyRPMSG3
    输出是：xdxs is a test from toradex，输入和输出不对应，这个是在M4中做了简单处理。
二、双核通讯原理分析

1.A53和M4双核CPU启动原理分析
1.1单核CPU启动原理分析
    单独的ARM-A53和arm-M4，有很多资料对这两者的启动流程都有比较清晰的说明，而且应该比较容易找到。
    这里我说一下自己的理解，总的来说CPU的启动是硬件和软件共同协作的结果，硬件上CPU的内置ram里面一段非常小的bootrom来加载核外的ram里面的bootloader，这个bootloader可以很简单直接启动M4，也可以很复杂uboot启动linux-kernel，这里需要明确CPU核内ram必须保证上电可以启动。
    一旦这个ram有了问题会咋样？很简单，这个CPU或者这个IC就是不量产品，IC的良率是好坏芯片的比率。良率跟IC设计的RTL代码质量有关系，跟代工厂的水平有关系，跟IC的面积有关系，跟IC加工的ns数有关系，据说面积是最大的影响因子
    良率的问题可以给大家一个参考指标，比如40ns 1M ram的良率大约是80%。
1.2双核CPU启动原理分析
    下面说说我做过的M3启动hifi的大概过程:
            首先，将hifi的固件转化为二进制数据写入到指定内存中，将这个首地址写入到hifi的config寄存器中，然后在hifi的reset寄存器中写入1，不出意外，hifi就会启动，可以通过一些诸如串口或者内存变化来确定hifi系统启动起来。
    A53启动M4过程类似，0x007E0000应该对应上面的首地址，而reset寄存器操作则是在arch_auxiliary_core_up函数，看代码也是对某些bit进行读写操作，具体流程可以结合M4的启动流程来分析，我这里不做详细分析。

2.双核通讯机制硬件基础
    双核通讯硬件基础通过下图可以直观的看出来，很简单就是一段可以同时访问的内存，当然要想安全的快捷的通讯，就需要添加很多功能实现，后面有时间我在仔细研究分享。

3.M4部分通讯功能代码实现
3.1源代码
   米尔提供的代码比较简单，不能满足需求，在网上可以找到一个很不错的源代码，估计是NXP官方的参考代码，看看下面的代码中LOCAL_EPT_ADDR定义，还有RPMSG_LITE_NS_ANNOUNCE_STRING的定义，跟kernel中的定义是呼应的，修改一下代码，可以确认两者是通过rpmsg机制关联在一起，而且LOCAL_EPT_ADDR定义是通过rpmsg传递给kernel，创建了合适的设备节点。

1. #define RPMSG_LITE_SHMEM_BASE         (VDEV0_VRING_BASE)
   
2. #define RPMSG_LITE_LINK_ID            (RL_PLATFORM_IMX8MM_M4_USER_LINK_ID)
   
3. #define RPMSG_LITE_NS_ANNOUNCE_STRING "rpmsg-virtual-tty-channel-1"
   
4. #define APP_TASK_STACK_SIZE (256)
   
5. #ifndef LOCAL_EPT_ADDR
   
6. #define LOCAL_EPT_ADDR (30)
   
7. #endif

复制代码

   另外也可以添加一个验证，代码如下：

1.   app_buf[0] = 'x';
   
2.                 app_buf[1] = 'd';
   
3.                 app_buf[2] = 'x';

复制代码

   对应的输出log如下：

1. root@mys-8mmx:~# [   83.908035] [drivers/rpmsg/imx_rpmsg_tty.c rpmsg_tty_cb 56] cbuf=xdxs is a test from toradexedesktop.systemd1.Manager len=27

复制代码

4.rpmsg框架原理分析
三、总结
    因为时间和水平关系，这里就写这么多，写试用帖子，真的很锻炼人的水平，但是因为还有本职工作，所以这次投入时间不算多，而且比较零散，希望后面可以抽时间把本次试用的所有目标都完成。

0