The Xtensa implementation of arch_irq_offload() required that the user
select the correct interrupt manually, and would race with itself if
invoked from separate CPUs (it was saved here by the main
irq_offload() function which has a semaphore to serialize access).
Use the new gen_zsr.py script to automatically detect the highest
available software interrupt, and keep a per-CPU set of
callback/parameter pointers.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use index zero, not one. The Xtensa tools emit the timers in priority
order, and as mentioned in the kconfig warnings using high priority
timers doesn't work. This also makes room for using software
interrupts that can preempt a timer interrupt for test purposes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The nRF5340dk is shipping an external QSPI flash that can be used to do
XIP from. Extend the code_relocation nocopy sample to support this
platform so that part of the functions are executed from internal flash
and others from external flash.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
* Use case of interest:
Some platforms are shipping in parallel to the internal FLASH some other
storage / external FLASH (usually a QSPI FLASH) that can be used to
execute (XIP) code from.
The content of this external FLASH can usually be written at flash time
using proper tools (see for example the case of the external FLASH on
the nRF5340DK that can be written at flash time using nrfjprog).
The external FLASH is a nice addition that is extremely useful when a
large application code doesn't entirely fit on the internal FLASH so
that we could want to move part of it in the auxiliary FLASH to XIP the
code from there.
* The problem:
Right now Zephyr doesn't have a formal and generic way to move at build
time part of the code to a different memory region.
* The current status:
Zephyr is indeed shipping a code_relocation feature but that doesn't
entirely match our needs.
When XIP is enabled, the code_relocation feature is used in Zephyr to
move the selected code (that is to copy text section, to initialize data
and zero bss) from FLASH to SRAM at run time and execute code from SRAM.
The relocation is done by a generated snippet of code that is
memcpy()-ing the right content to the destination region also using some
build-time generated portions of linker script to retrieve start and
destination addresses and regions.
* This patch:
This patch is leveraging the code_relocation code and adding a NOCOPY
feature. This feature is using the code_relocation feature to
dynamically build the linker script snippets but entirely skipping the
run-time code relocation so that the code can be XIP-ed from the
destination region.
* Example:
Let's say that we have a big file called `huge_file.c` that we want to
XIP from the external FLASH that is mapped in an EXTFLASH region.
In this case we should enable `CONFIG_XIP` and
`CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows:
zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY)
zephyr_code_relocate(src/huge_file.c SRAM_DATA)
this means that:
- The .text section of the `huge_file.c` must reside in the EXTFLASH
memory region and we do not need to copy the section there because we
are going to XIP it (and we assume that the file is going to be placed
in the external FLASH at flash time).
- The .data section of the `huge_file.c` must still reside in the SRAM
memory region.
* TODOs:
It's desirable to have the possibility to relocate libraries and
pre-build files instead of source code files.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Do not used generated macro from devicetree subsys directly
in driver.
Remove definition of it's own "FOREACH_STATUS_OKAY".
Redefine "DT_DRV_COMPAT" for each supported compatible string.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
LE Audio builds on top of the BT Host stack, and will
thus require a higher amount of stack size. Even simple
applications using BAP will likely reach the 1024 default
size with the default BAP configurations, and when
we start adding CAP and even TMAP/HAP on top of it, it
will likely increase even further.
The default value of 2048 is unlikely to be reached,
and applications that want to optimize can likely
reduce it, depending on the configuration.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
We use a specific experimental Kconfig option when describing the
behavior of CONFIG_WARN_EXPERIMENTAL.
However, this option may not be experimental forever. This therefore
may go stale. Rather than try to keep generic documentation about
experimental options up to date with whatever the bluetooth subsystem
happens to consider experimental or not, use a placeholder CONFIG_FOO
instead of a real option.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This far time values have been synonymous to integer values. Content
formats like CBOR do use different representation.
Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
As use for simple message with no-segment send or receive.
This will be useful for ram-resource-constrained device.
such as bbc-microbit-v1.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Remove the BT_AUDIO_DEBUG Kconfig option.
Given that all the audio modules are guarded by the BT_AUDIO config,
it seems excessive to also have a separate guard for audio module
debug. It is sufficient that this is turned on/off module by module.
Note that the BT_AUDIO_DEBUG was also located in the wrong file - the
babs Kconfig file, not the main Kconfig file.
Signed-off-by: Asbjørn Sæbø <asbjorn.sabo@nordicsemi.no>
Remove the check for BT_AUDIO from the Kconfig files that had it, for
consistency (some files did not have it).
This check is not required - all Kconfig.* files are sourced from the
main Kconfig file _only_ if BT_AUDIO has been configured. As long as
this is the case, it is not required to check in the files themselves.
Signed-off-by: Asbjørn Sæbø <asbjorn.sabo@nordicsemi.no>
Added support for Portfolio object support because LwM2M v1.1 conformance
test requirement that. This object is only for conformance test purposing.
Signed-off-by: Juha Heiskanen <juha.heiskanen@nordicsemi.no>
Before this change, enabling CONFIG_BT_SETTINGS and calling
settings_load(), but delaying / not calling bt_enable would trigger an
assertion error due to a timeout. The fault is that the settings load
handler for the Bluetooth host assumes bt_enable has already been called
and sends HCI commands to the controller. This times out if HCI is not
running.
The fix is to skip loading Bluetooth settings before bt_enable. The doc
is updated to guide the user on how to enable Bluetooth after settings
have been loaded before.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
This structure is no longer used by drivers. Instead, each driver is
responsible to define the required fields and the types that are needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only. Since the config struct can now store a pointer to
the UART structure, casts from address to (struct _uart*) are no longer
needed. UART_STRUCT has also been dropped in favor of using the config
pointer directly now that it is possible.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only. Since the config struct can now store a pointer to
the UART structure, casts from address to (struct pl011_regs *) are no
longer needed. PL011_REGS has also been dropped in favor of using the
config pointer directly now that it is possible.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only. Since the config struct can now store a pointer to
the UART structure, casts from address to (UART_T *) are no longer
needed. UART_STRUCT has also been dropped in favor of using the config
pointer directly now that it is possible.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only. Since the config struct can now store a pointer to
the UART structure, casts from address to (struct uart_reg *) are no
longer needed. HAL_INSTANCE has also been dropped in favor of using the
uart field from the config struct now that it is possible.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only. Since the config struct can now store a pointer to
the UART structure, casts from (uint8_t *) to (struct uart_cmsdk_apb*)
are no longer needed. UART_STRUCT has also been dropped in favor of
using the config pointer directly now that it is possible.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a driver specific configuration structure, containing the
required fields only.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
When CONFIG_PM=y, the IRQ function also needs to be stored, something
the "generic" uart_device_config cannot support. This uses the config
irq_config_func field to store the function in all situations, thus
removing unnecessary logic and finally dropping uart_device_config.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Instead of using "generic" uart_device_config fields, store the right
pointer to avoid unnecessary casts. This change makes code simpler and
more idiomatic.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
As already done for the regular linker script, dinamically generates the
memory regions with the 'zephyr,memory-region' compatible also when
using the cmake linker generator.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Introduce a new "zephyr,memory-region" compatible to be used when a new
memory region must be created in the linker script from the devicetree
nodes using the compatible.
Remove also the LINKER_DT_REGION_FROM_NODE macro and add a new
LINKER_DT_REGIONS macro to cycle through all the compatible regions.
In the same PR modify the DTS files and the linker scripts.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add a new cmake extension function:
dt_comp_path(<var> COMPATIBLE <compatible> [INDEX <idx>])
to get a list of paths for the nodes with the given <compatible>. This
is useful when we have to cycle through several nodes with the same
compatible.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This enables the below configuration so the AP and EC are able to
communicate over eSPI:
CONFIG_ESPI_PERIPHERAL_EC_HOST_CMD
CONFIG_ESPI_PERIPHERAL_ACPI_SHM_REGION
CONFIG_ESPI_PERIPHERAL_CUSTOM_OPCODE
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
This align the RISC-V linker script with ARM linker script.
(The snippets-ram-sections.ld is included first inside the
RAMABLE_REGION)
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
When sleep modes are used, configure sockets
to restore on boot. Letting the HL7800 manage
this means the driver does not have to do it.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
- Prevent double callback with ADV re-scheduling
For configurations using CONFIG_BT_CTLR_JIT_SCHEDULING, when last
ADV before initiating connection is re-scheduled with a small delay,
the disabled_cb would be called a second time. This would unexpectedly
invoke a second conn setup with illegal parameters.
To avoid this JIT scheduler phenomenon, clear the ADV disabled_cb
when invoked.
- Add priority to LLL header. This allows the conn priority to be
associated with the object. Used in vendor LLL implementation.
Signed-off-by: Morten Priess <mtpr@oticon.com>
Currently, the DCACHE range invalidation can cause data corruption when
the ends of the given range is not aligned to a full cache line.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Do not retransmit a message that just has been send successfully.
This case can in particular happen quite frequently if the modem
connection/throughput is quite bad and so there is a high latency.
A message that has to be acknowledged is scheduled for retransmission.
Before retransmission a ack for this message is received that will
cause a reset of the original message. In this case you see a
"LwM2M message is invalid" error message.
Signed-off-by: Andreas Chmielewski <andreas.chmielewski@grandcentrix.net>
fixtures could also be given by twister command with --fixture option
explicitly, not only hardware map file. In this case, we should
assign those fixtures to each devices too.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
No reason to exclude this platform, we only have been using wrong
logging defaults (which was set in the soc) and not printing log
messages which is required by the test.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
We are enabling logging in the SoC, this should be an application
decision, not a hardware decision.
Additionally, we are disabling logging defaults for testing, which
results in some tests failing on those platforms due to missing messages
in the test output.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
After PR: https://github.com/zephyrproject-rtos/zephyr/pull/38296
If we receive the second recovery after 192 hours after the first
recovery, we may still not be able to perform any recovery, even
if the IV Index differs by 42, because the `ivi_was_recovered` flag
will only be cleared during the iv update.
But still May lose iv update, as we did the first iv recovery.
This patch by checking the iv duration, if 192h later, auto clear
`ivi_was_recovered` flag.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
