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>
STM32 clock control subsystem allows to configure a different
frequency value for core clock (SYSCLK) and AHB clock (HCLK).
Though, it is HCLK which is used to feed Cortex Systick timer
which is used in zephyr as reference system clock.
If HCLK frequency is configured to a different value from SYSCLK
frequency, whole system is exposed to desynchro between zephyr clock
subsytem and STM32 HW configuration.
To prevent this, and until zephyr clock subsystem is changed to be
aware of this potential configuration, enforce AHB prescaler value
to 1 (which is current default value in use for all STM32 based
boards).
On STM32H7, enforce D1CPRE which fills the same role as ABH precaler.
On STM32MP1, the equivalent setting is done on A7 core, so it is
not exposed to the same issue as long as SYS_CLOCK_HW_CYCLES_PER_SEC
is set with the 'mlhclk_ck' clock frequency value. Update
matching boards documentation.
Fixes#17188
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
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>
Adapted from similar code in the x86_64 port.
Useful when debugging boot problems on actual x86
hardware if a JTAG isn't handy or feasible.
Turn this on for qemu_x86.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Write all the desired values in the debug control flag.
Initally we were oring it, but this variable does not have
the expected initial values as it also depends on fuse
programming settings, therefore we dont have console.
Signed-off-by: Francisco Munoz <francisco.munoz.ruiz@intel.com>
Allow the user to use software slave select instead of the
hardware pin, in order to free the related GPIO and avoid
unwanted SS triggering on the hardware pin. The default SS
is still the hardware pin.
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>
ARC nSIM simulates pretty much any modern ARC core,
moreover it emulates a lot of different core features so
it is possible to play with them even wo real hardware.
Thus we add yet another ARC core family to be used on simulated
nSIM board.
For now it's just a basic configuration with ARC UART for
smoke-testing of Zephyr on ARC HS CPUs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The ARC HS is a family of high performance CPUs from Synopsys
capable of running wide range of applications from heavy DPS
calculation to full-scale OS.
Still as with other ARC cores ARC HS might be tailored to
a particular application.
As opposed to EM cores ARC HS cores always have support of unaligned
data access and by default GCC generates such a data layout with
so we have to always enable unaligned data access in runtime otherwise
on attempt to access such data we'd see "Unaligned memory exception".
Note we had to explicitly mention CONFIG_CPU_ARCEM=y in
all current defconfigs as CPU_ARC{EM|HS} are now parts of a
choice so we cannot simply select ether option in board's Kconfig.
And while at it change "-mmpy-option" of ARC EM to "wlh1"
which is the same as previously used "6" but matches
Programmer's Reference Manual (PRM) and is more human-friendly.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This will give us a possibility to check unaligned read/write support
in simulation.
Note nSIM with S(ecure)EM (with secure option) doesn't support that
mode in HW.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Wayne Ren