2022-04-04 22:40:37 +08:00
|
|
|
.. _os_services:
|
|
|
|
|
|
|
|
|
|
OS Services
|
|
|
|
|
###########
|
|
|
|
|
|
|
|
|
|
.. toctree::
|
|
|
|
|
:maxdepth: 1
|
|
|
|
|
|
2022-04-04 22:41:46 +08:00
|
|
|
|
2023-03-26 03:52:41 +08:00
|
|
|
binary_descriptors/index.rst
|
2023-11-06 22:37:58 +08:00
|
|
|
console.rst
|
2022-04-04 23:23:10 +08:00
|
|
|
crypto/index
|
2022-04-04 22:46:11 +08:00
|
|
|
debugging/index.rst
|
2022-04-05 22:33:17 +08:00
|
|
|
device_mgmt/index
|
2022-10-07 13:54:46 +08:00
|
|
|
dsp/index.rst
|
2022-04-04 23:17:53 +08:00
|
|
|
file_system/index.rst
|
2022-04-04 22:53:48 +08:00
|
|
|
formatted_output.rst
|
2023-02-14 01:12:01 +08:00
|
|
|
input/index.rst
|
2022-10-24 18:20:20 +08:00
|
|
|
ipc/index.rst
|
2023-09-27 21:12:45 +08:00
|
|
|
llext/index.rst
|
2022-04-04 22:41:46 +08:00
|
|
|
logging/index.rst
|
2022-04-04 22:46:11 +08:00
|
|
|
tracing/index.rst
|
2022-04-04 22:47:04 +08:00
|
|
|
resource_management/index.rst
|
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
|
|
|
mem_mgmt/index.rst
|
2022-04-06 06:06:14 +08:00
|
|
|
modbus/index.rst
|
2023-10-14 22:24:56 +08:00
|
|
|
modem/index.rst
|
2022-04-04 22:51:01 +08:00
|
|
|
notify.rst
|
2022-04-04 22:55:06 +08:00
|
|
|
pm/index.rst
|
2022-04-06 05:36:48 +08:00
|
|
|
portability/index.rst
|
lib: os: add support for system power off
Add a new API to perform an immediate system power off:
`sys_poweroff()`.
Until now, this functionality has been implemented via the system power
management module, but in a clunky fashion. The way system PM works is
by defining some idle states in devicetree, that, given some properties
(e.g. minimal residency, exit latency, etc.) are automatically selected
when system goes to idle based on the expected next wake-up. However,
system off is a power state that one typically wants to control manually
from the application because it implies state loss, and in most cases,
configuring some sort of wake-up source. So in general, it is not
desired to let the system enter this state automatically. This led to
the following stuff in-tree:
from `boards/arm/mimxrt595_evk/mimxrt595_evk_cm33.dts`:
```c
/*
* Deep power-down mode is supported in this SoC through
* 'PM_STATE_SOFT_OFF' state. There is no entry for this in device tree,
* user can call pm_state_force to enter this state.
*/
```
That is, state not being defined in devicetree so that PM subsystem
doesn't pick it automatically, but still implemented in in the PM hooks:
from `soc/arm/nxp_imx/rt5xx/power.c`, `pm_state_set()`:
```c
case PM_STATE_SOFT_OFF:
set_deepsleep_pin_config();
POWER_EnterDeepPowerDown(EXCLUDE_FROM_DEEP_POWERDOWN);
break;
```
And to actually make use of this state, users had to do this kind of
abominations:
```c
pm_state_force(0u, &(struct pm_state_info){ PM_STATE_SOFT_OFF, 0, 0 });
/* Now we need to go sleep. This will let the idle thread runs and
* the pm subsystem will use the forced state. To confirm that the
* forced state is used, lets set the same timeout used previously.
*/
k_sleep(K_SECONDS(SLEEP_S));
printk("ERROR: System off failed\n");
while (true) {
/* spin to avoid fall-off behavior */
}
```
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2023-07-20 17:46:41 +08:00
|
|
|
poweroff.rst
|
2022-04-04 22:51:52 +08:00
|
|
|
shell/index.rst
|
2022-04-04 22:52:33 +08:00
|
|
|
settings/index.rst
|
2022-04-05 04:10:35 +08:00
|
|
|
smf/index.rst
|
2022-04-05 22:55:10 +08:00
|
|
|
storage/index.rst
|
2022-08-23 10:00:56 +08:00
|
|
|
sensing/index.rst
|
2022-04-05 22:55:10 +08:00
|
|
|
task_wdt/index.rst
|
2022-04-06 05:24:02 +08:00
|
|
|
tfm/index
|
2022-04-06 06:06:14 +08:00
|
|
|
virtualization/index.rst
|
2023-02-28 21:04:56 +08:00
|
|
|
retention/index.rst
|
2019-06-26 23:17:18 +08:00
|
|
|
rtio/index.rst
|
2022-07-31 10:40:36 +08:00
|
|
|
zbus/index.rst
|
2022-04-06 06:06:14 +08:00
|
|
|
misc.rst
|