Created unit tests for the encryption and decryption functions.
Tested with the peripheral and with central_hr samples.
Due to latency of CAUv3 when used as CCM inline accelerator
only one of the PDU can be encrypted/decrypted within an
bilateral exchange M->S + S->M in a connection event.
If the RXed PDU is encrypted, the TXed PDU must be empty
with More Data if there is data in the LLL queue.
The TXed PDU will be encrypted when an empty PDU is RXed.
Signed-off-by: Cristi Caciuloiu <cristian.caciuloiu@nxp.com>
Same deal as in commit eddd98f ("kconfig: Replace some single-symbol
'if's with 'depends on'"), for all symbols defined within defconfig
files. See that commit for an explanation.
Maybe 'if's were used originally to mirror the 'if's in the main Kconfig
files, and then it got copied around by people assuming 'if' must work
differently from 'depends on'. It doesn't match in every spot at least.
Better to keep it simple and just consistently use 'depends on' when
it's a single symbol/choice I think. Helps reinforce that 'if' isn't
magic too.
Verified by printing all Kconfig menu nodes (symbols, choices, menus,
etc.) before and after the change and diffing (should show no
difference).
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Converts the fxos8700 sensor driver to the new gpio api. Updates device
trees for all boards with this sensor to active low gpio interrupts by
default.
Tested on frdm_k64f and rv32m1_vega_ri5cy boards. The latter verifies
that the reset output works correctly.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Updates the rv32m1 gpio driver and all associated boards to use new
device tree compatible gpio configuration flags. Implements new port
get/set/clear/toggle and pin_interrupt_configure functions recently
added to the gpio api.
Assumes the gpio api layer handles translating logical flags to physical
flags.
Stops quietly reconfiguring pinmuxes to gpio mode. The pinmux must now
be configured explicitly in the board's pinmux.c or in the application.
Tested with:
- samples/basic/blinky
- samples/basic/button
- tests/drivers/gpio/gpio_api_1pin
On boards:
- rv32m1_vega_ri5cy
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Edited the index.rst file to say spi functionality is included. Also
edited the .yaml file in the boards directory to support spi for sanity
tests.
Signed-off-by: Jose Manuel Pacheco Luna <manuel.pacheco@nxp.com>
Added in enablement for the SPI-0 instance pins, as found in the
board schematic files. These connect to the arduino headers on the
front of the board.
Signed-off-by: Jose Manuel Pacheco Luna <manuel.pacheco@nxp.com>
Explicitly configures the rgb led pinmuxes as gpios. Currently the gpio
driver quietly changes the pinmux to gpio mode when configuring a gpio
pin, but this behavior is about to change.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Specific SW defined BLE LL parameters need to be set
if the user enables it on this platform. As such, conditionally
enable them directly into the defconfig.
INTMUX CH2 and CH3 are not available to be used if BT support
is enabled on Vega, because they are used internally by the
BLE SW LL
Signed-off-by: David Leach <david.leach@nxp.com>
Since the experimental BLE software link layer is enabled on
the VEGABoard, add some information about it, as well as the
limitations.
Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
Having a pin toggle when the code reaches a certain point
is really useful for debugging; the infrastructure is already
in place for Nordic boards, so just build upon and enable the
mechanism on the Vega board as well.
Signed-off-by: David Leach <david.leach@nxp.com>
The board area was renamed from riscv32 to riscv back in July to
accommodate riscv64 support. Fix the remaining references in
documentation.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Enable the MX25R32 SPI NOR Flash on the VEGAboard and provide board
config file for the spi_flash sample.
Signed-off-by: Karsten Koenig <karsten.koenig.030@gmail.com>
Same deal as in commit 7fdb525754 ("kconfig: Use 'default' instead of
'def_bool' in Kconfig.defconfig files"), but I hacked Kconfiglib to also
find cases where the type is given separately as e.g.
config FOO
int
default 3
Motivation (from a note in
https://docs.zephyrproject.org/latest/guides/kconfig/index.html):
For a symbol defined in multiple locations (e.g., in a
Kconfig.defconfig file in Zephyr), it is best to only give the
symbol type for the "base" definition of the symbol, and to use
'default' (instead of 'def_<type>' value) for the remaining
definitions. That way, if the base definition of the symbol is
removed, the symbol ends up without a type, which generates a
warning that points to the other definitions. That makes the extra
definitions easier to discover and remove.
It's also nice if 'def_bool' and the like turn into a semi-reliable flag
that the symbol is only defined in Kconfig.defconfig files. That might
be a sign that things could be cleaned up.
Will do a separate pass later to remove some symbols only defined in
Kconfig.defconfig files.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
We need to be able to specify GPIO flags in devicetree without that
preventing translation from the Arduino specifier to the host GPIO
specifier. Set up to ignore the low 6 bits of the flags field when
matching the child specifier, and to copy those bits to the parent
specifier.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
found some references to files (via :zephyr_file: and :zephyr-app:) that
were moved, so the links were broken
Fixes: #19660
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Update a number of boards that have arduino_gpio and arduino_i2c
support in their dts files to show that they support that in the
board.yaml file. This allows coverage on several shield tests that
utilize the tags 'arduino_gpio' and 'arduino_i2c'.
Exlucde stm32mp157c_dk2 from some of the samples right now since the
connector on the board doesn't support A2/A3. Also remove the duplicate
of exluding disco_l475_iot1.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
For OpenVega board, in the case of the Zero Riscy core,
the flash partition used for the code and data is the
M0 ARM core's 256KB flash region. This is closest to
the RISC core.
The m0_flash node defines where the interrupt vector
is located for the Zero Riscy core, and one needs to
restrict the application so its interrupt vector is
placed accordingly.
Fixes: 34b0516466 ("boards: riscv32: rv32m1_vega:
enable MCUboot for ri5cy core")
Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.
Redirects for the web documentation are also included.
Then zephyrbot complained about this:
"
New files added that are not covered in CODEOWNERS:
dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi
Please add one or more entries in the CODEOWNERS file to cover
those files
"
So I assigned them to those who created them. Feel free to readjust
as necessary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
George Stefan