This is the documentation for the latest (main) development branch of Zephyr. If you are looking for the documentation of previous releases, use the drop-down menu on the left and select the desired version.

CONFIG_KERNEL_VM_BASE

Virtual address space base address

Type: hex

Help

Define the base of the kernel's address space.

By default, this is the same as the DT_CHOSEN_Z_SRAM physical base SRAM
address from DTS, in which case RAM will be identity-mapped. Some
architectures may require RAM to be mapped in this way; they may have
just one RAM region and doing this makes linking much simpler, as
at least when the kernel boots all virtual RAM addresses are the same
as their physical address (demand paging at runtime may later modify
this for non-pinned page frames).

Otherwise, if RAM isn't identity-mapped:
1. It is the architecture's responsibility to transition the
instruction pointer to virtual addresses at early boot before
entering the kernel at z_cstart().
2. The underlying architecture may impose constraints on the bounds of
the kernel's address space, such as not overlapping physical RAM
regions if RAM is not identity-mapped, or the virtual and physical
base addresses being aligned to some common value (which allows
double-linking of paging structures to make the instruction pointer
transition simpler).

Zephyr does not implement a split address space and if multiple
page tables are in use, they all have the same virtual-to-physical
mappings (with potentially different permissions).

Direct dependencies

MMU

(Includes any dependencies from ifs and menus.)

Default

  • 0x0

Kconfig definition

At arch/Kconfig:613

Included via Kconfig:8Kconfig.zephyr:39

Menu path: (Top) → Enable MMU features

config KERNEL_VM_BASE
    hex "Virtual address space base address"
    default 0x0
    depends on MMU
    help
      Define the base of the kernel's address space.

      By default, this is the same as the DT_CHOSEN_Z_SRAM physical base SRAM
      address from DTS, in which case RAM will be identity-mapped. Some
      architectures may require RAM to be mapped in this way; they may have
      just one RAM region and doing this makes linking much simpler, as
      at least when the kernel boots all virtual RAM addresses are the same
      as their physical address (demand paging at runtime may later modify
      this for non-pinned page frames).

      Otherwise, if RAM isn't identity-mapped:
      1. It is the architecture's responsibility to transition the
      instruction pointer to virtual addresses at early boot before
      entering the kernel at z_cstart().
      2. The underlying architecture may impose constraints on the bounds of
      the kernel's address space, such as not overlapping physical RAM
      regions if RAM is not identity-mapped, or the virtual and physical
      base addresses being aligned to some common value (which allows
      double-linking of paging structures to make the instruction pointer
      transition simpler).

      Zephyr does not implement a split address space and if multiple
      page tables are in use, they all have the same virtual-to-physical
      mappings (with potentially different permissions).

(The ‘depends on’ condition includes propagated dependencies from ifs and menus.)