XWOS Porting Guide

XWOS Porting Guide

  18 minute read  

Overview

XWOS porting steps includes the following elements:

  • XWOS porting layer (XWOSPL): It is similar to the abstract interface class in C++. It declare the interface and implement some member functions.
  • XWOS Porting Implementation Layer (XWOSIMPL): It is similar to C++. It provides implementation of the XWOS Porting Layer (XWOSPL) interface.
  • Initialization
  • Compilation

In order to improve the reusability of the code, the code related to the XWOS porting implementation layer (XWOSIMPL) is further divided into:

  • Architecture Description Layer (ADL)
  • CPU Description Layer (CDL)
  • SOC Description Layer (SDL)
  • Board Description Layer (BDL)

For example, under the ARMv7m architecture, the ADL directory is xwcd/soc/arm/v7m/gcc/, where the code is reused for all ARMv7-M-based CPUs. The differences between m3, m4, and m7 are described by the CDL directory. The same CPU core but different SOCs are described by SDL directory. The same SOC but different boards are described by BDL directory.

XWOS Porting Layer (XWOSPL) Header File Rules

Since C does not have a virtual keyword like C++, it is necessary to set a naming convention to express the same meaning as C++ abstract interface classes:

  • xwos/ospl/*.h : Header files provided by XWOS to BSP. Those files CANNOT be included by XWOS header files.
    • Prefix xwospl_ : Functions with prefix xwospl_ are similar to pure virtual functions in C++ abstract classes. XWOS does not provide default implementations for them. And they need to be implemented in BSP.
    • Prefix xwosplcb_ : Functions with prefix xwosplcb_ are similar to member functions in C++ classes. XWOS provides them for BSP to call.
  • xwos/ospl/soc/*.h : Header files provided by BSP can be included by XWOS header files.
    • xwos/ospl/soc/type.h : Header file contains platform type definitions.
    • xwos/ospl/soc/compiler.h : Header file contains platform compiler-related definitions.
    • xwos/ospl/soc/isa.h : Header file contains platform instruction and architecture-related definitions.
    • xwos/ospl/soc/lfq.h : Header file contains platform lock-free queue-related definitions.
      • Prefix soc_ : Functions with prefix soc_ are similar to pure virtual functions in C++ abstract classes. XWOS does not provide default implementations for them. And they need to be implemented in BSP.
    • xwos/ospl/soc/setjmp.h : Header file contains definitions related to setjmp.h .
      • xwlib_setjmp() : A function is similar to virtual function in C++ class. XWOS provides a default implementation. If no override implementation is provided, the default implementation of this function is setjmp() from the C standard library.
      • xwlib_longjmp() : A function is similar to virtual function in C++ class. XWOS provides a default implementation. If no override implementation is provided, the default implementation of this function is longjmp() from the C standard library.
    • xwos/ospl/soc/spinlock.h : Header file contains spinlock related definitions.
      • Prefix soc_ : Functions with prefix soc_ are similar to pure virtual functions in C++ abstract classes.
    • xwos/ospl/soc/xwaop.h : Header file contains atomic operations related definitions.
      • Prefix xwaop_: Functions with prefix xwaop_ are similar to virtual functions in C++ classes. XWOS provides default implementations.
    • xwos/ospl/soc/xwbop.h : Header file contains atomic operations related definitions.
      • Prefix xwbop_ : Functions with prefix xwbop_ are similar to virtual functions in C++ classes. XWOS provides default implementations.
    • xwos/ospl/soc/xwsc.h : Header file contains definitions related to system permissions and system calls.
      • xws64_t xwsc(xwsc_f func, xwreg_t argnum, ...) : This function is similar to pure virtual functions in C++ abstract class. XWOS does not provide a default implementation. Yt is not necessary to implement it. If no implementation is provided, the system privileged call xwsc() is not available.

Porting

The elements of porting XWOS includes: basic types, compiler, architecture instructions, lock-free queues, setjmp/longjmp, system calls and system permissions, spin locks, bit operations, atomic operations, interrupts, hardware timers, schedulers, and thread local storage (TLS).

Basic Types

XWOS defines a set of basic types, and all source codes are developed around the basic types.

  • XWOS header file: xwos/lib/type.h, included by xwos/standard.h .
  • Interface: xwos/ospl/soc/type.h
  • Implementation: xwosimpl_soc_type.h
    • Defining the ARCH_HAVE_xxxx macro to 1, indicates that the default definition of xxxx is overwritten. This file is generally located in the ADL directory, for example xwcd/soc/arm/v7m/gcc/xwosimpl_soc_type.h .
  • For all basic types, please refer to Basic Types

Compiler

  • XWOS header file: xwos/lib/compiler.h , included by xwos/standard.h .
  • Interface: xwos/ospl/soc/compiler.h
  • Implementation: xwosimpl_soc_compiler.h , provides definitions according to the compiler used.
  • Compiler-related macro definitions:
    • __xwcc_section(s) : Indicates that the symbol belongs to segment s.
    • __xwcc_aligned(x): Indicates that the starting address of the data is aligned to x bytes.
    • __xwcc_inline : Indicates that the function is an inline function and needs to be used with static .
    • __xwcc_packed : Indicates that the data structure is compact and the compiler should not perform optimized alignment processing.
    • __xwcc_must_check : Indicates that the function return value must be read, otherwise the compiler will report a warning.
    • __xwcc_unused : Indicates that the variable or function is not used. Used to remove compilation warnings.
    • __xwcc_noreturn: Indicates that the function will not return.
    • __xwcc_hot : Indicates that the function is often called in the code, which can help compilers optimize compilation.
    • __xwcc_atomic : Indicates that the variable is atomic, defined as _Atomic in the C11 standard and volatile in the C99 standard.
    • __xwcc_likely(x) : Indicates that the condition x is likely to be true . It is used to help the compiler optimize the compilation of if..else.. .
    • __xwcc_unlikely(x) : Indicates that the condition x is likely to be false . It is used to help the compiler optimize the compilation of if..else.. .
    • __xwcc_alignl1cache : Indicates that the starting address of the data is aligned to the cache line of the 1st level cache (way-set cache)
    • __xwcc_alignptr : Indicates that the starting address of the data is aligned to the size of the pointer. On 32-bit systems, data is aligned to 4 bytes. On 64-bit systems, data is aligned to 8 bytes.
    • xwcc_offsetof(type, member) : Calculate the offset of member in structure type . It is equivalent to offsetof() in the standard C library.

Architecture instructions

The CPU architecture provides some special instructions, which are usually difficult to express directly in C language. For ease of use, XWOS defines some functions or macros to express those instructions.

  • Interface: xwos/ospl/soc/isa.h
  • Implementation: xwosimpl_soc_isa.h

These architectural instructions include but are not limited to:

  • XWOS header file: xwos/lib/mb.h , included by xwos/standard.h .
    • Memory barrier
      • xwmb_compiler() : Compiler memory barrier. It prevents the compiler from optimizing out-of-order data reading and writing.
      • xwmb_isb() : Instruction synchronization barrier. It is used to wait for all instructions in the instruction pipeline to be executed before re-fetching instructions from the instruction cache.
      • xwmb_ddb() : Data dependency barrier. The data read from the memory for the first time is used as the address for the second read, which will generate a data dependency barrier, corresponding to the consumption order defined in stdatomic.h ( memory_order_consume ).
        • Most processor architectures will automatically generate data dependency barriers without the need for additional instructions. At this time, xwmb_ddb() is defined as xwmb_compiler().
        • Data dependency barrier instructions are only needed on a few CPUs, such as the DEC Alpha.
      • xwmb_rmb() : Read memory barrier
      • xwmb_wmb() : Write memory barrier
      • xwmb_mb() : Read and write memory barrier
      • xwmb_dma_rmb() : Read memory barrier when using DMA
      • xwmb_dma_wmb() : Write memory barrier when using DMA
      • xwmb_dma_mb() : Memory barrier when using DMA
      • xwmb_mp_mb() : Memory barrier on multi-core systems
      • xwmb_mp_rmb() : Read memory barrier on multi-core systems
      • xwmb_mp_wmb() : Write memory barrier on multi-core systems
      • xwmb_mp_acquire() : Barrier to ensure acquire memory ordering on multi-core systems. acquire memory ordering is usually used with read instructions.
      • xwmb_mp_release() : Barrier to ensure release memory ordering on multi-core systems. release memory ordering is usually used with a store instruction.
  • XWOS header file: xwos/standard.h
    • debugging
      • soc_bug(): Usually used to handle errors in relatively low-level codes such as ARCH, CPU, SOC, Board, etc. Usually defined as a breakpoint instruction to facilitate debugging with a debugger.

Lock-free queue

The C library of XWOS provides lock-free queue functions. The implementation of lock-free queues depends on the atomic operation instructions of the CPU.

  • XWOS header file: xwos/lib/lfq.h
  • Interface: xwos/ospl/soc/lfq.h
  • Implementation: xwosimpl_soc_lfq.h

setjmp/longjmp

The XWOS C library provides functions similar to the setjmp()/longjmp() in the C standard library. The specific implementation is closely related to how registers are switched when the OS switches contexts. The standard implementation in the C standard library may not meet the requirements. If no implementation is provided, the standard implementation from the C standard library will be used by default.

  • XWOS header file: xwos/lib/setjmp.h
  • Interface: xwos/ospl/soc/setjmp.h
  • Implementation:
    • xwosimpl_soc_setjmp.h
    • xwosimpl_soc_setjmp.c

System calls and system privileges

Usually the CPU has two permission modes: user and system.

  • All registers can be accessed in system mode;
  • Some CPU registers cannot be accessed in user mode (such as switch interrupts), and can only be accessed by special instructions. Accessible only in system mode.

The XWOS C library provides the method called xwsc() that can switch CPU access permissions. xwsc() allows users to simulate the method temporarily possesses system privileges to call a function. xwsc() is not required to be implemented. In this case, when porting XWOS, all threads should only run in the system authority mode.

  • XWOS header file: xwos/lib/sc.h
  • Interface: xwos/ospl/soc/xwsc.h
  • Implementation: xwosimpl_soc_xwsc.h

Spin lock

In a multi-core system, memory areas accessed by multiple CPUs need to be protected by spin locks. The implementation of spin locks depends on atomic operation instructions and memory barrier instructions.

  • XWOS header files:
    • xwos/osal/lock/spinlock.h : Spin lock
    • xwos/osal/lock/seqlock.h : Improved spin lock, named sequence lock.
  • Interface: xwos/ospl/soc/spinlock.h
  • Implementation: xwosimpl_soc_spinlock.h

Bit Operations

The C library of XWOS provides a set of bit operation functions. To improve efficiency, some bit operations can be re-implemented with special instructions.

  • XWOS header file: xwos/lib/xwbop.h
  • Interface: xwos/ospl/soc/xwbop.h
  • Implementation:
    • xwosimpl_soc_xwbop.h
    • xwosimpl_soc_xwbop.c
  • Basic bit operation function set:
    • Bit order mirror flip: The conversion between Intel bit sequence (small-endian) and Motorola bit sequence (big-endian).
      • xwbop_rbit8() : Mirror flip the bit order of 8-bit data.
      • xwbop_rbit16() : Mirror flip the bit order of 16-bit data.
      • xwbop_rbit32() : Mirror flip the bit order of 32-bit data.
      • xwbop_rbit64() : Mirror flip the bit order of 64-bit data.
    • Endian reversal
      • xwbop_re16() : Reverse the byte order of 16-bit data.
      • xwbop_re16s32() : Reverse the byte order of 16-bit data, extend the sign bit to 32 bits, and return signed 32-bit data.
      • xwbop_re32() : Reverse the byte order of 32-bit data.
      • xwbop_re32s64() : Reverse the byte order of 32-bit data, extend the sign bit to 64 bits, and return signed 64-bit data.
      • xwbop_re64() : Reverse the byte order of 64-bit data.
    • Find the bit that is set to 1
      • xwbop_ffs8() : Search from the least significant bit of an 8-bit data.
      • xwbop_fls8() : Ssearch from the most significant bit of an 8-bit data.
      • xwbop_ffs16() : Search from the least significant bit of a 16-bit data.
      • xwbop_fls16() : Search from the most significant bit of a 16-bit data.
      • xwbop_ffs32() : Search from the least significant bit of a 32-bit data.
      • xwbop_fls32() : Search from the most significant bit of a 32-bit data.
      • xwbop_ffs64() : Search from the least significant bit of a 64-bit data.
      • xwbop_fls64() : Search from the most significant bit of a 64-bit data.

Atomic Operations

The XWOS C library provides a set of atomic operation functions. The implementation of atomic operations depends on the atomic operation instructions of the CPU.

  • XWOS header files: + xwos/lib/xwaop.h
  • Interface: xwos/ospl/soc/xwaop.h
  • Implementation:
    • xwosimpl_soc_xwaop.h
    • xwosimpl_soc_xwaop/*.c
  • Description
    • The XWOS kernel implements atomic operations of other types based on the 8 basic types atomic operations (xws8_t, xwu8_t, xws16_t, xwu16_t, xws32_t, xwu32_t, xws64_t, xwu64_t). Because other basic types are defined based on these 8 basic types.
    • 64-bit atomic operations do not need to be implemented.
    • If the CPU architecture is relatively simple and there is no atomic operation instruction, you can consider implementing atomic operation functions based on spin locks. In a uni-core system, the implementation of spin lock only requires closing/opening interrupts.
    • Some CPU architectures only provide atomic operation instructions that are consistent with the CPU bit width. In this case, atomic operations of other bit-width types can be implemented based on spin locks。 In a uni-core system, the implementation of spin lock only requires closing/opening interrupts.
  • Basic types of atomic operation function set
    • load() : Load (memory order can be specified)
    • store() : Store (memory order can be specified)
    • read() : Read (memory order: load-require)
    • write() : Write (memory order: store-release)
    • add() : Addition
    • sub() : Subtraction
    • rsb() : Reverse subtraction
    • and() : And operation
    • or() : Or operation
    • xor() : Exclusive or operation
    • teq_then_write() : Test whether the atomic variable is equal to the test value, then write .
    • teq_then_add() : Test whether the atomic variable is equal to the test value, then do add operation.
    • teq_then_sub() : Test whether the atomic variable is equal to the test value, then do subtraction operation.
    • teq_then_rsb() : Test whether the atomic variable is equal to the test value, then do reverse subtraction operation.
    • tne_then_write() : Test whether the atomic variable is not equal to the test value, then write .
    • tne_then_add() : Test whether the atomic variable is not equal to the test value, then do add operation.
    • tne_then_sub() : Test whether the atomic variable is not equal to the test value, then do subtraction operation.
    • tne_then_rsb() : Test whether the atomic variable is not equal to the test value, then do reverse subtraction operation.
    • tge_then_write() : Test whether the atomic variable is greater than or equal to the test value, then write .
    • tge_then_add() : Test whether the atomic variable is greater than or equal to the test value, then do add operation.
    • tge_then_sub() : Test whether the atomic variable is greater than or equal to the test value, then do subtraction operation.
    • tge_then_rsb() : Test whether the atomic variable is greater than or equal to the test value, then do reverse subtraction operation.
    • tgt_then_write() : Test whether the atomic variable is greater than the test value, then write .
    • tgt_then_add() : Test whether the atomic variable is greater than the test value, then do add operation.
    • tgt_then_sub() : Test whether the atomic variable is greater than the test value, then do subtraction operation.
    • tgt_then_rsb() : Test whether the atomic variable is greater than the test value, then do reverse subtraction operation.
    • tle_then_write() : Test whether the atomic variable is less than or equal to the test value, then write .
    • tle_then_add() : Test whether the atomic variable is less than or equal to the test value, then do add operation.
    • tle_then_sub() : Test whether the atomic variable is less than or equal to the test value, then do subtraction operation.
    • tle_then_rsb() : Test whether the atomic variable is less than or equal to the test value, then do reverse subtraction operation.
    • tlt_then_write() : Test whether the atomic variable is less than the test value, then write .
    • tlt_then_add() : Test whether the atomic variable is less than the test value, then do add operation.
    • tlt_then_sub() : Test whether the atomic variable is less than the test value, then do subtraction operation.
    • tlt_then_rsb() : Test whether the atomic variable is less than the test value, then do reverse subtraction operation.
    • tgele_then_write() : Test whether the atomic variable is in the closed interval [l,r] , then write .
    • tgele_then_add() : Test whether the atomic variable is in the closed interval [l,r] , then do add operation.
    • tgele_then_sub() : Test whether the atomic variable is in the closed interval [l,r] , then do subtraction operation.
    • tgele_then_rsb() : Test whether the atomic variable is in the closed interval [l,r] , then do reverse subtraction operation.
    • tgelt_then_write() : Test whether the atomic variable is in the left closed and right open interval [l,r) , then write .
    • tgelt_then_add() : Test whether the atomic variable is in the left-closed and right-open interval [l,r) , and then do add operation.
    • tgelt_then_sub() : Test whether the atomic variable is in the left closed and right open interval [l,r) , then do subtraction operation.
    • tgelt_then_rsb() : Test whether the atomic variable is in the left closed and right open interval [l,r) , then do reverse subtraction operation.
    • tgtle_then_write() : Test whether the atomic variable is in the left-open and right-closed interval (l,r] , then write .
    • tgtle_then_add() : Test whether the atomic variable is in the left-open and right-closed interval (l,r] , then do add operation.
    • tgtle_then_sub() : Test whether the atomic variable is in the left-open and right-closed interval (l,r] , then do subtraction operation.
    • tgtle_then_rsb() : Test whether the atomic variable is in the left-open and right-closed interval (l,r] , then do reverse subtraction operation.
    • tgtlt_then_write() : Test whether the atomic variable is in the open interval (l,r) , then write .
    • tgtlt_then_add() : Test whether the atomic variable is in the open interval (l,r) , then do add operation.
    • tgtlt_then_sub() : Test whether the atomic variable is in the open interval (l,r) , then do a subtraction operation.
    • tgtlt_then_rsb() : Test whether the atomic variable is in the open interval (l,r) , then do a reverse subtraction operation.
    • tst_then_op() : Test the atomic variable with tst() function, then operate it with op() function.
  • Atomic operations on bitmap arrays
    • xwbmpaop_c0i() : Clear the i th bit to 0 .
    • xwbmpaop_s1i() : Set the i th bit to 1 .
    • xwbmpaop_x1i() : flip the i th bit.
    • xwbmpaop_t1i() : Test whether the i th bit is 1 .
    • xwbmpaop_t0i_then_s1i() : Test whether the i th bit is 0 , then set it to 1 .
    • xwbmpaop_t1i_then_c0i() : Test whether the i th bit is 1 , then clear it to 0 .
    • xwbmpaop_ffs_then_c0i() : Find the first bit that is 1 starting from the least significant bit and clear it to 0 .
    • xwbmpaop_ffz_then_s1i() : Find the first bit that is 0 tarting from the least significant bit and set it to 1 .
    • xwbmpaop_fls_then_c0i() : Find the first bit that is 1 starting from the most significant bit and clear it to 0 .
    • xwbmpaop_flz_then_s1i() : Find the first bit that is 0 starting from the most significant bit and set it to 1 .

Interrupts

  • XWOS header file: xwos/osal/irq.h
  • Interface: xwos/ospl/irq.h
  • Implementation:
    • xwosimpl_irq.h
    • xwosimpl_irq.c
  • Interrupt number:
    • XWOS defines the interrupt number type xwirq_t, which is a signed integer:
      • Integer and 0: It represents the peripheral interrupt of SOC.
      • Negative number: It represents an exception.
  • Interrupt priority requirements
    • The context switch interrupt is the lowest priority interrupt in the system.
    • The context switch interrupt priority <= the tick timer interrupt priority <= the scheduler service interrupt priority.
  • Functions that need to be implemented in the operating system porting layer:
    • void xwospl_cpuirq_enable_lc(void) : Turn on the CPU interrupt.
    • void xwospl_cpuirq_disable_lc(void) : Turn off the CPU interrupt.
    • void xwospl_cpuirq_restore_lc(xwreg_t cpuirq) : Save the current CPU interrupt switch state and turn it off.
    • void xwospl_cpuirq_save_lc(xwreg_t * cpuirq) : Restore the previously saved CPU interrupt switch state.
    • xwer_t xwospl_irq_get_id(xwirq_t * irqnbuf) : Get the interrupt number of the current interrupt, which can also be used to judge the context.
    • xwer_t xwospl_irq_enable(xwirq_t irqn) : Turn on a peripheral interrupt.
    • xwer_t xwospl_irq_disable(xwirq_t irqn) : Turn off a peripheral interrupt.
    • xwer_t xwospl_irq_save(xwirq_t irqn, xwreg_t * flag) : Save the switch of a peripheral interrupt, and then close it.
    • xwer_t xwospl_irq_restore(xwirq_t irqn, xwreg_t flag) : Restore the switch of a peripheral interrupt.

Hardware Timer

Each CPU needs a private hardware timer to provide periodic tick interrupts. XWOS’s scheduling, delays, and software timers are all implemented based on tick interrupts.

  • Interface: xwos/ospl/syshwt.h
  • Implementation:
    • xwosimpl_syshwt.h
    • xwosimpl_syshwt.c
  • Adaptation function:
    • xwospl_syshwt_init() : Initialize hardware timer.
    • xwospl_syshwt_start(): Start hardware timer.
    • xwospl_syshwt_stop(): Close hardware timer.
    • xwospl_syshwt_get_timeconfetti(): Returns how many nanoseconds are left before the next timer interrupt.

Scheduler

  • Interface: xwos/ospl/skd.h
  • Implementation:
    • xwosimpl_skd.h
    • xwosimpl_skd.c
  • Adaptation function:
    • xwospl_skd_init(struct xwospl_skd * xwskd) : Initialize the scheduling scheduler.
    • xwospl_skd_init_stack() : Initialize the stack of scheduling objects (threads).
    • xwospl_skd_get_id() : Get the ID of the current CPU.
    • xwospl_skd_start() : Start the scheduler.
    • xwospl_skd_suspend() : Suspend the scheduler for power management.
    • xwospl_skd_resume() : Resume the scheduler for power management.
    • xwospl_skd_req_swcx() : Request scheduling.
    • xwospl_skd_isr_swcx() : context switch interrupt.
    • xwospl_thd_exit_lc() : The thread on the current CPU exits.
    • xwospl_thd_freeze_lc() : Freeze the thread currently running in the CPU.
    • xwospl_thd_outmigrate() : Migrate threads out of other CPUs and prepare to migrate to other CPUs (multi-core only).
    • xwospl_thd_immigrate() : Migrate thread to target CPU (multi-core only).

Thread Local Storage

From the C11 standard, C language supports thread local storage (TLS). XWOS provides support for the keywords _Thread_Local (C11) and thread_Local (C2X).

  • Interface: xwos/ospl/tls.h
  • Implementation: xwosimpl_tls.c
  • Adaptation function:
    • void xwospl_tls_init(struct xwospl_skdobj_stack * stk): Initialize TLS in the thread stack.

There are 4 standard models for thread local storage (TLS): global-dynamic, local-dynamic, initial-exec, and local-exec. XWOS only supports initial-exec and local-exec, and uses compiler option -ftls-model=local-exec by default. When porting XWOS, you need to put the .got section in the linker script:

        .got : {
                *(.got.plt) *(.igot.plt) *(.got) *(.igot)
        } > code_mr AT> code_mr

Linker Script

The XWOS linker script consists of two parts:

  • xxx.lds in SOC description layer describes SECTIONS
    • Users can refer to existing files for modification, for example:
      • ARMv6M
        • STM32F0x: xwcd/soc/arm/v6m/m0/stm32/f0.lds
      • ARMv7M
        • STM32H7x: xwcd/soc/arm/v7m/m7/stm32/h7.lds
        • S32K3xx: xwcd/soc/arm/v7m/m7/s32k3xx/s32k3xx.lds
        • STM32F4x: xwcd/soc/arm/v7m/m4/stm32/f4.lds
        • S32K14x: xwcd/soc/arm/v7m/m4/s32k14x/s32k14x.lds
        • GD32F30x: xwcd/soc/arm/v7m/m4/gd32/f30x.lds
        • STM32F1x: xwcd/soc/arm/v7m/m3/stm32/f1.lds
        • GD32F10x: xwcd/soc/arm/v7m/m3/gd32/f10x.lds
      • ARMv8A
        • RPi4B: xwcd/soc/arm64/v8a/a72/bcm2711/soc.lds
      • PowerPC Embedded
        • MPC560xB: xwcd/soc/powerpc/e200x/e200z0h/mpc560xb/soc.lds
      • RISC-V
        • GD32VF10x: xwcd/soc/riscv/nuclei/bumblebee/gd32v/f10x.lds
  • brd.lds in board directory defines MEMORY .

Initialization Process

XWOS provides a general boot flow:

flowchart LR
    Pre-initialization --> Initialization --> Post-initialization --> Main-function

    subgraph Pre-initialization
        direction TB
        exc["Exception initialization"]
        exc["Floating point unit initialization"]
        exc["Memory initialization"]
    end

    subgraph Initialization
        xwos_init["xwos_init()"]
    end

    subgraph Post-initialization
        direction LR
        device["Device driver initialization"]
        mm["Dynamic memory allocator initialization"]
    end

    subgraph Main-function
        direction LR
        skd_init["Initialize the scheduler: xwos_skd_init_lc()"]
        thd["Create threads."]
        skd_start["Start the scheduler: xwos_skd_start_lc()"]
    end

XWOS divides the initialization process into four phases:

  • Pre-initialization phase: xwos_preinit()
    • Defined by the user.
    • Inaccessible global variables, usually used to call arch_init(), cpu_init(), soc_init(), load memory data.
  • Initialization phase: xwos_init()
    • Defined by XWOS.
  • Post-initialization phase: xwos_postinit()
    • Defined by the user.
    • Access to global variables, usually used to initialize chip drivers, initial power management, and initial memory management.
  • Main function phase: xwos_main()
    • Defined by the user.
    • Usually used to define threads and start the scheduler.
    • If you need to use C standard lib, you also need to initialize libc. Depending on the selection by configuring XWCFG_LIBC, call newlibac_init() or picolibcac_init() .
    • C++ runtime also be initialized when calling newlibac_init() or picolibcac_init() .

Configuration

When porting XWOS, users need to provide the configuration cfg/ in the board directory. The specific content of the configuration can be found in Configuration.

Build system

XWOS provides a build system that can run on Windows and Linux. User code can be integrated by Xuanwu module .

Last modified July 15, 2024: chore: :tade: 创建玄武操作系统网站 (3cdce99)