Porting the OpenHarmony Kernel to a New Hardware Architecture

Porting the Processor Architecture

The foundation of kernel porting lies in adapting the processor architecture. In OpenHarmony, this step is optional—only required if the target architecture is not already supported. The list of currrently supported architectures can be found under liteos_m/arch. Refer to Table 1 for an overview.

Table 1: Supported Architectures in OpenHarmony

Series Model
arm arm9, cortex-m3, cortex-m4, cortex-m7, cortex-m33
csky v2
risc-v nuclei, riscv32
xtensa lx6

If your target processor is not listed, the chip vendor must implement the necessary adaptations. The arch/include directory contains essential header files defining functions that must be implemented for any new architecture. Some low-level components are written in assembly, and their syntax varies depending on the toolchain (e.g., GCC, IAR, Keil), so separate implementations exist per compiler.

kernel/liteos_m/arch
├── arm
│   ├── arm9
│   ├── cortex-m3
│   ├── cortex-m33
│   │   ├── gcc
│   │   └── iar
│   ├── cortex-m4
│   ├── cortex-m7
├── csky
├── include
│   ├── los_arch.h            # Architecture-specific initialization functions
│   ├── los_atomic.h          # Atomic operation implementations
│   ├── los_context.h         # Task context management
│   ├── los_interrupt.h       # Interrupt and exception handling
│   └── los_timer.h           # System timer configuration
├── risc-v
│   ├── nuclei
│   └── riscv32
└── xtensa
     └── lx6

Integrating Vendor SDK into the Build Framework

After setting up the build environment, integrate the chip vendor’s SDK into OpenHarmony’s compilation system. This enables building a bare-metal image with SDK APIs available, allowing the OS to call them later.

  1. Place the vendor SDK under the device directory in a logical location.
  2. Integrate the SDK’s build scripts or image packaging logic into the build system.

Example GN build script: device/MyDeviceCompany/MyBoard/BUILD.gn

import("//build/lite/config/component/lite_component.gni")

executable("OHOS_Image.elf") {
  libs = [
    "xxx/xxx/libxxx.a",
  ]
  asmflags = [""]
  ldflags = [
    "-T./xxx/xxx/xxx.ld",
    "-Lxxx/xxx/",
    "-lxxx",
    "-Wl,--whole-archive",
    "-lmodule_xxx",
    "-Wl,--no-whole-archive",
  ]
  deps = [
    "//build/lite:ohos",
    ":sdk",
  ]
}

copy("prebuilt") {
  sources = []
  outputs = []
}

static_library("sdk") {
  sources = []
  include_dirs = []
}

build_ext_component("image") {
  exec_path = rebase_path(root_out_dir)
  objcopy = "arm-none-eabi-objcopy"
  objdump = "arm-none-eabi-objdump"
  command = "$objcopy -O binary OHOS_Image.elf OHOS_Image.bin"
  command += " && sh -c '$objdump -t OHOS_Image.elf | sort > OHOS_Image.sym.sorted'"
  command += " && sh -c '$objdump -d OHOS_Image.elf > OHOS_Image.asm'"
  deps = [
    ":prebuilt",
    ":OHOS_Image.elf",
  ]
}

group("MyBoard") {
}

Figure 1: Dependency Execution Order

  1. Create a custom target_config.h file for the chip vendor. Place it in device/MyDeviceCompany/MyBoard, and adjust settings based on hardware capabilities. See Table 2 for key configuration options.

Reference path: device/hisilicon/hispark_pegasus/sdk_liteos/platform/os/Huawei_LiteOS/targets/hi3861v100/include/target_config.h

Note:

  • If default values don’t meet requirements, consult kernel/liteos_m/kernel/include/los_config.h, which contains all available kernel configurations.
  • Settings in target_config.h override those in los_config.h.

Table 2: Key Configuration Options in target_config.h

Configuration Description Suggested Value
OS_SYS_CLOCK System clock frequency 40000000UL
LOSCFG_BASE_CORE_TICK_PER_SECOND OS tick rate 100UL
LOSCFG_BASE_CORE_TICK_HW_TIME Timer calibration option YES
LOSCFG_PLATFORM_HWI Use interrupt handover mechanism YES
LOSCFG_BASE_CORE_TSK_LIMIT Maximum number of tasks (excluding idle) 32
LOSCFG_BASE_CORE_TSK_IDLE_STACK_SIZE Idle task stack size 0x180UL
LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE Default task stack size (aligned to 8 bytes) 0x1000UL
LOSCFG_BASE_CORE_TSK_MIN_STACK_SIZE Minimum required stack size ALIGN(0x180, 4)
LOSCFG_BASE_CORE_TIMESLICE_TIMEOUT Max execution time for same-priority tasks 2
LOSCFG_BASE_IPC_SEM_LIMIT Maximum semaphores 100
LOSCFG_BASE_IPC_MUX_LIMIT Maximum mutexes 64
LOSCFG_BASE_IPC_QUEUE_LIMIT Maximum message queues 64
LOSCFG_BASE_CORE_SWTMR_LIMIT Maximum software timers 80
LOSCFG_BASE_MEM_NODE_SIZE_CHECK Enable memory node size validation NO
LOSCFG_PLATFORM_EXC Exception module enable YES
LOSCFG_USE_SYSTEM_DEFINED_INTERRUPT Use OS-defined interrupts NO
  1. Modify Interrupt Handling

OpenHarmony supports two approaches:

  1. Use Vendor Default Interrupts Set LOSCFG_USE_SYSTEM_DEFINED_INTERRUPT to NO (0). Then modify the startup file (xxx.s) as follows:

    • Replace PendSV_Handler with HalPendSV.
    • Replace SysTick_Handler with OsTickHandler.
  2. Redirect Interrupts During System Initialization Set both LOSCFG_USE_SYSTEM_DEFINED_INTERRUPT and LOSCFG_PLATFORM_HWI to YES (1).

Note: After redirection, the interrupt vector table g_hwiForm must be byte-aligned per the architecture manual—commonly aligned to 0x200-byte boundaries.

Adding the Kernel Subsystem

Once the kernel is ready, integrate it into the project to generate a full-featured system image.

  1. Add the kernel subsystem in config.json. Path: vendor/MyVendorCompany/MyProduct/config.json

    Update with:

    {
      "subsystem": "kernel",
      "components": [
        {
          "component": "liteos_m",
          "features": [""]
        }
      ]
    }
    
  2. Enable or Disable Kernel Features

    LiteOS-M provides optional features like filesystems and backtrace support.

    Path: kernel/liteos_m/BUILD.gn

    declare_args() {
      enable_ohos_kernel_liteos_m_cppsupport = true
      enable_ohos_kernel_liteos_m_cpup = true
      enable_ohos_kernel_liteos_m_exchook = true
      enable_ohos_kernel_liteos_m_kal = true
      enable_ohos_kernel_liteos_m_fs = true
      enable_ohos_kernel_liteos_m_backtrace = true
    }
    group("kernel") {
      deps = [
        "components/bounds_checking_function:sec",
        "kernel:kernel",
        "utils:utils",
      ]
      if (enable_ohos_kernel_liteos_m_cppsupport) {
        deps += ["components/cppsupport:cppsupport"]
      }
      ...
      if (enable_ohos_kernel_liteos_m_kal) {
        deps += ["kal:kal"]
      }
    }
    

    Choose between CMSIS or POSIX interface support:

    Path: kernel/liteos_m/kal/BUILD.gn

    declare_args() {
      enable_ohos_kernel_liteos_m_cmsis = true
      enable_ohos_kernel_liteos_m_posix = true
    }
    static_library("kal") {
      sources = ["kal.c"]
      if (enable_ohos_kernel_liteos_m_cmsis) {
        deps += ["cmsis/"]
      }
      if (enable_ohos_kernel_liteos_m_posix) {
        deps += ["posix/"]
      }
    }
    

    Enable FATFS support:

    Path: kernel/liteos_m/components/fs/BUILD.gn

    declare_args() {
      enable_ohos_kernel_liteos_m_fatfs = true
    }
    group("fs") {
      deps = []
      if (enable_ohos_kernel_liteos_m_fatfs) {
        deps += ["fatfs:fatfs"]
      }
    }
    

    Note: Feature flags can be configured per product. Example:

    vendor/MyVendorCompany/MyProduct/config.json

    {"subsystem": "kernel", "components": [{"component": "liteos_m", "features": ["enable_ohos_kernel_liteos_m_fs = false", "enable_ohos_kernel_liteos_m_cppsupport = false"]}]}
    

Tags: OpenHarmony Kernel Porting Embedded Systems LiteOS-M Chip Architecture

Posted on Thu, 14 May 2026 06:44:51 +0000 by jokerofsouls