After having migrated a bunch of apps to the new default C library we
have realized that some of the caveats described in the existing
picolibc section of the migration guide do require action on the user
more often than previously thought. In order to ensure that all users
see those and can act upon them, move the picolibc migration info to the
required changes section.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Because devices share the same underlying infrastructure with SYS_INIT,
the same levels have always been available. However, not all of them are
needed, and some are not even usable. For example, `EARLY` can't be used
because when initialized `z_device_state_init` has not been called yet.
`SMP` has never been used by device drivers, and it is now in question,
likely to be moved to SMP specific hooks. Finally, `APPLICATION` does
not make much sense in the context of Kernel devices. Note that of the 3
levels just mentioned, only one was actively tested (`APPLICATION`) by
Kernel tests, meaning others were likely never considered in the context
of devices.
This patch leaves `PRE_KERNEL_1`, `PRE_KERNEL_2` and `POST_KERNEL`
available to devices. Others have been deprecated, and will generate a
compiler warning if used.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
MODEM_GSM_PPP is deprecated in favor of using the new
MODEM_CELLULAR driver.
Directly related to this are UART_MUX and GSM_MUX. These are also
being deprecated.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
Clarified the impact of CONFIG_NET_INTERFACE_NAME Kconfig option
as it can change how SO_BINDTODEVICE BSD socket option behaves.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
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>
There aren't any 'required' or 'recommended' changes when switching from
the minimal C library to picolibc, but there are a bunch of things which
application developers might need to be aware of. Add a separate section to
list those.
Signed-off-by: Keith Packard <keithp@keithp.com>
Modify the signature of the k_mem_slab_free() function with a new one,
replacing the old void **mem with void *mem as a parameter.
The following function:
void k_mem_slab_free(struct k_mem_slab *slab, void **mem);
has the wrong signature. mem is only used as a regular pointer, so there
is no need to use a double-pointer. The correct signature should be:
void k_mem_slab_free(struct k_mem_slab *slab, void *mem);
The issue with the current signature, although functional, is that it is
extremely confusing. I myself, a veteran Zephyr developer, was confused
by this parameter when looking at it recently.
All in-tree uses of the function have been adapted.
Fixes#61888.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Instead of documenting API changes, deprecations, additions and
deletions in the main release notes, create a new specific document to
help users migrate from one release to another one.
This new document has only two sections:
- Required changes
- Recommended changes
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Co-authored-by: Benjamin Cabé <kartben@gmail.com>
