Commit 73cb9586ce renamed linker
section from _k_memory_pool to _k_mem_pool, but the references
in linker scripts are still there. So remove them now.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add a note in the documentatation of _setup_new_thread()
function stating that the caller is responsible for
providing a size argument that corresponds to the availabe
thread stack area.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The commit adds an __ASSERT statement when configuring
the ARMv8-M build-in stack guard for supervisor thread
stack overflow protection, to catch the case when the
stack_info.start does not point to the beginning of the
thread stack allocated area, pointed by stack_obj.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit does the following:
- moves the reservation of the area for local thread data
inside the arch-specific _new_thread() function,
- aligns the end of the thread's stack with the granularity
of the MPU, already at thread's initialization, moving it
out of userspace_enter() function. In this way, the local
thread data are stored inside the thread stack area that
is, later, assigned unprivileged RW permissions (if thread
enters user mode).
- passes the right thread stack size information to function
_new_thread_init(), which stores it into stack_info.start.
As a result, the whole usable User Thread stack area (i.e.
excluding a possible guard area) falls inside the region
programmed as unprivileged RW, during context-switch.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit forces architecture-specific implementation for
initializing the are for user mode local thread data. This
has been enforced already for ARC. We now do the same for ARM.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit corrects and improves the documentation for the
convenience macro _ARCH_THREAD_STACK_SIZEOF(sym). It stresses
that the returned size is guaranteed to match the amount of
stack that is available for the thread, that is, excluding any
areas not directly usable, e.g. a Stack Guard.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This patch introduce logging to settings.
Error in stored data record might occurred in runtime, so
better to switch assertion to error logging.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
If the rc = -EAGAIN from mqtt_read_publich_payload(), it shouldn't be
used in memcpy() since it is a negative value, and instead, it should
try to read again.
Fix: #13825
Coverity-CID: 191002
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
The Kconfig.defconfig.efr32* files added redundant dependencies on
SOC_EFM32* that are already added in the Kconfig.defconfig.series files
that source them.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Ram back-end was unnecessary included in non qemu test which
increased RAM footprint much.
Patch includes ram backend into build only for qemu_x86 build.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Use the generic option WDT_DISABLE_AT_BOOT instead of the SAM specific
one WDT_SAM_DISABLE_AT_BOOT (note the generic one has been introduced
after the SAM one).
This also have the consequence of changing the default value for yes to
no, fixing the watchdog tests.
Fixes#13290
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Use the new net_pkt allocator. Fix a small leak in the test as well.
No need to build the net_pkt, just send the data directly through
net_context_sendto_new()
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The very first test was basically testing the checksum calculation. And
that's already tested in more relevant tests. It was also trying in a
cumbersome way to generate packets scattered over many net_buf. But
that's also already tested in various other tests, and it's not at all
part of core utils anyway.
In any case, that all redundant, so let's remove it.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
No need to build the net_pkt, just send the data directly through
net_context_sendto_new()
Use the new net_context option to enable timestamping of outgoing
packet (NET_CONTEXT_TIMESTAMP).
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Though core system is able to manage packet timestamping internaly (gptp
requires it for instance), it might be necessary to enable/disable
packet timestamping from net context directly.
Currently this will be only used by the tx timestamp test. So this
support is disabled by default. (And gptp does not require it anyway).
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is required if traffic class is enabled, so allocated packets from
net_context do get the right priority set.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Just a quick rm/mv. The new API is going to be the only one, so legacy
test can disappear.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
That can be useful on some tests which will not have any interface but
still allocate net_pkt. Also, one may allocate a packet with buffer not
knowing yet the interface it will be send through.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
No need to build the net_pkt, just send the data directly through
net_context_sendto_new()
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
s/0/K_NO_WAIT for all timeouts
And fix tcp context connect call (it's not net_context_listen obviously,
and one parameter was missing).
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
No need to build the net_pkt, just send the data directly through
net_context_sendto_new()
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
In case of early crash, shell will not output logs. Added
documentation explaining how to handle such situations.
It is recommended to enable simple logger backend (RTT, UART)
which are available earlier.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
* Registration of interrupt context callbacks from user mode
is forbidden.
- Remove can_attach_isr() as a system call
- Enforce that can_send() has a NULL callback parameter
* k_msgq are kernel objects that do not live in user memory.
Fix the checks for it in can_attach_msgq().
* CAN API documentation was with the API struct typedefs and
not the actual APIs. Moved.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The architecture document contained old information and is now
updated to match the reality.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
drivers/pwm/Kconfig.esp32 is 'source'd within an 'if PWM' in
drivers/pwm/Kconfig.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Appears within a menu that already has 'depends on ARM_SECURE_FIRMWARE'.
'depends on FOO' on a menu will add 'depends on FOO' to each item within
it. 'if FOO' work similarly.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Appears within an 'if IMG_MANAGER'.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
subsys/usb/Kconfig 'source's subsys/usb/class/Kconfig (which in turn
'source's subsys/usb/class/netusb/Kconfig) within an
'if USB_DEVICE_STACK', so the dependencies on USB_DEVICE_STACK added
within those files are redundant.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
subsys/bluetooth/common/Kconfig and subsys/bluetooth/host/Kconfig are
'source'd within 'if BT' and 'if BT_HCI', in subsys/bluetooth/Kconfig,
so there's no need to add those dependencies within them.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Appears within a menu that already has a 'depends on ARCH_POSIX'.
'depends on FOO' on a menu will add 'depends on FOO' to each item within
it. 'if FOO' work similarly.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Appears within an 'if BOARD_NRF52_BSIM' in the same file.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Appears within an 'if BOARD_NATIVE_POSIX' in the same file.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
I2S_STM32 is already within an 'if I2S', in drivers/i2s/Kconfig.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
I2C_EEPROM_SLAVE is already within an 'if I2C_SLAVE', in
drivers/i2c/slave/Kconfig.
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
These symbols appear within an 'if COUNTER' (in
drivers/counter/Kconfig).
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
These symbols appear within an 'if CLOCK_CONTROL' (in
drivers/clock_control/Kconfig).
'if FOO' is just shorthand for adding 'depends on FOO' to each item
within the 'if'. Dependencies on menus work similarly. There are no
"conditional includes" in Kconfig, so 'if FOO' has no special meaning
around a source. Conditional includes wouldn't be possible, because an
if condition could include (directly or indirectly) forward references
to symbols not defined yet.
Tip: When adding a symbol, check its dependencies in the menuconfig
('ninja menuconfig', then / to jump to the symbol). The menuconfig also
shows how the file with the symbol got included, so if you see
duplicated dependencies, it's easy to hunt down where they come from.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Daniel Leung