STM32F407移植OpenHarmony笔记9_openharmony移植stm32

继上一篇笔记，已经完成liteos内核的基本功能适配。
今天尝试启动OHOS和XTS兼容性测试。

如何启动OHOS？
OHOS系统初始化接口是OHOS_SystemInit(void)，在内核初始化完成后，就能调用。

extern void OHOS_SystemInit(void);
OHOS_SystemInit();

OHOS_SystemInit函数在//base/startup/bootstrap_lite/services/source/system_init.c里面。
它负责初始化系统组件，由于系统组件的初始化用了特殊的宏定义，比如：

CORE_INIT()
SYS_RUN()
SYS_SERVICE_INIT_PRI()
......

这些宏在ohos_init.h里面可以看到，利用编译器把这个函数放到指定的代码段，相当于在编译阶段生成一个静态数组，然后OHOS_SystemInit会从这个数组取出函数，再依次执行。要实现这样的机制还需要修改链接脚本，好消息是talkweb的demo代码已经帮我们写好了，直接拿来就能用。
LD脚本添加的内容长下面的样子：

 
    __zinitcall_bsp_start = .;
    KEEP (*(.zinitcall.bsp0.init))
    KEEP (*(.zinitcall.bsp1.init))
    KEEP (*(.zinitcall.bsp2.init))
    KEEP (*(.zinitcall.bsp3.init))
    KEEP (*(.zinitcall.bsp4.init))
    __zinitcall_bsp_end = .;
    ......
    __zinitcall_exit_start = .;
    KEEP (*(.zinitcall.exit0.init))
    KEEP (*(.zinitcall.exit1.init))
    KEEP (*(.zinitcall.exit2.init))
    KEEP (*(.zinitcall.exit3.init))
    KEEP (*(.zinitcall.exit4.init))
    __zinitcall_exit_end = .;

OHOS系统组件是按子系统来分类管理的，每个子系统下面又有多个组件，需要用哪些系统功能就要添加对应的组件到config.json文件里面去。每个组件都有一个专门的描述文件：bundle.json，描述组件的名字和适用系统类型等信息。

功能组件之间也存在依赖关系，目前我还不知道怎么查询依赖关系，只能凭经验手动添加来测试。
在编辑config.json添加组件时，还有一个features字段，也不知道从哪找。

XTS是一个独立子系统，依赖组件不太清楚，只能根据编译报错信息往里面加，加到编译不报错为止。不过这就遇到一个奇怪的报错：

[OHOS ERROR] FAILED: gen/base/startup/init/services/param/liteos/lite_ohos_param_to_param_cfg_to_code.log 
[OHOS ERROR] /home/openharmony/prebuilts/python/linux-x86/3.9.2/bin/python3 ../../../base/startup/init/scripts/param_cfg_to_code.py --source /home/openharmony/base/startup/init/services/etc_lite/param/ohos_const/ohos.para --source /utils/sys_param/vendor.para --source /home/openharmony/base/startup/init/services/etc/param/ohos.para --dest_dir /home/openharmony/out/demo_board/hello/gen/init/

通过对比talkweb的demo，原来需要手写一个vendor.para文件，而且还要指定路径。
需要在config.json里面添加产品适配器的路径，就是下面这行代码：

  "product_adapter_dir": "//vendor/demo/hello/hals",

这表示某些需要产品级适配的组件，会在这个目录去寻找对应的文件。
刚才的报错就是“syspara_lite”这个组件所需要的适配文件。
参考talkweb的demo，在这个目录下创建以下文件：

utils/sys_param/vendor.para
utils/sys_param/hal_sys_param.c
utils/sys_param/BUILD.gn

再次编译又遇到bool未定义的问题，我真是服了！用bool必须要#include <stdbool.h>。
经过一番折腾总算是编译通过了。
下载到板子上程序跑起来了，也看到一些日志了，但是还没有看到XTS的日志。

01-01 00:00:00.063 0 124 I 1/SAMGR: Init service 0x8039010 <time: 4294967260ms> success!
01-01 00:00:00.071 0 124 I 1/SAMGR: Initialized all core system services!
01-01 00:00:00.078 0 124 I 1/SAMGR: Goto next boot step return code:-6

再研究研究，XTS默认没有显示调用，只是被编译成静态库了。不会被链接脚本加入目标文件中，还需要手动在ldflags里面添加要引用的库，下面是抄来的参考代码：

  if (build_xts) {
    lib_dirs = [ "$root_out_dir/libs" ]
 
    ldflags += [
      "-Wl,--whole-archive",
      "-lbootstrap",
      "-lbroadcast",
      "-lhctest",
      #"-lhal_sysparam",
 
      #公共基础库
      #"-lmodule_ActsUtilsFileTest",
      #"-lmodule_ActsKvStoreTest",
 
      #DFX
      "-lmodule_ActsDfxFuncTest",
      "-lmodule_ActsHieventLiteTest",
 
      #启动恢复
      "-lmodule_ActsBootstrapTest",
      #"-lmodule_ActsParameterTest",
 
      #分布式任务调度
      "-lmodule_ActsSamgrTest",
 
      #网络
      #"-lmodule_ActsLwipTest",
      #"-lmodule_ActsUpdateTest",
 
      "-Wl,--no-whole-archive",
    ]
  }

这回终于看到XTS的日志打印了。

后面还会有很多个Start to run test suite:xxxx还在滚动。
滚到最后会打印All the test suites finished!

到此OHOS已成功启动，XTS测试也跑起来了。