Instead of casting k_delayed_work directly to k_work, use the
k_work field name. This avoids warnings from Coverity and
allows the code to work even if the k_delayed_work fields are
re-ordered in the future.
Coverity-CID: 214346
Fixes#28659
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Move init_timer_data() out of k_usleep() tick alignment.
Compute rem_ticks just after busy_wait_ms() to avoid slew
due to 'now' and 'rem_ms' computations.
With slow CPU 32MHz: -2 Ticks.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Insert k_usleep(1) just before k_timer_start()
to guaranty tick alignment for step "test_timer_k_define"
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
The up_squared board suffers the same issue as qemu_x86_64
where a bigger stack is needed but CMSIS has a limit on
how big the stack can be. This results in stack overflow.
So exclude up_squared in samples.yaml.
Fixes#28552
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
See schematics of the board: MB1297
both user leds LD1 and LD2 are active high.
Fixes#28665
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
The up_squared board suffers the same issue as qemu_x86_64
where a bigger stack is needed but CMSIS has a limit on
how big the stack can be. This results in stack overflow
on one of the test.
Also, the thread API tests are not designed with SMP in mind.
The osThreadGetCount() would return a value smaller than
expected. This function only counts queued threads, where with
SMP, there are more CPUs running threads and thus fewer queued
ones.
So exclude up_squared from the test.
Fixes#27571
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Removing frdm_k64f from the allowed list of platforms to test.
Power management support has not been added and/or verified for
frdm_k64f platform yet.
Fixes: #27821
Signed-off-by: David Leach <david.leach@nxp.com>
Fix the redundant PDU transmission when the new Tx PDU
buffer is enqueued after MD bit value of zero was
transmitted previously in a connection event.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
When doing test_thread_join with OTHER_ABORT_TIMEOUT, the interval
between two k_uptime_get() includes the two k_thread_create() which
means the interval delta does not exactly count the time spent
in k_thread_join(). On x86_64 with userspace, time spent inside
k_thread_create() scales with memory size as it needs to create
a new page table for the thread. So to actually measure
the time spent in k_thread_join(), the locations where uptime is
obtained need to be moved.
Fixes#28549
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
nRF51 MCUs are Cortex-M0 running with a 16 MHz clock. The overhead of
work done in k_usleep() requires adding three more ticks (92 us) to the
expected loop iteration time. (Two ticks is enough on most boards, but
some require a little more time.)
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
update rt6xx series sram mapping to skip 0x180000,
reserved for DSP usage.
this fixes tests/subsys/debug/coredump for this board
Signed-off-by: Hake Huang <hake.huang@oss.nxp.com>
Commit 5632ee26f3 introduced an issue where in order to use MMIO
configuration:
- do_pcie_mmio_cfg is required to be true
- Only set to true in pcie_mm_init()
- Which is only called from pcie_mm_conf()
- Which is only called from pcie_conf() if do_pcie_mmio_cfg is
already true!
The end result is that MMIO configuration will never be used.
Fix the situation by moving the initialization check to pcie_conf().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
fixes following cmake warning:
CMake Warning at ../../kernel/CMakeLists.txt:54 (message):
Single threaded mode (CONFIG_MULTITHREADING=n) is deprecated
Signed-off-by: Alexander Kozhinov <AlexanderKozhinov@yandex.com>
- They all had the wrong prototype and hard-casts can sometimes
lead to problems
- Several renamed to something more descriptive
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Per TSC we will document deprecation for 2.4 but not add
__deprecated tags until the 2.5 merge window opens.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Deprecate the Kconfig option for the time being. Unless a contributor
volunteers to take over the work to maintain the option, it will be
removed after 2 releases.
Relates to #27415.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Add dependency to UDP in DHCPv4 Kconfig option as UDP is needed
in DHPCv4 to work properly.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The condition used to detect presence of optional devicetree
properties that specify read and write opcodes was inadvertently
changed to something that will never be true. Update the check and
the property extraction to restore the original behavior.
Fixes#28635.
Signed-off-by: Stephan Walter <stephan@walter.name>
Amend Doxygen documentation for k_msgq_put to note that the message
content will not be modified as a result of the function call and
constify data parameter in function prototype.
Fixes#22301
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
The ce0cc3a7 commit (lsm6dsl: make the driver multi-instance) changes
all bus API signature, which now requires a "const struct device *dev"
and not a "struct lsm6dsl_data *data". By mistake the shub part was
left unchanged. Fix: #28565
Signed-off-by: Armando Visconti <armando.visconti@st.com>
An execution path could reach a loop that dereferences a pointer in
conditions where the pointer is null. Add a check to the loop
condition.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Lowering the connection timeout in order to avoid spin lock assert
in frdm_k64f device. This error was seen with this device
ASSERTION FAIL [z_spin_lock_valid(l)] @ zephyr/include/spinlock.h:92
Recursive spinlock 0x20003590
Fixes#28602
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The HAS_NRFX Kconfig option is selected also for the nrf52_bsim board,
where the nrfx drivers are compiled for a simulated target, without
CMSIS. Thus, selecting HAS_CMSIS_CORE in such case is inappropriate.
This patch removes then the selection of the HAS_CMSIS_CORE option from
HAS_NRFX. When the nrfx drivers are built for a real SoC, where CMSIS
is actually used, the option will get selected by the CPU_CORTEX_M one.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Bug description:
When in tcp_conn_unref(), in case one of the delayed works is already
submitted to sysworkq (after delay period), e.g. send_timer, the check
of k_delayed_work_remaining_get() prevents calling
k_delayed_work_cancel().
This leads to corrupting sysworkq when zeroing struct tcp* conn.
Note that the "next" pointer for the work queue is part of the struct
work (in _reserved field). Which is, in this case, a member of struct
tcp.
Scenario leading to the bug:
(1) net_tcp_connect() is called from a work in sysworkq
(2) net_tcp_connect() submits conn->send_timer to sysworkq
(3) while net_tcp_connect() is waiting on connect_sem, delay period
passes (z_timeout) and send_timer enters sysworkq work slist
(4) also, some other code (app) submits more works to queue, now pointed
by conn->send_timer in sysworkq work list
(5) connection fails (no answer to SYN), causing a call to
tcp_conn_unref()
(6) tcp_conn_unref() is calling tcp_send_queue_flush()
(7) checking k_delayed_work_remaining_get(&conn->send_timer) returns 0
due to delay period end, but send_timer is still in sysworkq work
slist (sysworkq thread still hasn't handled the work)
(8) BUG!: no call to k_delayed_work_cancel(&conn->send_timer)
(9) back in tcp_conn_unref(), a call to memset(conn, 0, sizeof(*conn))
zeroes conn->send_timer
(10) conn->send_timer is pointed to in sysworkq work slist, but is
zeroed, clearing pointer to following works submitted in stage (4)
(11) EFFECT! the works in stage (4) are never executed!!
NOTES:
* k_delayed_work_cancel(), handles both states:
(1) delayed work pends on timeout and
(2) work already in queue.
So there is no need to check k_delayed_work_remaining_get()
* This is also relevant for conn->send_data_timer
Solution:
removing checks of k_delayed_work_remaining_get(), always calling
k_delayed_work_cancel() for work in struct tcp, in unref, before memset
Signed-off-by: David Komel <a8961713@gmail.com>
We only need to offset the start of the non-secure image
by 0x400, if TFM is built with BL2 support. In this case
we use the ROM_START_OFFSET Kconfig switch and we set it
to 0x400, which is the default BL2 Header size value in
TF-M builds. This instructs the linker to offset the beginning
of the ROM section by 0x400. In other words, we do not need
to statically move the start of the image by 0x400 (using
FLASH_BASE_ADDRESS or FLASH_LOAD_OFFSET) when building for
nucleo_l552ze_q 'non-secure'. This fixes an issue that
prevents from running Zephyr + TFM without BL2 support.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
If the location counter ('.') is within the area that the veneers
should go, the current solution will give a linker error ("Cannot move
location counter backwards"). This patch places the veneers in the next
SPU region in this case.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
The current instrumentation point for CONFIG_TRACING added in
PR #28512 had two problems:
- If userspace and KPTI are enabled, the tracing point is simply
never run if we are resuming a user thread as the
z_x86_trampoline_to_user function is jumped to and calls
'iret' from there
- Only %rdi is being saved. However, at that location, *all*
caller-saved registers are in use as they contain the
resumed thread's context
Simplest solution is to move this up near where we update page
tables. The #ifdefs are used to make sure we don't push/pop
%rdi more than once. At that point in the code only %rdi
is in use among the volatile registers.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Instead of hardcoding the priority1 and priority2 values used
in BMCA, let the user tweak the values via Kconfig.
Fixes#28151
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This commit fixes the zephyr_get_system_include_directories_for_lang()
function in the event that no system include directories are specified
for Zephyr interface.
This fixes an issue where the value returned by this function is
`-isystem` with no directory.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
From 2.3 to 2.4 the net samples pair echo-server/client increase the
SRAM requirements. Since CI doesn't build all combinations, (even for
a release like 2.4.0-rc1) the problem was detected only now. Decrease
buffers for atsamr21_xpro on both echo_server/client sample pair.
Fixes#28341.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
When added bluetooth over USB shell overlay, the
file was by mistake added with wrong extension.
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
We only need to offset the start of the non-secure image
by 0x400, if TFM is built with BL2 support. In this case
we use the ROM_START_OFFSET Kconfig switch and set to
0x400. This instructs the linker to offset the beginning
of the ROM section by 0x400. In other words, we do not need
to statically move the start of the image by 0x400. This
fixes an issue that prevents from running Zephyr + TFM
without BL2 on Musca B1.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We only need to offset the start of the non-secure image
by 0x400, if TFM is built with BL2 support. In this case
we use the ROM_START_OFFSET Kconfig switch and set to
0x400. This instructs the linker to offset the beginning
of the ROM section by 0x400. In other words, we do not need
to statically move the start of the image by 0x400. This
fixes an issue that prevents from running Zephyr + TFM
without BL2 on MPS2 AN521.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When we build Zephyr for a Non-Secure image, using TFM
as the Secure counterpart, we may or may not use BL2 (e.g.
MCUboot in TFM). If we build with BL2 we need to account
for a ROM offset before the start of the non-secure image
where TFM BL2 expects the BL2 header. This offset is not
needed when TFM is built without BL2. We use the existing
Kconfig options to determine whether we need a ROM offset
or not. We use the value of 0x400 for the BL2 header,
which is the default value used in TFM, but the option is
non-hidden, allowing the user to overwrite the default
value if needed.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
