To avoid a Coverity warning (203449):
https://github.com/zephyrproject-rtos/zephyr/issues/18354
Initialize a pointer to NULL, and check it later before
de-referencing it.
Coverity could not see that posix_print_error_and_exit()
never returns even that it ends with exit()
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This commit adds the reel_board canbus shield.
On the shield, there is an MCP2515 and a CAN transceiver.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
This commit enables the pullup on CAN0_RX pin (PORTB 19).
The pullup ensures that the CAN controller initializes even
without a transceiver connected.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
now we use hex file instead of elf file for flash command as
PR #17822 suggested, so enable BUILD_OUTPUT_HEX by default for
board sam_e70_xplained.
Fixes: #18181.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Selection of the HFRCO causes the SOC to stay at its power-up frequency
of 19 MHz. Switch to the HFXO to use the configured frequency.
Closes#17630
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Related to #17997, move an include out of a extern "C" block
Background:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
* CONFIG_SMP can be enabled by smp application, e.g. tests/kernel/smp
* if application is not designed for smp, CONFIG_SMP can be disabled,
and the target works as a single processor.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Now when SMP support for ARC is available we may introduce a simulation
platform which might be used for testing & development for SMP setups.
One important note is stand-alone nSIM (as well as its "Free" flavour)
doesn't support SMP simulation so we have to switch to use of nSIM via
proprietary MetaWare debugger [1] and so:
1. We introduce new emulation target "mdb"
2. It's only possible to run that platform for those who
have MetaWare tools installed and valid license.
Though QEMU port for ARC is in work at the moment and once we
open that port and it has SMP support we'll switch to it and everybody
will be able to try ARC HS with SMP.
[1] https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This commit includes the initial support of ARC HS Development Kit:
* hsdk soc support
* hsdk board support
* no mmu support, so no userspace
* smp support
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
This adds support for SARA-U2 modems. They have different timings on
the PWR_ON pin, don't support AT+CESQ and require a manual GPRS
connection setup.
The VINT pin is used as a more reliable and faster way to power on the
modem.
Based on work by Göran Weinholt <goran.weinholt@endian.se>
Signed-off-by: Michael Scott <mike@foundries.io>
In nRF9160 the reset pin is a dedicated one, it cannot be configured
as a regular GPIO pin, so this option should not be presented to users
building for this SoC, to not generate confusion.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This driver makes use of the nRF RNG peripheral, so it can be used only
for SoCs that are equipped with one, and not all nRF SoCs are.
The option enabling the driver should then depend on `HAS_HW_NRF_RNG`,
which indicates the presence of this peripheral in a given SoC.
This patch removes also entries disabling this driver in default
configurations for nRF9160 SoC, as these were needed only because
of the invalid dependency of the ENTROPY_NRF5_RNG option.
A minor adjustment of Kconfig files of the nrf52_bsim board was
required as well, so that this board's configuration can properly
handle this corrected dependency.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
In order to increase code coverage, we force building a Secure
Firmware image by default (i.e. with option
CONFIG_TRUSTED_EXECUTION_SECURE set), when building for
mps2_an521 board. CONFIG_TRUSTED_EXECUTION_SECURE enables
compiling-in all TrustZone-related code in the tree, that is,
all ARM-specific code inside #ifdef CONFIG_ARM_SECURE_FIRMWARE.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This emulates a RISC-V in 64-bit mode on a SiFive FE310 dev board.
Memory is tight so a few tests had to be disabled due to the extra
memory usage compared to qemu_riscv32.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Add support for driving the on-board LEDs present on the NXP TWR-KE18F
development board using FlexTimer (FTM) PWM modulation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The number of MPU regions appears to be 16 instead of 8,
so we fix that in the board .dts files.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
So far zephyr.elf file was hardcoded in cmake files. Remove it from
there and use cfg.elf_file from python, which can be overwritten by
specifying --elf-file command line option.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Same deal as in commit a84ded74ea ("dts: Replace status = "ok" with
status = "okay""), for newly introduced stuff.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Route these to the equivalent pins for RXD1 and TXD1 on the Arduino
Mega.
Note that uart0 is routed to the debug probe IC on the nRF9160
DK, and uart1 is routed to where the RXD0 and TXD0 Arduino pins are on
the DK. This makes RXD1/TXD1 a logical place to put these UART pins,
since the header layout for the DK board matches the Arduino mega.
This is also necessary to keep some downstream code compiling which
needs to enable the UART2 but doesn't have a good place to put these
pins, since the new DTS parser is enforcing that all required
properties (like tx-pin and rx-pin in this case) are set for nodes
with status = "okay".
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
- update doc for different core configuration.
- fix some bugs in dts related files.
- add dts config and defconfig for different core configuration.
- end files with a newline in boards/arc/emsdp/board.dtsi
- remove unused head in boards/arc/emsdp/doc/index.rst
- ARC_MPU_VER in different core is fixed. so remove some useless code
for ARC_MPU_VER judgements in Kconfig.defconfig.* files for emsdp
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
Enable Mailbox support on 96Boards Avenger96 board. This will help
communicating to CortexA7 core.
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Add onboard LEDs on 96Boards Avenger96 board. There are 4 user LEDs
on this board but only 3 are enabled. This is due to the fact that
LED0 is connected to unavailable PortZ. Hence, LED0 is ignored and
remaining LEDs are enabled starting from index 0.
Once PortZ is added, this will be fixed.
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
After witnessing some strange errors with memory not being
what it should be, lifiting everything above 1MB has solved
it. The Zephyr binary was being loaded into memory containing
reserved regions, resulting in data corruption.
We still simulate XIP for testing purposes by setting up the
memory map as follows:
0x000000 - 0x0FFFFF : Non-present
0x100000 - 0x4FFFFF : "Flash" ROM region
0x500000 - 0x8FFFFF : "SRAM" RAM region
For a total of 9 megabytes of physical RAM used.
Fixes problems observed in some large tests when code coverage
is enabled (which increases the amount of RAM used even more).
Fixes: #17782
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Removes very complex boot-time generation of page tables
with a much simpler runtime generation of them at bootup.
For those x86 boards that enable the MMU in the defconfig,
set the number of page pool pages appropriately.
The MMU_RUNTIME_* flags have been removed. They were an
artifact of the old page table generation and did not
correspond to any hardware state.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
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>
It is expressed that the BOARD depends on whether NONSECURE is enabled
or not. But it is the other way around. Depending on the selected
board, it may or may not be possible to enable/disable NONSECURE.
The dependency is going in the wrong direction, this reversed edge is
observed to be able to create a cycle in the dependency graph.
Fix the dependency by removing it.
It is left as future work to enforce that enabling/disabling NONSECURE
is done in a way that is compatible with selecting
BOARD_NRF9160_PCA10090 vs BOARD_NRF9160_PCA10090NS.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The "{d,i}ccm" nodes should not have had a 'device_type' property.
Remove it from the cases that we clearly know are {d,i}ccm.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The true mmio-sram nodes should not have had a 'device_type' property.
Remove it from the cases that we clearly know are SRAM.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add SPI support for stm32mp157c_dk2 board. If SPI is selected, SPI4
(Arduino connector compatible SPI) and SPI5 (on front 2x20 GPIO
expander) will be enable by default on stm32mp157c_dk2 board.
Signed-off-by: Yaël Boutreux <yael.boutreux@st.com>
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
(This could not be triggered in the nrf52_bsim yet,
so just so it is fixed for the future)
Properly handle converting back and forth from absolute to HW
time when either of those is set to TIME_NEVER
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
System clock for m4 core was set to same clock as m7 core.
This is wrong as m4 its value is actually based on clock frequency
value after D1CPRE (sys_d1cpre_ck) divided per HPRE value, 200MHz in
current case.
This also matches the max clock speed for the m4 core (200MHz)
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
cores
In order to prevent potential misconfiguration set the clock setting,
which impacts both cores, under board.defconfig file which is used
by both core.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>