Updates wording in Coding Guidelines page to remove outdated timelines
and correct the criteria for each stage. Changes reflect that we are
in stage 1 and will not reach stage 2 until the CI for enforcing
coding guidelines has been established.
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
The root cause of #38591 was region symbols being placed before the
section description for data region.
To support both schemes with the linker generator, a new
`SYMBOL SECTION` argument has been added to the zephyr_linker_group()
function.
This commit updates the arm/linker.cmake CMake linker file to use the
new `SYMBOL SECTION` argument for the data region group and text region
group so that those two groups now behave identical to the behavior when
using the cortex_m linker.ld template.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The root cause of #38591 was region symbols being placed before the
section description for data region.
Some region start symbols are placed before section description, other
region start symbols are placed inside the first section in the region
and thus identical to the sections own first symbol.
To support both schemes with the linker generator, a new
`SYMBOL SECTION` argument has been added to the zephyr_linker_group()
function.
The ld_script.cmake linker script generator has been updated to support
the new argument so that generated ld linker script has identical
behavior to the templated ld linker scripts.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #38591, #38207, #37861
The commit 65a2de84a9 aligned the data
linker symbol for sections and regions.
The data region symbol start has been placed outside the sections thus
being defined as the address of the region before alignment of the first
section in the data region, usually the `datas` section.
The symbol defining the start address of the data section is after
section alignment.
In most cases the address of the data region start and datas section
start will be identical, but not always.
The data region symbol is a new linker symbol and existing code has
been depending on the old data section start symbol.
Thus, the update to the use of the data region start symbol instead of
data ram start symbol thus results in a different address when the
section is aligned to a different address.
To ensure the original behavior in all cases, the data region start
address is now moved inside the data section.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Following the migration of the clock source configuration in DTS (commit
2691541ad2), HSI is always used as wake-up source on STM32LX. It is
reconfigured as MSI just after, but it slightly increase the wake-up
time and power consumption.
It happens as the file defining STM32_SYSCLK_SRC_MSI is not included.
Fix that.
Fixes#38807
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The interrupt config flags for an IO should be separate
from the standard IO configs because the interrupt config
is a separate API.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
When CONFIG_ARM_MPU is explicitly unset in application prj.conf there
were build warnings related with implicit declarations of following
symbols: NRF_DT_GPIOS_TO_PSEL, __WFE, __SEV.
Lack of NRF_DT_GPIOS_TO_PSEL lead to build error due to undeclared
dfegpio0_gpios symbol.
The cause for the warnings and error were missing soc.h includes in
few source files. The missing includes were added in this commit.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
This commit sets the minimum required Zephyr SDK version to 0.13.1,
which fixes the following critical issues:
1. Xtensa initial malloc failure (GitHub issue #38258)
2. ARMv8-M security extension vulnerability (CVE-2021-35465)
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The commit 9bd1483afeb18f4225ec7b0340b0d4e20efb7d01 was added as a
workaround for the Xtensa initial malloc failure bug.
This bug has been fixed in the Zephyr SDK 0.13.1 release and therefore
this workaround is no longer needed.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
k_work_schedule may return other non-negative value than 0.
When driver was adapted to the new k_work API that was not
taken into account.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The Zephyr 2.6 release notes, in the Bluetooth section, refers the user
to a commit message which had a couple of typos in it. Clarify this in
the very release notes.
Fixes#36692.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
RFC 2460 Sec. 5 requires that a ICMPv6 Time Exceeded message is sent
upon reassembly timeout, if we received the first fragment (i.e. the one
with a Fragment Offset of zero).
Implement this requirement.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The purpose of shift_packets() is to make room to insert one fragment in
the list. This is not what it does currently, potentially leading to
-ENOMEM even if there is enough free room.
To see the current behaviour, let's assume that we receive 3 fragments
in reverse order:
- Frag3(offset = 0x40, M=0)
- Frag2(offset = 0x20, M=1)
- Frag1(offset = 0x00, M=1)
After receiving Frag3 and Frag2, pkt[] will look like:
.-------.-------.-------.
| Frag2 | Frag3 | NULL |
| 0x20 | 0x40 | |
'-------'-------'-------'
pkt[0] pkt[1] pkt[2]
When receiving Frag1, shift_packets(pos = 0) is called to make some room
at position 0. It will iterate up to i = 2 where there is a free
element. The current algorithm will try to shift pkt[0] to pkt[2], which
is indeed impossible but also unnecessary. It is only required to shift
pkt[0] and pkt[1] by one element in order to free pkt[0] to insert
Frag1.
Update the algorithm in order to shift the memory only by one element.
As a result, the ENOMEM test is only simpler: as long as we encounter
one free element, we are guaranteed that we can shift by one element.
Also assign a NULL value to the newly freed element since memmove() only
copy bytes.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently net_ipv6_handle_fragment_hdr() performs 2 distinct tests: it
checks the M-bit of the most recent fragment to decide if we can proceed
with the reassembly. Then it performs some sanity checks which can lead
to dropping the whole packet if not successful.
The test on the M-bit assumes that fragments arrive in order. But this
will fail if packets arrive out-of-order, since the last fragment can
arrive before some other fragments. In that case, we proceed with the
reassembly but it will fail because not all the fragments have been
received.
We need a more complete check before proceeding with the reassembly:
- We received the first fragment (offset = 0)
- All intermediate fragments are contiguous
- The More bit of the last fragment is 0
Since these conditions can also detect a malformed fragmented packet, we
can replace the existing sanity check that is performed before
reassembly. As a bonus, we can now detect and rejected overlapping
fragments, since this can have some security issues (see RFC 5722).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently we only store the fragment offset. But in some cases it might
be necessary to also inspect the M-bit (More Fragment) of all received
fragments.
Modify the semantics of the field to store all the flags, rename the
setter to account for this change, and add a getter for the M-bit.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The special handling of the 1st fragment in unnecessary, since it will
be correctly handled even without it. Moreover it causes some corner
cases, like a single packet with a fragment header (M=0), to be
incorrectly handled since the reassembly code is skipped.
Remove the special handling of the 1st fragment to fix these problems.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently the requirement of the length being a multiple of 8 is not
tested for the first fragment, since the first fragment takes a
different path due to the goto.
Move the test earlier in the process, so that it is performed on all
fragments, including the first one.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
If we have less fragments than what can be stored in the reassembly
array, some loops will blindly dereference NULL pointers.
Add checks for NULL pointers when necessary and exit the loop.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently the stack is limited to a maximum of 2 incoming fragments per
packet. While this can be enough in most cases, it might not be enough
in other cases.
Make this value configurable at build time.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently prev_hdr_offset always equals 6, which is the offset of
the nexthdr field in the IPv6 header. This value is used to overwrite it
when removing an IPv6 Fragment header, so it will work as long as there
is no other Extension header between the IPv6 header and the Fragment
header.
However this does not work in the other cases: the nexthdr field of the
IPv6 header will be overwritten instead of the nexthdr field of the last
Extension header before the Fragment, leading to unwanted results.
Update prev_hdr_offset so that it always point to the nexthdr field of
the previous header, either the IPv6 header or an Extension header.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The current validation code waits to process the header before rejecting
it, while some checks can be already enforced when reading the nexthdr
field of the previous header.
The main problem is a wrong pointer field in the resulting ICMPv6 error
message: the pointer should have the offset of the invalid nexthdr
field, while currently it will the offset the invalid header.
To solve that problem, reorganize the loop in two parts: the first
switch validates nexthdr, while the second switch processes the current
header. This allows to reject invalid nexthdr earlier.
The check for duplicated headers is also generalized, so that we can
catch other kind of headers (like the Fragment header).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
By definition, NET_IPV6_NEXTHDR_NONE is void. So we must stop processing
before trying to read any data, since we will start reading values that
are outside the Extension Header (likely the payload, if any).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
When an unknown option is encountered, an ICMPv6 error message must be
sent in some cases. The message contains a pointer field, which must be
the offset to the unknown option. Currently the offset is computed from
the beginning of the option list, while it should be computed with
respect to the beginning of the IPv6 header.
Record the offset when reading the option type and pass it later to
ipv6_drop_on_unknown_option() to correctly set the pointer field. Also
rename the argument in ipv6_drop_on_unknown_option() to make the
purpose more clear.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently PADN data are not skipped, which results in the stack to think
that the next header starts in the middle of the padding. We have to
skip the bytes before going on.
Also clarify the PAD1 does not have any length field.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The current names are confusing. Indeed "nexthdr" if the type of the
header currently processed, while "next_nexthdr" is the nexthdr field of
the current header.
Rename them to improve readability and make it less error-prone.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
ICMPv6 error messages are not sent (on native_posix) because the first
net_pkt_write() returns an error.
pkt has just been allocated using net_pkt_alloc_with_buffer(). Trying to
write an empty packet in overwrite mode will result in an error. There
is no need to be in overwrite mode, since we want to write the LL
src/dst addresses at the beginning.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
There is a copy-paste error in this sample code that results
in a function for input events being called for an output pin.
By chance, this has no influence on the behavior of the sample,
as the function returns a register offset that for events and
tasks is the same for a given channel, but obviously the code
is confusing.
This is fixed by replacing the relevant part with more suitable
function calls, to also simplify the code a little.
On the occasion, also a remark is added about no button debouncing
used in the sample, to prevent users from being surprised by its
possible behavior.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Similarly to what was done on stm32g0, disable DBGMCU clock
after operation to avoid conflict with openocd.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
If clock is not enabled write access on that registers are no-op.
Disable clock after operation to avoid conflicts with openocd which
can also access this clock when flashing.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Enable CONFIG_DEBUG when test is run in CI.
This will allow DGB access in stop modes (and specially flashing)
and avoid potential issues when test in run in a test suite.
Note that on some targets (stm32wb for instance) openocd is able
to do the same operation, and which allows to reflash the target
even if switch was not enabled, but this could not be the case
on all targets.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Adding missing parenthesis. Without them wrong results
appeared when k_cycle_get_32 wrapped.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Fixes: #38463
With 6be1b2af9b then Zephyr shields and
soc Kconfig are always sourced from Kconfig directly.
However, check_compliance.py generates Kconfig files for sourcing the
same files thus sourcing the same files twice.
The end result is a lot of Kconfig warnings as described in #38463.
Removing the generated Kconfig files as this is no longer needed after
6be1b2af9b has been introduced.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #38761
The introduction of zephyr_library_property in #38347 contained a
stray function call `target_compile_definitions()` resulting in the
library property name and value to also be added compile definitions to
the Zephyr library.
The Zephyr library property is an internal property and is not supposed
to be added as compile definitions, and thus this call is removed with
this commit.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add support for Quectel modem in gsm_ppp modem driver.
The CMUX cmd is based on MUX application notes v1.0(2020-09-22)
for BG95, BG77 and BG600L. Tested and working on EC21e.
As the gsm_ppp doesn't do power control, it is required to power
on the modem manually in the application.
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
Apply the same changes as the previous commit made in the spi_nrfx_spim
shim, to keep these two shims aligned.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
According to the nRF5340 PS, for 32 Mbps high-speed SPI using SPIM4,
drive configuration H0H1 must be used. The underlying nrfx_spim driver
does it properly in its initialization function, so change the shim to
(re)initialize the driver when the SPI configuration is to be changed
(only then the speed to use is known), to avoid the need of duplicating
the corresponding code in the shim itself.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
According to the nRF5340 PS, SPIM4 only supports 32 Mbps when
the application core is running at 128 MHz. This patch adds
the corresponding check.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The board name used in the zephyr-app-commands directive was the old
name for the Thingy52 board.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The nRF battery sample claims that it works without the need of a vbatt
node (voltage divider). However, this was currently not possible because
the sample code did have no means to extract the necessary ADC details
(instance and channel) from Devicetree unless vbatt was present. Similar
to other ADC samples, the zephyr,user node is used to define io-channels
property in this case. The sample README has been updated with an
example of how measurement without a voltage divider can be achieved.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
GDB can be built with or without Python support. When built with Python
support this can cause a particular problem: The gdb executable relies
on shared libraries that are bound to a specific Python version. But
since most Linux distributions typically ship with a single version, it
is very difficult to choose which one to target when building GDB.
When GDB executes, if it fails to load the shared libraries it will exit
immediately with an error code of 127 and output resembling this:
/home/carles/bin/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb:
error while loading shared libraries: libpython3.8.so.1.0: cannot open
shared object file: No such file or directory
There are two known approaches to shipping multiple gdb executables:
- The Zephyr SDK ships a default gdb with Python enabled, and then a
separate gdb-no-py executable with Python disabled
- GNU Arm Embedded ships with a default gdb with Python disabled, and an
additional gdb-py with Python enabled
To mitigate the problem of not being able to debug, fall back to a
'gdb-no-py' if it exists whenever the standard gdb executable fails to
even run.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Refactor IPv4 multicast address to MAC multicast address conversion
into its own function, so it can be reused by drivers as it is already
possible for IPv6 multicast addresses.
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
This patch fixes the issue that can cause a deadlock in shell.
When two threads simultaneously poll the TXDONE signal, only one
of them will receive it, leaving second one stalled.
The problem was that shell's context contains k_poll_event objects that
were polled by multiple threads. Polling it overwrites the poller field
that was set by previous thread.
Instead, the k_poll_event object must be created on the stack by every
thread that wants to poll the TXDONE signal.
This makes sure that no thread will be left waiting for this signal
forever.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
ptp_clock_test was failing when trying to access the ptp clock from user
mode. This was due to an arbitrary initialization priority between the
virtual PTP clock devices created by the ptp clocking test and the
physical PTP clock on the frdm_k64f board. Since the ptp test
initializes the virtual clock with the same device name as the physical
clock, if the physical clock was initialized first this test would
incorrectly reference the physical device during testing, instead of the
virtual one.
This fix simply defines the virtual ptp clock with a custom name, so
that the test will always locate the correct ptp clock.
Fixes#38731
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
