Add a kernel timer driver for the MEC1501 32KHz RTOS timer.
This timer is a count down 32-bit counter clocked at a fixed
32768 Hz. It features one-shot, auto-reload, and halt count down
while the Cortex-M is halted by JTAG/SWD. This driver is based
on the new Intel local APIC driver. The driver was tuned for
accuracy at small sleep values. Added a work-around for RTOS
timer restart issue. RTOS timer driver requires board ticks per
second to be 32768 if tickless operation is configured.
Signed-off-by: Scott Worley <scott.worley@microchip.com>
The native_posix timer driver was still using the
legacy timer API.
Replace it with a new version, which is aligned with
the new kernel<->system timer driver API,
and which has TICKLESS_CAPABLE support
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This is an oddball API. It's untested. In fact testing its proper
behavior requires very elaborate automation (you need a device outside
the Zephyr hardware to measure real world time, and a mechanism for
getting the device into and out of idle without using the timer
driver). And this makes for needless difficulty managing code
coverage metrics.
It was always just a hint anyway. Mark the old API deprecated and
replace it with a kconfig tunable. The effect of that is just to
change the timeout value passed to the timer driver, where we can
manage code coverage metrics more easily (only one driver cares to
actually support this feature anyway).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing local APIC timer driver (loapic_timer.c) has bitrotted
and doesn't support TICKLESS_KERNEL, which is the preferred mode of
operation. This patch introduces a completely new driver, called
the APIC timer driver - the name is changed to allow the drivers to
continue to coexist in the short term, and also because "APIC timer"
isn't ambiguous (the I/O APICs do not have timers).
This driver makes no attempt to work with the MVIC timer as the
previous version did, because MVIC support is deprecated.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The Quark D2000 is the only x86 with an MVIC, and since support for
it has been dropped, the interrupt controller is orphaned. Removed.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Add LiteX timer driver with bindings for this device.
Signed-off-by: Filip Kokosinski <fkokosinski@internships.antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
We shall not enable by default a system timer in ARM
platforms, namely the SysTick, the Nordic, or the SAM0
RTC timer, simply by assessing the hardware capabilities
(e.g. by conditioning on CPU_CORTEX_M_HAS_SYSTICK).
Instead, now, all ARM platforms needs to explicitly set
their system timer module. Note that this has already
been the case for ca 80% of the ARM platforms.
This clean-up allows us to decouple HW capabilities from
system configuration (for example, Nordic platforms may
enable option CPU_CORTEX_M_HAS_SYSTICK, and still use
the platform-specific RTC timer for system timing).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit renames the symbol CPU_HAS_SYSTICK to
CPU_CORTEX_M_HAS_SYSTICK, to look similar to all
other CPU_CORTEX_M_HAS_ options, and moves the
K-config symbol definition from arm/core/Kconfig to
arm/core/cortex_m/Kconfig.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Redefining the config will not let another (out-of-source) driver be
chosen instead of the default. The driver is practically forced by the
soc settings. This commit moves default settings from soc/arm/nordic_nrf
into the drivers themselves.
Signed-off-by: Thomas Stenersen <thomas.stenersen@nordicsemi.no>
nrf_rtc_timer was selecting counter RTC1 instance even though it
is not using counter API at all.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The system timer uses RTC1, but does not implement the counter API with
it. Instead of auto-enabling the counter API on the system timer make
the two conflict until/unless both APIs are supported by the peripheral.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
This board is unmaintained and unsupported. It is not known to work and
has lots of conditional code across the tree that makes code
unmaintainable.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add sam0_rtc_driver that implements system timer API on top of the RTC
and can be used as a replacement for the default systick timer.
Signed-off-by: Martin Benda <martin.benda@omsquare.com>
Add a level 2 interrupt controller for the RV32M1 SoC. This uses the
INTMUX peripheral.
As a first customer, convert the timer driver over to using this,
adding nodes for the LPTMR peripherals. This lets users select the
timer instance they want to use, and what intmux channel they want to
route its interrupt to, using DT overlays.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Signed-off-by: Mike Scott <mike@foundries.io>
The OpenISA RV32M1 SoC has four CPU cores. Two of these are RISC-V
32-bit cores, which are named "RI5CY" and "ZERO-RISCY". (The other two
cores are ARM Cortex-M0+ and -M4.) This patch adds basic SoC
enablement for the RISC-V cores:
- basic dtsi, to be extended as additional drivers are added
- SoC definition in soc/riscv32/openisa_rv32m1 for RI5CY / ZERO-RISCY
- system timer driver for RI5CY, based on LPTMR0 peripheral
The timer driver will be generalized a bit soon once proper
multi-level interrupt support is available.
Emphasis is on supporting the RI5CY core as the more capable of the
two; the ZERO-RISCY SoC definitions are a good starting point, but
additional work setting up a dtsi and initial drivers is needed to
support that core.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Signed-off-by: Michael Scott <mike@foundries.io>
Cleanup dependencies in Kconfig and convert some top-level options to
menuconfig. guard all dependent options with if instead of using
'depends on' for readibility.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit renames the CLOCK_CONTROL_NRF5 Kconfig symbol to
CLOCK_CONTROL_NRF. The change is required to aleviates confusion
when selecting the symbol in nRF9160 SOC definition.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This patch adds a x86_64 architecture and qemu_x86_64 board to Zephyr.
Only the basic architecture support needed to run 64 bit code is
added; no drivers are added, though a low-level console exists and is
wired to printk().
The support is built on top of a "X86 underkernel" layer, which can be
built in isolation as a unit test on a Linux host.
Limitations:
+ Right now the SDK lacks an x86_64 toolchain. The build will fall
back to a host toolchain if it finds no cross compiler defined,
which is tested to work on gcc 8.2.1 right now.
+ No x87/SSE/AVX usage is allowed. This is a stronger limitation than
other architectures where the instructions work from one thread even
if the context switch code doesn't support it. We are passing
-no-sse to prevent gcc from automatically generating SSE
instructions for non-floating-point purposes, which has the side
effect of changing the ABI. Future work to handle the FPU registers
will need to be combined with an "application" ABI distinct from the
kernel one (or just to require USERSPACE).
+ Paging is enabled (it has to be in long mode), but is a 1:1 mapping
of all memory. No MMU/USERSPACE support yet.
+ We are building with -mno-red-zone for stack size reasons, but this
is a valuable optimization. Enabling it requires automatic stack
switching, which requires a TSS, which means it has to happen after
MMU support.
+ The OS runs in 64 bit mode, but for compatibility reasons is
compiled to the 32 bit "X32" ABI. So while the full 64 bit
registers and instruction set are available, C pointers are 32 bits
long and Zephyr is constrained to run in the bottom 4G of memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The HPET default is to deliver events on the same INTIn as the legacy
PIT IRQ, and in fact our code requires that because it uses the
"legacy routing" option. So this isn't really a configurable and has
to be set correctly. Do it right in the kconfig default instead of
forcing boards to set it.
(No, I have no idea where "20" came from either.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rewritten Xtensa CCOUNT driver along the lines of all the other new
drivers. The new API permits much smaller code.
Notably: The Xtensa counter is a 32 bit up-counter with a comparator
register. It's in some sense the archetype of this kind of timer as
it's the simplest of the bunch (everything else has quirks: NRF is
very slow and 24 bit, HPET has a runtime frequency detection, RISC-V
is 64 bit...). I should have written this one first.
Note also that this includes a blacklist of the xtensa architecture on
the tests/driver/ipm test. I'm getting spurious failures there where
a k_sem_take() call with a non-zero timeout is being made out of the
console output code in interrupt context. This seems to have nothing
to do with the timer; I suspect it's because the old timer drivers
would (incorrectly!) call z_clock_announce() in non-interrupt context
in some contexts (e.g. "expiring really soon"). Apparently this test
(or something in the IPM or Xtensa console code) was somehow relying
on that on Xtensa. But IPM is a Quark thing and there's no particular
reason to run this test there.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rewritten driver along the lines of all the other new drivers,
implementing the new timer API. Structurally, the machine timer is an
up-counter with comparator, so it works broadly the same way HPET and
NRF do. The quirk here is that it's a 64 bit counter, which needs a
little more care.
Unlike the other timer reworks, this driver has grown by a few lines
as it used to be very simple. But in exchange, we get full tickless
support on the platform.
Fixes#10609 in the process (the 64 bit timer registers are unlatched
for sub-word transfers, so you have to use careful ordering).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Reworked using the older hardware interface code, but with an
implementation of the new API only. Much smaller & simpler.
As yet, tested (manually) only on a nrf52_pca10056 board.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rewritten along the lines of ARM SysTick. Implements only the new,
simplified API. MUCH smaller. Works with tickless pervasively. No
loss of functionality.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a TICKLESS_CAPABLE kconfig variable which is used by the kernel to
select tickless mode's default automatically on drivers that support
it (rather than having to set the default per-board). Select it from
the ARM SysTick and Intel HPET drivers.
Also remove the old qemu_cortex_m3 default settings which this
replaces.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Qemu doesn't like tickless. By default[1] it tries to be realtime as
vied by the host CPU -- presenting read values from hardware cycle
counters and interrupt timings at the appropriate real world clock
times according to whatever the simulated counter frequency is. But
when the host system is loaded, there is always the problem that the
qemu process might not see physical CPU time for large chunks of time
(i.e. a host OS scheduling quantum -- generally about the same size as
guest ticks!) leading to lost cycles.
When those timer interrupts are delivered by the emulated hardware at
fixed frequencies without software intervention, that's not so bad:
the work the guest has to do after the interrupt generally happens
synchronously (because the qemu process has just started running) and
nothing notices the dropout.
But with tickless, the interrupts need to be explicitly programmed by
guest software! That means the driver needs to be sure it's going to
get some real CPU time within some small fraction of a Zephyr tick of
the right time, otherwise the computations get wonky.
The end result is that qemu tends to work with tickless well on an
unloaded/idle run, but not in situations (like sanitycheck) where it
needs to content with other processes for host CPU.
So, add a flag that drivers can use to "fake" tickless behavior when
run under qemu (only), and enable it (only!) for the small handful of
tests that are having trouble.
[1] There is an -icount feature to implement proper cycle counting at
the expense of real-world-time correspondence. Maybe someday we might
get it to work for us.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Simplify the Kconfig dependency for the nrf timer driver.
CLOCK_CONTROL_NRF5 depends on the SOC_FAMILY_NRF already.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Consistently use
config FOO
bool/int/hex/string "Prompt text"
instead of
config FOO
bool/int/hex/string
prompt "Prompt text"
(...and a bunch of other variations that e.g. swapped the order of the
type and the 'prompt', or put other properties between them).
The shorthand is fully equivalent to using 'prompt'. It saves lines and
avoids tricking people into thinking there is some semantic difference.
Most of the grunt work was done by a modified version of
https://unix.stackexchange.com/questions/26284/how-can-i-use-sed-to-replace-a-multi-line-string/26290#26290, but some
of the rarer variations had to be converted manually.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Upcoming Nordic ICs that share many of the peripherals and architecture
with the currently supported nRF5x ones are no longer part of the nRF5
family. In order to accomodate that, rename the SoC family from nrf5 to
nrf, so that it can contain all of the members of the wider Nordic
family.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The LOAPIC driver was doing this in a way susceptible to a very
nasty race condition: the CCR register could reset and be readable
before the associated interrupt could be delivered.
This resulted in a small window of time where CCR was reset, but
accumulated_cycle_count not updated, causing some calls to
k_cycle_get_32() to appear to jump backwards in time.
Just use the x86 TSC for these cycle timestamps. A divisor may be
provided in cases where the CPU clock speed is some multiple of
the bus speed. Modern x86 CPUs do not change their TSC rate even
when adjusting cpu frequency, so this should be a reliable timing
source.
Issue: ZEP-1546
Change-Id: I441bd8e32af866587a91f306e89e3fa0ece512b5
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This is needed by next commit as some assembly files handling interrupts use
some options from this file.
This file is not included in next commit to separate code and build system
aptches.
Change-Id: Iff3a8019362599beb0c0058c3169480fa5183c1c
Signed-off-by: Mazen NEIFER <mazen@nestwave.com>
Enabling the riscv_machine_timer driver by default for riscv32
causes compilation issues on riscv32 boards (like zedboard_pulpino)
not supporting it.
Boards supporting the driver enable it via their respective
config file.
Change-Id: Ieb0d25fa339834fd386ae2725f40b6b7b72dc52b
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
This flag is no longer necessary and TICKLESS_IDLE will be
enabled by default if SYS_POWER_MANAGEMENT is enabled.
Jira: ZEP-1325
Change-Id: Ic6cd4b8dc0a17c6a413cabf6509b215a4558318d
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
riscv defines the machine-mode timer registers that are implemented
by the all riscv SOCs that follow the riscv privileged architecture
specification.
The timer registers implemented in riscv-qemu follow this specification.
To account for future riscv SOCs, reimplement the riscv_qemu_driver by
the riscv_machine_driver.
Change-Id: I645b03c91b4e07d0f2609908decc27ba9b8240d4
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The riscv-qemu timer driver does not implement
TICKLESS_IDLE
Change-Id: I3eeb5abb05b3f16b55ab9343c2045295b3010cfd
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
The pulpino_timer driver does not implement TICKLESS_IDLE
for the time being.
Change-Id: I0cce8c8a7e203d551a924863462e6c86af4c98ff
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
On the nRF5x platforms we need always need the NRF_RTC_TIMER and it
depends on the CLOCK_CONTROL_NRF5. So enable all of these always.
Fixes issues if one tries to build nRF5x platforms w/o CONFIG_BLUETOOTH.
Change-Id: I0f9af785e785f37ec289a935ddf70ee6dec08cd4
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
