Replaces the previous approach to define bands via hardware capabilities
by the standard conforming concept of channel pages.
In the short term this allows us to correctly calculate the PHY specific
symbol rate and several parameters that directly depend from the symbol
rate and were previously not being correctly calculated for some of the
drivers whose channel pages could not be represented previously:
* We now support sub-nanosecond precision symbol rates for UWB. Rounding
errors are being minimized by switching from a divide-then-multiply
approach to a multiply-then-divide approach.
* UWB HRP: symbol rate depends on channel page specific preamble symbol
rate which again requires the pulse repetition value to be known
* Several MAC timings are being corrected based on the now correctly
calculated symbol rates, namely aTurnaroundTime, aUnitBackoffPeriod,
aBaseSuperframeDuration.
In the long term, this change unlocks such highly promising functional
areas as UWB ranging and SUN-PHY channel hopping in the SubG area (plus
of course any other PHY specific feature).
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Adds note on addition of
MCUBOOT_BOOTLOADER_MODE_WITH_DOWNGRADE_PREVENTION
to MCUboot Kconfig module.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
This adds a note on the changes related to the device
initialization macros and removal of two kconfigs.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
Add support of mounting littlefs on the block device from the shell/fs.
Add alignment parameter to FS_LITTLEFS_DECLARE_CUSTOM_CONFIG macro.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
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>
Adds a note on the stable API change of changing the MCUmgr SMP
version 2 error entry name to avoid a collision with shell_mgmt
which already used "ret".
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Document the changes implemented in #60368:
* Placement of the .bss and .noinit sections at the end of the binary
so that large zero-/uninitialized data structures such as heaps,
arrays etc. don't have to be padded in the resulting binary.
* Location of the z_mapped_start marker: prevents the assignment
of the single 4k-page wide .vectors section right at the RAM
base address as dynamic memory by the MMU at run-time. Instead
of pointing to the start of the subsequent .text section, the
z_mapped_start marker now covers all the data contained within
the binary that ends up in RAM.
Signed-off-by: Immo Birnbaum <mail@birnbaum.immo>
List `DT_MEM_FROM_FIXED_PARTITION()` and `DT_FIXED_PARTITION_ADDR()` as
the newly added macros.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Remove CONFIG_OCRAM_NOCACHE setting, as this is now possible to achieve
using devicetree linker regions, and there is no point in having a
specific Kconfig for one memory region on the RT series like this.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Enable SOC fixed MPU regions by default for the RT10xx/RT11xx SOC lines.
Additionally, add code to handle defining the SDRAM0 region as
device type (non cacheable, non shareable). This behavior can
be disabled with CONFIG_NXP_IMX_EXTERNAL_SDRAM=y. Set this Kconfig
for all boards in tree using SDRAM.
This will resolve an issue present on the RT11xx series where
the core may execute speculative prefetches to the SDRAM region when
no SDRAM is present on the board, resulting in the system faulting.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Don't default CONFIG_DEVICE_CONFIGURATION_DATA to enabled for iMX RT
SOCs, as this configuration block is only used when the board needs
peripherals like the external memory controller setup from reset by the
bootrom.
Enable this feature on all in tree boards that will require it,
and document the change to the default value in release notes.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Drop the notes about listing all the github issues with the release
notes. That was a huge list of github issues sorted by closing time,
very noisy and hard to maintain.
The unfiltered list of changes is already in the commit history, a
distilled list is now in the blog posts and a final list is in the notes
summary.
The issue list has been skipped in 3.4 already, let's just drop it from
the process.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The current default value for `BOOTLOADER_SRAM_SIZE` is set to an
arbitrary-seeming value of `16`, which feels like a random magic
number.
Given that adding an offset in SRAM for a bootloader should always be
a conscious choice for a specific platform, this PR sets the default
to `0`. An appropriate value can be set at the SoC or board level,
overriding this default.
Signed-off-by: Kevin Townsend <kevin.townsend@linaro.org>
Documents the changes to the naming of the cc13/26xx timer compatible
and Kconfig options.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Adds a note that this MCUmgr notification hook can now be used
to reject commands and send an error back to the client.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
