zephyr/subsys/CMakeLists.txt

57 lines
2.1 KiB
CMake
Raw Normal View History

# SPDX-License-Identifier: Apache-2.0
# FIXME: SHADOW_VARS: move this before adding shadow variable warning below.
# This is because, in some build configurations, the external lorawan module
# is pulled in as though the source files are in main repo. This results in
# shadow variable warnings being active on these files. Until the module has
# fixed those shadow variables, keep this here before add_compile_options()
# below.
add_subdirectory_ifdef(CONFIG_LORAWAN lorawan)
# FIXME: SHADOW_VARS: Remove this once we have enabled -Wshadow globally.
add_compile_options($<TARGET_PROPERTY:compiler,warning_shadow_variables>)
# zephyr-keep-sorted-start
add_subdirectory(canbus)
add_subdirectory(debug)
add_subdirectory(fb)
add_subdirectory(fs)
add_subdirectory(ipc)
add_subdirectory(logging)
dt: Make zephyr,memory-attr a capabilities bitmask This is the final step in making the `zephyr,memory-attr` property actually useful. The problem with the current implementation is that `zephyr,memory-attr` is an enum type, this is making very difficult to use that to actually describe the memory capabilities. The solution proposed in this PR is to use the `zephyr,memory-attr` property as an OR-ed bitmask of memory attributes. With the change proposed in this PR it is possible in the DeviceTree to mark the memory regions with a bitmask of attributes by using the `zephyr,memory-attr` property. This property and the related memory region can then be retrieved at run-time by leveraging a provided helper library or the usual DT helpers. The set of general attributes that can be specified in the property are defined and explained in `include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be extended when needed). For example, to mark a memory region in the DeviceTree as volatile, non-cacheable, out-of-order: mem: memory@10000000 { compatible = "mmio-sram"; reg = <0x10000000 0x1000>; zephyr,memory-attr = <( DT_MEM_VOLATILE | DT_MEM_NON_CACHEABLE | DT_MEM_OOO )>; }; The `zephyr,memory-attr` property can also be used to set architecture-specific custom attributes that can be interpreted at run time. This is leveraged, among other things, to create MPU regions out of DeviceTree defined memory regions on ARM, for example: mem: memory@10000000 { compatible = "mmio-sram"; reg = <0x10000000 0x1000>; zephyr,memory-region = "NOCACHE_REGION"; zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>; }; See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see how an architecture can define its own special memory attributes (in this case ARM MPU). The property can also be used to set custom software-specific attributes. For example we can think of marking a memory region as available to be used for memory allocation (not yet implemented): mem: memory@10000000 { compatible = "mmio-sram"; reg = <0x10000000 0x1000>; zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE | DT_MEM_SW_ALLOCATABLE )>; }; Or maybe we can leverage the property to specify some alignment requirements for the region: mem: memory@10000000 { compatible = "mmio-sram"; reg = <0x10000000 0x1000>; zephyr,memory-attr = <( DT_MEM_CACHEABLE | DT_MEM_SW_ALIGN(32) )>; }; The conventional and recommended way to deal and manage with memory regions marked with attributes is by using the provided `mem-attr` helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT helpers). When this option is enabled the list of memory regions and their attributes are compiled in a user-accessible array and a set of functions is made available that can be used to query, probe and act on regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h` Note that the `zephyr,memory-attr` property is only a descriptive property of the capabilities of the associated memory region, but it does not result in any actual setting for the memory to be set. The user, code or subsystem willing to use this information to do some work (for example creating an MPU region out of the property) must use either the provided `mem-attr` library or the usual DeviceTree helpers to perform the required work / setting. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2023-08-16 18:48:26 +08:00
add_subdirectory(mem_mgmt)
add_subdirectory(mgmt)
add_subdirectory(modbus)
add_subdirectory(pm)
add_subdirectory(portability)
add_subdirectory(random)
add_subdirectory(rtio)
add_subdirectory(sd)
add_subdirectory(stats)
add_subdirectory(storage)
add_subdirectory(task_wdt)
add_subdirectory(testsuite)
add_subdirectory(tracing)
add_subdirectory(usb)
add_subdirectory_ifdef(CONFIG_ARM_SIP_SVC_SUBSYS sip_svc)
add_subdirectory_ifdef(CONFIG_BINDESC bindesc)
add_subdirectory_ifdef(CONFIG_BT bluetooth)
add_subdirectory_ifdef(CONFIG_CONSOLE_SUBSYS console)
add_subdirectory_ifdef(CONFIG_DEMAND_PAGING demand_paging)
add_subdirectory_ifdef(CONFIG_DISK_ACCESS disk)
add_subdirectory_ifdef(CONFIG_DSP dsp)
add_subdirectory_ifdef(CONFIG_EMUL emul)
add_subdirectory_ifdef(CONFIG_IMG_MANAGER dfu)
add_subdirectory_ifdef(CONFIG_INPUT input)
add_subdirectory_ifdef(CONFIG_JWT jwt)
add_subdirectory_ifdef(CONFIG_LLEXT llext)
add_subdirectory_ifdef(CONFIG_MODEM_MODULES modem)
add_subdirectory_ifdef(CONFIG_NET_BUF net)
add_subdirectory_ifdef(CONFIG_RETENTION retention)
add_subdirectory_ifdef(CONFIG_SENSING sensing)
add_subdirectory_ifdef(CONFIG_SETTINGS settings)
add_subdirectory_ifdef(CONFIG_SHELL shell)
add_subdirectory_ifdef(CONFIG_TIMING_FUNCTIONS timing)
add_subdirectory_ifdef(CONFIG_ZBUS zbus)
# zephyr-keep-sorted-stop