OpenHarmony 平頭哥玄鐵架構輕量系統移植—潤和W800移植分享

本方案基于OpenHarmony LiteOS-M核心，使用聯盛德W800晶片的潤和軟體海王星系列Neptune100開發闆，進行開發移植。移植架構采用

Board

與

SoC

分離方案，支援通過Kconfig圖形化配置編譯選項，增加玄鐵

ck804ef

架構移植，實作了

HDF

、

XTS

等子系統及元件的适配。

适配準備

準備ubuntu20.04系統環境，安裝csky-abiv2-elf-gcc交叉編譯工具鍊。

編譯建構

目錄規劃

本方案的目錄結構使用Board和Soc解耦的思路：

晶片适配目錄規劃為：

device
├── board                                --- 單闆廠商目錄
│   └── hihope                           --- 單闆廠商名字：HiHope
│       └── neptune100                   --- 單闆名：Neptune100
└── soc                                  --- SoC廠商目錄
    └── winnermicro                      --- SoC廠商名字：聯盛德
        └── wm800                        --- SoC Series名：w800系列晶片

産品樣例目錄規劃為：

vendor
└── hihope                               --- 開發産品樣例廠商目錄，潤和軟體的産品樣例
    ├── neptune_iotlink_demo             --- 産品名字：Neptune100産品樣例代碼
    └── ...

産品定義

vendor/hihope/neptune_iotlink_demo/config.json

檔案下，描述了産品使用的核心、單闆、子系統等資訊。其中，核心、單闆型号、單闆廠商需提前規劃好，是預編譯指令

hb set

關注的。例如：

{
  "product_name": "neptune_iotlink_demo",   --- 産品名
  "ohos_version": "OpenHarmony 3.1",        --- 使用的OS版本
  "type":"mini",                            --- 系統類型: mini
  "version": "3.0",                         --- 系統版本: 3.0
  "device_company": "hihope",               --- 單闆廠商：hihope
  "board": "neptune100",                    --- 單闆名：neptune100
  "kernel_type": "liteos_m",                --- 核心類型：liteos_m
  "kernel_version": "3.0.0",                --- 核心版本：3.0.0
  "subsystems": []                          --- 子系統
}

填入的資訊與規劃的目錄相對應，其中

device_company

和

board

用于關聯出

device/board/<device_company>/

目錄。

單闆配置

關聯到的<board>目錄下，在

device/board/hihope/neptune100/liteos_m

目錄下放置

config.gni

檔案，該配置檔案用于描述該單闆資訊，包括CPU型号、交叉編譯工具鍊及全局編譯、連結參數等重要資訊：

# Kernel type, e.g. "linux", "liteos_a", "liteos_m".
kernel_type = "liteos_m"

# Kernel version.
kernel_version = "3.0.0"

# Board CPU type, e.g. "cortex-a7", "riscv32".
board_cpu = "ck804ef"

# Board arch, e.g.  "armv7-a", "rv32imac".
board_arch = "ck803"

# Toolchain name used for system compiling.
# E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang,  riscv32-unknown-elf.
# Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toolchain.
board_toolchain = "csky-elfabiv2-gcc"

#use_board_toolchain = true

# The toolchain path installed, it's not mandatory if you have added toolchain path to your ~/.bashrc.
board_toolchain_path = ""

# Compiler prefix.
board_toolchain_prefix = "csky-elfabiv2-"

# Compiler type, "gcc" or "clang".
board_toolchain_type = "gcc"

# config.json parse
if (product_path != "") {
  product_conf = read_file("${product_path}/config.json", "json")
  product_name = product_conf.product_name
  bin_list = product_conf.bin_list
}

# Board related common compile flags.
board_cflags = [
  "-mcpu=ck804ef",
  "-mhard-float",
  "-DGCC_COMPILE=1",
  "-DTLS_CONFIG_CPU_XT804=1",
  "-DNIMBLE_FTR=1",
  "-D__CSKY_V2__=1",
  "-DCPU_CK804",
  "-O2",
  "-g3",
  "-Wall",
  "-ffunction-sections",
  "-MMD",
  "-MP",
]

board_cxx_flags = board_cflags

board_asmflags = [
  "-mcpu=ck804ef",
  "-DCPU_CK804",
]

board_ld_flags = []

# Board related headfiles search path.
board_include_dirs = []

# Board adapter dir for OHOS components.
board_adapter_dir = ""

# Sysroot path.
board_configed_sysroot = ""

# Board storage type, it used for file system generation.
storage_type = ""

預編譯

在工程根目錄下輸入預編譯指令

hb set

可顯示相關産品資訊，如下：

hb set
OHOS Which product do you need?  (Use arrow keys)

hihope
 > neptune_iotlink_demo

OHOS Which product do you need?  neptune_iotlink_demo

執行

hb set

後，會在根目錄下自動生成

ohos_config.json

檔案，檔案中會列出待編譯的産品資訊。

通過

hb env

可以檢視選擇出來的預編譯環境變量。

[OHOS INFO] root path: /home/xxxx/openharmony_w800
[OHOS INFO] board: neptune100
[OHOS INFO] kernel: liteos_m
[OHOS INFO] product: neptune_iotlink_demo
[OHOS INFO] product path: /home/xxxx/openharmony_w800/vendor/hihope/neptune_iotlink_demo
[OHOS INFO] device path: /home/xxxx/openharmony_w800/device/board/hihope/neptune100/liteos_m
[OHOS INFO] device company: hihope

至此，預編譯适配完成，但工程還不能執行hb build進行編譯，還需要準備好後續的LiteOS-M核心移植。

核心移植

Kconfig适配

在

kernel/liteos_m

的編譯中，需要在相應的單闆以及SoC目錄下使用

Kconfig

檔案進行索引。

在 vendor/hihope/neptune_iotlink_demo 目錄下建立kernel_configs目錄，并建立 debug.config 空檔案。

打開

kernel/liteos_m/Kconfig

檔案，可以看到在該檔案通過orsource指令導入了

device/board

和

device/soc

下多個

Kconfig

檔案，後續需要建立并修改這些檔案：

orsource "../../device/board/*/Kconfig.liteos_m.shields"
orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.defconfig.boards"
orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.boards"
orsource "../../device/soc/*/Kconfig.liteos_m.defconfig"
orsource "../../device/soc/*/Kconfig.liteos_m.series"
orsource "../../device/soc/*/Kconfig.liteos_m.soc"

在

device/board/hihope

下建立相應的的

Kconfig

檔案：

├──  neptune100                                  --- neptune100單闆配置目錄
│   ├── Kconfig.liteos_m.board                   --- 單闆的配置選項
│   ├── Kconfig.liteos_m.defconfig.board         --- 單闆的預設配置項
│   └── liteos_m
│       └── config.gni                           --- 單闆的配置檔案
├── Kconfig.liteos_m.boards                      --- 單闆廠商下Boards配置資訊
└── Kconfig.liteos_m.defconfig.boards            --- 單闆廠商下Boards預設配置資訊

修改 Board 目錄下 Kconfig 檔案内容：

在

neptune100/Kconfig.liteos_m.board

中添加，

config BOARD_NEPTUNE100
    bool "select board neptune100"
    depends on SOC_WM800

配置隻有SOC_WM800被選後，BOARD_NEPTUNE100才可被選。

在

neptune100/Kconfig.liteos_m.defconfig.board

中添加，

if BOARD_NEPTUNE100

endif #BOARD_NEPTUNE100

用于添加 BOARD_NEPTUNE100預設配置

在

device/soc/winnermicro

下建立相應的的

Kconfig

檔案：

├── wm800                                        --- W800系列
│   ├── Kconfig.liteos_m.defconfig.wm800         --- W800晶片預設配置
│   ├── Kconfig.liteos_m.defconfig.series        --- W800系列預設配置
│   ├── Kconfig.liteos_m.series                  --- W800系列配置
│   └── Kconfig.liteos_m.soc                     --- W800晶片配置
├── Kconfig.liteos_m.defconfig                   --- SoC預設配置
├── Kconfig.liteos_m.series                      --- Series配置
└── Kconfig.liteos_m.soc                         --- SoC配置

修改 Soc 目錄下 Kconfig 檔案内容：

在

wm800/Kconfig.liteos_m.defconfig.wm800

中添加：

config SOC
    string
    default "wm800"
    depends on SOC_WM800

在

wm800/Kconfig.liteos_m.defconfig.series

中添加：

if SOC_SERIES_WM800

rsource "Kconfig.liteos_m.defconfig.wm800"

config SOC_SERIES
    string
    default "wm800"

endif

在

wm800/Kconfig.liteos_m.series

中添加：

config SOC_SERIES_WM800
    bool "winnermicro 800 Series"
    select ARM
    select SOC_COMPANY_WINNERMICRO              --- 選擇 SOC_COMPANY_WINNERMICRO
    select CPU_XT804
    help
        Enable support for winnermicro 800 series

在選擇了 SOC_SERIES_WM800之後，才可選

wm800/Kconfig.liteos_m.soc

檔案中的 SOC_WM800：

choice
    prompt "Winnermicro 800 series SoC"
    depends on SOC_SERIES_WM800

config SOC_WM800                         --- 選擇 SOC_WM800
    bool "SoC WM800"

endchoice

綜上所述，要編譯單闆BOARD_NEPTUNE100，則要分别選中：SOC_COMPANY_WINNERMICRO、SOC_SERIES_WM800、SOC_WM800

7. 在

kernel/liteos_m

中執行

make menuconfig

進行選擇配置,能夠對SoC Series進行選擇：

配置後的檔案會預設儲存在

vendor/hihope/neptune_iotlink_demo/kernel_configs/debug.config

,也可以直接填寫

debug.config

：

LOSCFG_PLATFORM_QEMU_CSKY_SMARTL=y
LOSCFG_SOC_SERIES_WM800=y

子產品化編譯

Board

和

SoC

的編譯采用子產品化的編譯方法，從

kernel/liteos_m/BUILD.gn

開始逐級向下遞增。本方案的适配過程如下：

在

device/board/hihope

中建立檔案

BUILD.gn

，新增内容如下：

if (ohos_kernel_type == "liteos_m") {
  import("//kernel/liteos_m/liteos.gni")
  module_name = get_path_info(rebase_path("."), "name")
  module_group(module_name) {
    modules = [
      "neptune100",                     --- 單闆子產品
      "shields",
    ]
  }
}

在上述

BUILD.gn

中，neptune100以及shields即是按目錄層級組織的子產品名。

在

device/soc/winnermicro

中，建立檔案

BUILD.gn

，按目錄層級組織，新增内容如下：

if (ohos_kernel_type == "liteos_m") {
  import("//kernel/liteos_m/liteos.gni")
  module_name = get_path_info(rebase_path("."), "name")
  module_group(module_name) {
    modules = [
     "hals",
     "wm800",
    ]
  }
}

在

device/soc/winnermicro

各個層級子產品下，同樣新增檔案

BUILD.gn

，将該層級子產品加入編譯。以

device/soc/winnermicro/wm800/board/platform/sys/BUILD.gn

為例：

import("//kernel/liteos_m/liteos.gni")
module_name = get_path_info(rebase_path("."), "name")
kernel_module(module_name) {             --- 編譯的子產品
  sources = [                            --- 編譯的源檔案
    "wm_main.c",
  ]
  include_dirs = [                       --- 子產品内使用到的頭檔案
    ".",
  ]
}

為了組織連結以及一些編譯選項，在

device/soc/winnermicro/wm800/board/BUILD.gn

下的

config("board_config")

填入了相應的參數：

config("board_config") {
  ldflags = []                            --- 連結參數，包括ld檔案
  libs = []                               --- 連結庫
  include_dirs = []                       --- 公共頭檔案

為了組織一些産品側的應用，需要強制連結到産品工程中來，本方案在vendor相應的

config.json

加入了相應的list來組織，在

vendor/hihope/neptune_iotlink_demo/config.json

增加對應的list：

"bin_list": [                       --- demo list
   {
     "elf_name": "hihope",
     "enable": "false",                 --- list開關
     "force_link_libs": [
       "bootstrap",
       "broadcast",
       ...
     ]
   }

将demo應用作為子產品庫來管理，開啟/關閉某個demo，在bin_list中增減相應庫檔案即可。bin_list在gn中可以直接被讀取，在

device/board/hihope/neptune100/liteos_m/config.gni

新增内容：

# config.json parse
if (product_path != "") {
  product_conf = read_file("${product_path}/config.json", "json")
  product_name = product_conf.product_name
  bin_list = product_conf.bin_list
}

讀取list後即可在相應的連結選項上加入相關的元件庫，在

//device/soc/winnermicro/wm800/BUILD.gn

添加内容：

foreach(bin_file, bin_list) {
   build_enable = bin_file.enable
   ...
   if(build_enable == "true")
   {
     ...
     foreach(force_link_lib, bin_file.force_link_libs) {
     ldflags += [ "-l${force_link_lib}" ]
     }
     ...
   }
}

核心子系統适配

在

vendor/hihope/neptune_iotlink_demo/config.json

添加核心子系統及相關配置，如下：

"subsystems": [
 {
   "subsystem": "kernel",
   "components": [
     { "component": "liteos_m", "features":[]
     }
   ]
},

核心啟動适配

由于Neptune100開發闆的晶片架構為Openharmony不支援的ck804ef架構，需要進行ck804ef架構移植。适配

kernel\liteos_m\arch\include

中定義的通用的檔案以及函數清單，并放在了

kernel\liteos_m\arch\csky\v2\ck804\gcc

檔案夾下。

核心初始化示例如下:

osStatus_t ret = osKernelInitialize();                    --- 核心初始化
if(ret == osOK)
{
 threadId = osThreadNew((osThreadFunc_t)sys_init,NULL,&g_main_task); --- 建立init線程
 if(threadId!=NULL)
 {
     osKernelStart();                                          --- 線程排程
 }
}

board_main在啟動OHOS_SystemInit之前，需要初始化必要的動作，如下：

...
UserMain();         --- 啟動OpenHarmony  OHOS_SystemInit的之前完成驅動的初始化
...
OHOS_SystemInit();  --- 啟動OpenHarmony服務，以及元件初始化
...

UserMain函數在

device/soc/winnermicro/wm800/board/app/main.c

檔案中，如下：

...
if (DeviceManagerStart()) {                                      --- HDF初始化
    printf("[%s] No drivers need load by hdf manager!",__func__);
}
...

HDF驅動架構适配

HDF驅動架構提供了一套應用通路硬體的統一接口，可以簡化應用開發，添加HDF元件需要在

//vendor/hihope/neptune_iotlink_demo/kernel_configs

添加：

LOSCFG_DRIVERS_HDF=y
LOSCFG_DRIVERS_HDF_PLATFORM=y

驅動适配相關檔案放置在

drivers/adapter/platform

中，對應有gpio，i2c，pwm，spi，uart，watchdog，都是通過HDF機制加載，本章節以GPIO和UART為例進行詳細說明。

GPIO适配

晶片驅動适配檔案位于 drivers/adapter/platform 目錄，在gpio目錄增加 gpio_wm.c 檔案，在 BUILD.gn 檔案中，描述了W800驅動的編譯适配。如下：
```
...
if (defined(LOSCFG_SOC_COMPANY_WINNERMICRO)) {
  sources += [ "gpio_wm.c" ]
}
...
           
```

gpio_wm.c

中驅動描述檔案如下：

/* HdfDriverEntry definitions */
struct HdfDriverEntry g_GpioDriverEntry = {
    .moduleVersion = 1,
    .moduleName = "WM_GPIO_MODULE_HDF",
    .Bind = GpioDriverBind,
    .Init = GpioDriverInit,
    .Release = GpioDriverRelease,
};
HDF_INIT(g_GpioDriverEntry);

在

device/board/hihope/shields/neptune100/neptune100.hcs

添加gpio硬體描述資訊, 添加内容如下：

root {
    platform {
     gpio_config {
         match_attr = "gpio_config";
         groupNum = 1;
         pinNum = 48;
     }
    }
}

在GpioDriverInit擷取hcs參數進行初始化，如下：

...
 gpioCntlr = GpioCntlrFromHdfDev(device);        --- gpioCntlr節點變量擷取具體gpio配置
 if (gpioCntlr == NULL) {
     HDF_LOGE("GpioCntlrFromHdfDev fail\r\n");
     return HDF_DEV_ERR_NO_DEVICE_SERVICE;
 }
 ...

UART适配

晶片驅動适配檔案位于 drivers/adapter/platform 目錄，在uart目錄增加 uart_wm.c 檔案，在 BUILD.gn 檔案中，描述了W800驅動的編譯适配。如下：
```
...
if (defined(LOSCFG_SOC_COMPANY_WINNERMICRO)) {
  sources += [ "uart_wm.c" ]
}
...
           
```

uart_wm.c

中驅動描述檔案如下：

/* HdfDriverEntry definitions */
struct HdfDriverEntry g_UartDriverEntry = {
    .moduleVersion = 1,
    .moduleName = "W800_UART_MODULE_HDF",
    .Bind = UartDriverBind,
    .Init = UartDriverInit,
    .Release = UartDriverRelease,
};

/* Initialize HdfDriverEntry */
HDF_INIT(g_UartDriverEntry);

在

device/board/hihope/shields/neptune100/neptune100.hcs

添加uart硬體描述資訊, 添加内容如下：

root {
    platform {
     uart_config {
     /*
         uart0 {
             match_attr = "uart0_config";
             num = 0;
             baudrate = 115200;
             parity = 0;
             stopBit = 1;
             data = 8;
         }*/
         uart1 {
             match_attr = "uart1_config";
             num = 1;
             baudrate = 115200;
             parity = 0;
             stopBit = 1;
             data = 8;
         }
      }
   }
}

在UartDriverInit擷取hcs參數進行初始化，如下：

...
 host = UartHostFromDevice(device);
 if (host == NULL) {
     HDF_LOGE("%s: host is NULL", __func__);
     return HDF_ERR_INVALID_OBJECT;
 }
 ...

Openharmony子系統适配

子系統的編譯選項入口在相應産品

config.json

下，如：

vendor/hihope/neptune_iotlink_demo/config.json

。

wifi_lite元件

首先，在

config.json

檔案中，增加

communication

子系統的

wifi_lite

部件，如下：

{
  "subsystem": "communication",
  "components": [
    {
      "component": "wifi_lite",
      "optional": "true"
    }
  ]
},

wifi_lite

部件在

build/lite/components/communication.json

檔案中，描述如下：

{
  "component": "wifi_lite",
  "targets": [
    "//foundation/communication/wifi_lite:wifi"       --- wifi_lite的編譯目标
  ],
},

在本案例中，

wifi

适配源碼可見

device/soc/winnermicro/wm800/board/src/wifi/wm_wifi.c

,如下：

int tls_wifi_netif_add_status_event(tls_wifi_netif_status_event_fn event_fn)   ---用于增加wifi事件功能
{
  u32 cpu_sr;
  struct tls_wifi_netif_status_event *evt;
  //if exist, remove from event list first.
  tls_wifi_netif_remove_status_event(event_fn);
  evt = tls_mem_alloc(sizeof(struct tls_wifi_netif_status_event));
  if(evt==NULL)
      return -1;
  memset(evt, 0, sizeof(struct tls_wifi_netif_status_event));
  evt->status_callback = event_fn;
  cpu_sr = tls_os_set_critical();
  dl_list_add_tail(&wifi_netif_status_event.list, &evt->list);
  tls_os_release_critical(cpu_sr);

  return 0;
}

系統服務管理子系統适配

系統服務管理子系統适配添加

samgr_lite

部件，直接在

config.json

配置，如下：

{
  "subsystem": "distributedschedule",
  "components": [
    {
      "component": "samgr_lite"
    }
  ]
},

公共基礎庫子系統适配

公共基礎庫子系統适配添加了

kv_store、file

部件，直接在

config.json

配置，如下：

{
  "subsystem": "utils",
  "components": [
    {
      "component": "kv_store",
      "features": [
        "enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true"
      ]
    },
    { "component": "file", "features":[] }
  ]
},

适配

kv_store

部件時，鍵值對會寫到檔案中。在輕量系統中，檔案操作相關接口有

POSIX

接口與

HalFiles

接口這兩套實作。

因為對接核心的檔案系統，采用

POSIX

相關的接口，是以

features

需要增加

enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true

。

啟動恢複子系統适配

啟動恢複子系統适配添加了

bootstrap_lite、syspara_lite

部件，直接在

config.json

配置，如下：

{
  "subsystem": "startup",
  "components": [
    {
      "component": "bootstrap_lite"
    },
    {
      "component": "syspara_lite",
      "features": [
        "enable_ohos_startup_syspara_lite_use_posix_file_api = true",
        "config_ohos_startup_syspara_lite_data_path = \"/data/\""
      ]
    }
  ]
},

适配bootstrap_lite部件時，需要在連結腳本檔案

device/soc/winnermicro/wm800/board/ld/w800/gcc_csky.ld

中手動新增如下段：

.zinitcall_array :
{
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_core_start = .);
 KEEP (*(SORT(.zinitcall.core*)))
 KEEP (*(.zinitcall.core*))
 PROVIDE_HIDDEN (__zinitcall_core_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_device_start = .);
 KEEP (*(SORT(.zinitcall.device*)))
 KEEP (*(.zinitcall.device*))
 PROVIDE_HIDDEN (__zinitcall_device_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_bsp_start = .);
 KEEP (*(SORT(.zinitcall.bsp*)))
 KEEP (*(.zinitcall.bsp*))
 PROVIDE_HIDDEN (__zinitcall_bsp_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_sys_service_start = .);
 KEEP (*(SORT(.zinitcall.sys.service*)))
 KEEP (*(.zinitcall.sys.service*))
 PROVIDE_HIDDEN (__zinitcall_sys_service_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_app_service_start = .);
 KEEP (*(SORT(.zinitcall.app.service*)))
 KEEP (*(.zinitcall.app.service*))
 PROVIDE_HIDDEN (__zinitcall_app_service_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_sys_feature_start = .);
 KEEP (*(SORT(.zinitcall.sys.feature*)))
 KEEP (*(.zinitcall.sys.feature*))
 PROVIDE_HIDDEN (__zinitcall_sys_feature_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_app_feature_start = .);
 KEEP (*(SORT(.zinitcall.app.feature*)))
 KEEP (*(.zinitcall.app.feature*))
 PROVIDE_HIDDEN (__zinitcall_app_feature_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_run_start = .);
 KEEP (*(SORT(.zinitcall.run*)))
 KEEP (*(.zinitcall.run*))
 PROVIDE_HIDDEN (__zinitcall_run_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_test_start = .);
 KEEP (*(SORT(.zinitcall.test*)))
 KEEP (*(.zinitcall.test*))
 PROVIDE_HIDDEN (__zinitcall_test_end = .);
 . = ALIGN(0x4) ;
 PROVIDE_HIDDEN (__zinitcall_exit_start = .);
 KEEP (*(SORT(.zinitcall.exit*)))
 KEEP (*(.zinitcall.exit*))
 PROVIDE_HIDDEN (__zinitcall_exit_end = .);
} > REGION_RODATA

需要新增上述段是因為

bootstrap_init

提供的對外接口，見

utils/native/lite/include/ohos_init.h

檔案，采用的是灌段的形式，最終會儲存到上述連結段中。主要的服務自動初始化宏如下表格所示：

接口名	描述
SYS_SERVICE_INIT(func)	辨別核心系統服務的初始化啟動入口
SYS_FEATURE_INIT(func)	辨別核心系統功能的初始化啟動入口
APP_SERVICE_INIT(func)	辨別應用層服務的初始化啟動入口
APP_FEATURE_INIT(func)	辨別應用層功能的初始化啟動入口

通過上面加載的元件編譯出來的lib檔案需要手動加入強制連結。

如在

vendor/hihope/neptune_iotlink_demo/config.json

中配置了

bootstrap_lite

部件

{
  "subsystem": "startup",
  "components": [
    {
      "component": "bootstrap_lite"
    },
    ...
  ]
},

bootstrap_lite

部件會編譯

base/startup/bootstrap_lite/services/source/bootstrap_service.c

，該檔案中，通過

SYS_SERVICE_INIT

将

Init

函數符号灌段到

__zinitcall_sys_service_start

和

__zinitcall_sys_service_end

中，由于

Init

函數是沒有顯式調用它，是以需要将它強制連結到最終的鏡像。如下：

static void Init(void)
{
    static Bootstrap bootstrap;
    bootstrap.GetName = GetName;
    bootstrap.Initialize = Initialize;
    bootstrap.MessageHandle = MessageHandle;
    bootstrap.GetTaskConfig = GetTaskConfig;
    bootstrap.flag = FALSE;
    SAMGR_GetInstance()->RegisterService((Service *)&bootstrap);
}
SYS_SERVICE_INIT(Init);   --- 通過SYS啟動即SYS_INIT啟動就需要強制連結生成的lib

在

base/startup/bootstrap_lite/services/source/BUILD.gn

檔案中，描述了在

out/neptune100/neptune_iotlink_demo/libs

生成

libbootstrap.a

，如下：

static_library("bootstrap") {
  sources = [
    "bootstrap_service.c",
    "system_init.c",
  ]
  ...

适配

syspara_lite

部件時，系統參數會最終寫到檔案中進行持久化儲存。在輕量系統中，檔案操作相關接口有POSIX接口與HalFiles接口這兩套實作。

因為對接核心的檔案系統，采用POSIX相關的接口，是以features字段中需要增加

enable_ohos_startup_syspara_lite_use_posix_file_api = true

。

XTS子系統适配

XTS子系統的适配，直接在

config.json

中加入元件選項：

{
 "subsystem": "xts",
 "components": [
   { 
     "component": "xts_acts",
     "features":
        [
       "config_ohos_xts_acts_utils_lite_kv_store_data_path = \"/data\"",
       "enable_ohos_test_xts_acts_use_thirdparty_lwip = true"
     ]
   },
   { "component": "xts_tools", "features":[] }
 ]
}

另外，XTS功能也使用了list來組織，在

config.json

檔案中增減相應子產品：

"bin_list": [
  {
    "enable": "true",
    "force_link_libs": [
       "module_ActsParameterTest",
       "module_ActsBootstrapTest",
       "module_ActsDfxFuncTest",
       "module_ActsHieventLiteTest",
       "module_ActsSamgrTest",
       "module_ActsUtilsFileTest",
       "module_ActsKvStoreTest",
       "module_ActsWifiServiceTest"
    ]
  }
],

其它元件的适配過程與官方以及其它廠商的過程類似，不再贅述。

OpenHarmony 平頭哥玄鐵架構輕量系統移植—潤和W800移植分享

适配準備

編譯建構

目錄規劃

産品定義

單闆配置

預編譯

核心移植

Kconfig适配

子產品化編譯

核心子系統适配

核心啟動适配

HDF驅動架構适配

GPIO适配

UART适配

Openharmony子系統适配

wifi_lite元件

系統服務管理子系統适配

公共基礎庫子系統适配

啟動恢複子系統适配

XTS子系統适配

繼續閱讀

[OpenHarmony] [RK2206] 建構OpenHarmony編譯器 (二)

#DAYU200# OpenHarmony跳轉撥号界面

#打卡不停更#OpenHarmony資料轉碼應用開發實戰（上）背景需求設計建立項目頁面布局規劃UI界面編碼實作總結

賦能千行百業數字化轉型，OpenHarmony生态新成果即将亮相HDC2022

基于OpenHarmony标準接口的檔案讀寫實作案例

前行不綴未來可期，鴻蒙生态發展邁入全新階段

哔哩哔哩已經開始開發鴻蒙版本了目前第一版V0.1.0Beta采用eTS語言，基于OpenHarmonyApi9開發支援功

#DAYU200體驗官# OpenHarmony3.1 Release 編譯

#沖刺創作新星# #跟着小白一起學鴻蒙# [十二]簡單Http用戶端

我把分布式音樂播放器适配了Stage模型

想開發DAYU200，我教你

在DAYU200上實作OpenHarmony視訊播放器

OpenHarmony移植案例： build lite源碼分析之hb指令entry.py

共築使能千行百業的數字底座 | HDC 2022松湖對話順利召開

OpenHarmony社群營運報告（2022年10月）

開源鴻蒙OpenHarmony 4.0 Beta2釋出，方舟架構ArkUI-X首發

OpenHarmony 平頭哥玄鐵架構 輕量系統移植—潤和W800移植分享

适配準備

編譯建構

目錄規劃

産品定義

單闆配置

預編譯

核心移植

Kconfig适配

子產品化編譯

核心子系統适配

核心啟動适配

HDF驅動架構适配

GPIO适配

UART适配

Openharmony子系統适配

wifi_lite元件

系統服務管理子系統适配

公共基礎庫子系統适配

啟動恢複子系統适配

XTS子系統适配

繼續閱讀

OpenHarmony 平頭哥玄鐵架構輕量系統移植—潤和W800移植分享