Melis3.0系统Quick Start
Melis3.0系统是全志科技面向数字媒体和IoT领域的轻量级物联网嵌入式实时操作系统，主打视频多媒体编,解,录周边产品应用。在整合内部开发资源的基础上， 与开源社区深度合作，致力建立服务于多媒体，语音的端侧基础设施平台. Melis3.0系统具备极致性能， 极简开发，富媒体，富组件，wireless连接，音/视频编解码等功能特性， 可广泛应用于多媒体播放器，行车记录仪，游戏模拟器，DVB机顶盒，儿童早教机，卡拉OK机, 传感器网络模组，智能家居等产品的开发.

内核沿用熊大的rt-thread,作为一款有高度的高性能内核，RT-Thread不但可以适配MCU级的应用方案，更可以支撑Linux级的大型应用方案，这是zephyr, freeRTOS等内核无法比拟的，另外，pthread, shell，以及网络组件等部分也是从熊大社区直接拿来用的，在这里向熊大表示深深的感谢 @熊大.https://www.rt-thread.org/

支持多平台，多方案的多媒体架构

Melis 3.0的特性
极简开发

• 基于Kbuild构建扩展，支持C和C++编译. menuconfig字符菜单配置界面. 支持Windows/Linux开发环境.

• 支持ARMCC/GNU GCC CrossToochain.

• 支持ARMDS5/开源GDB+OCD+ICE(JLink/OpenJtag/CMSIS-DAP)调试方式.

• 支持KGDB裸机串口调试 .

• 支持ADBD服务，可以通过adb进行调试与连接.

• 采用松散多bin架构，系统由具备独立子功能的binary动态组合实现，模块之间高内聚，低耦合。便于分布式开发.

• 支持V4L2和Cedarx多媒体框架，方便集成各种编，解码方案.
  网络服务

• 列表支持BLE/BE协议栈

• 列表支持IPV4/IPV6网络协议栈.

• 列表支持基于mbedtls的安全套接字服务
  模块化设计
  类微内核架构(混合内核)，支持应用，驱动和中间件代码独立编译链接，映像高度压缩，不用时可卸载节省运存。模块化要求内存管理支持二级页表设计。
  内核服务:
  按照内核和方案解耦的方式设计，当前基于zephyr，rt-thread双内核， 具备硬实时能力,核心架构良好，支持极小footprint的设备.
  RT-Thread和zephyr各有特点，两者比较，zephyr有广度，但高度欠缺，而RT-Thread恰恰相反，它支持较高的Linux语义，有高度，但广度不如zephyr.
  Melis3.0主要面向全志自身的编码解码产品线进行开发，需要一个API层面有高度的系统，但不需要支持太多的开发板，所以广度方面甚重要．
  内存管理
  支持slab内存管理算法，有效减少内存外部碎片。
  支持虚拟空间动态创建，页面可支持4K大小
  调度策略
  在任何时候,系统执行有资格获得处理器的优先级最高的任务,在优先级相同的情况下,采用时间片轮转的调度策略. 这种调度策略有个简单的名字，叫做Round Robin(RR)调度策略
  丰富的文件系统支持
  支持常见文件系统格式,包括 Fat12/16/32, exFat,udffs,ntfs,cdfs, devfs, ramfs,littlefs, spiffs
  支持文件系统块缓冲bcache,可以有效提高存储价质的读写效率。
  丰富的多媒体和GUI支持
  集成全志CedarX2.7多媒体框架和OrangeGUI/MiniGUI图形框架，可支持中大规模多媒体录,编,解码产品的开发.
  支持全部的常见音频格式，支持的视频解码格式包括:H263/H264/H265,VP9/VP8/VP6, MJPEG/MPEG2/MPEG4, AVS/AVS2/AVS+, Divx/Xvid, VC1,Sorenson Spark,以及H264、H265，VP8，MJPEG编码的支持。
  Posix兼容
  支持Posix完整语义，面向MacOS,Unix,Linux可移植应用/中间件的跨系统移植.
  设备管理
  支持linux style的设备文件系统，所有设备以设备节点的方式向应用提供服务，应用通过标准化的接口open/read/write/ioctl/close对设备进行操作
  在Linux上搭建Melis3.0 开发环境
  第一步，得到源码，进入melis-v3.0目录执行source melis-env.sh
  
  第二步:选择方案
  
  这里选择的是C800唱戏机方案。
  第三步：make menuconfig,自定义配置，如果默认第二部配置满足要求，则跳过这一步
  
  第四步：执行make完成编译，编译过程首先会自动解压工具链到指定目录，然后才完成项目编译:
  
  第五步：打包成可烧录固件，执行pack命令
  
  至此，生成了最终可烧录的文件存放在source/workspace/suniv/beetles目录
  
  结束！

@zhaodongyu
感觉它这里针对的是GEMM KERNEL加速核的设计而言的，PPT标题已经给出来了。对经典的CPU流水线来讲，计算阶段和访问阶段已经流水化了，由不同的硬件(ALU/BIU）完成，本身是可以做到并行的。而用计算来掩盖访存延迟一般是HPC计算加速器的做法，因为这种KERNEL 加速器不像CPU有丰富的L1/L2/L3缓存可以用，CPU访存延迟低。计算加速器只能通过大量计算掩盖访存延迟。所以我感觉它这里讲的可能不是RISC-V的特性，而是GEMM阵列的特性。

A7 大概1.6个DMIPS/MHZ,平均下来每个clk执行1.6条指令，和谷歌标称的A7 1.9 DMIPS/Mhz差别不大，中间可能有编译器优化，运行环境不同引入的差别。

@q1215200171 你好，看到你最后两步使用了两个不同的模型，而无需修改后处理代码，所以很好奇，想请教你，这里的用的两个算法模型是同一个么？如果不是，为何resetnet和aipu.bin无缝替换却不用修改后处理的？
谢谢指导~！

@honglingjin
调用abort表明这是一个异常处理case, sys_abort函数属于系统porting层。一般定义为调试指令，调试打印，这里定义成死循环也没有问题。至于头文件定义了却找不到，可能和同文件的依赖顺序有关，两个办法处理：
1.找到当前报错文件所在目录，在当前目录下有一个隐藏的 .cmd文件，里面包含了编译此文件的所有头文件依赖列表，看是否有你想要的头文件。
2.甚至你可以直接 在调用处直接while(1)死循环暴力解决，注意加入调试打印，否则出错了也不知道。

@marleo ft.tar.bz2
仅供参考。

@geniusgogo 或者你了解到的方案中有其它更好的实现方式，也可以给我们推介一下.

@geniusgogo 在 melis中disp驱动问题 中说：

例如：应用分配buffer A/B，第一次显示buffer A，第二次显示buffer B，第三次由于应用不知道前两次显示的是否完成，所以按照应用层交替使用A/B buffer的逻辑，此时又会使用A，而此时底层驱动可能正在刷A，这就导致应用也会同时修改A buffer的数据，造成不同步花屏。

有可能的。
buffer的指针在用户手里，用户如果不加考虑随便写，可能会导致写入正在显示的画面，导致撕裂。
以播放视频的场景为例，一般video framebuffer会有很多个，比如说10个吧，所以显示那边会有一个显示帧队列，比如有三个帧，一帧是刚刚获取的，一帧是正在显示的，还有一帧是刚刚显示完的，通过软件控制时序，是可以保证常态化如此的，你可以理解它有点类似于网络中的滑动窗口，队列中永远都有一个待显示帧，当前帧和已显示帧。并且已显示帧需要回帧后，解锁才能再次写入数据，这样就可以避免撕裂的情况。
如果是UI framebuffer，也可以参考类似的做法，多创建几个帧，并且创建回帧机制。
严谨的做法可能要用到fence机制了，如果你们有 tina sdk，在disp2驱动下有个composoer_init函数，里面的逻辑就是实现fence的，安卓上用的就是这套机制。

所以，你说的情况是存在的，但是如果你隔足够安全的时间去送帧，自然每次都是成功的,这也是melis上的做法。

@bookos buffer是零拷贝，驱动内部记录是乒乓指针，buffer由应用去分配。
所以，站在这个层面看显示驱动，你不能只分配一个静态framebuffer,而是至少分配两个，然后传指针进去.

@geniusgogo 不会的，驱动内部对显示图层分配了两个buffer，你可以认为是一个pingpong buffer机制，当前写的不是正在显示的那片buffer，两个buffer依赖TCON中断进行同步。
虽然不存在花屏的问题，但是可能存在覆盖的问题，如果你送帧的帧率和TCON刷新率不匹配(太快），可能会覆盖上次还没显示出来的帧。
比如你的帧率要控制在30fps,你就需要通过某种机制保证在这个范围内送帧，误差不要太大, 这方面RTOS做的要比linux 好很多。

@march 在 FreeRTOS 10.4.3在RISCV(T-HEAD C906)平台上移植过程 中说：

过程

这里面细节比较多，有些忘记了，我找找当初移植的代码吧，到时候你参考一下。