The code assumes that when the systick counter hits zero,
the timer interrupt will be taken before the loop can
read the LOAD/VAL registers, but this is not architecturally
guaranteed, and so the code can see a post-reload SysTick->VAL
and a pre-reload clock_accumulated_count, which causes it to
return an incorrectly small cycle count. By adding a ISB we
overcome this issue.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Move to more generic tracing hooks that can be implemented in different
ways and do not interfere with the kernel.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Define generic interface and hooks for tracing to replace
kernel_event_logger and existing tracing facilities with something more
common.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This patch provides support needed to get timing related
information from riscv32 based SOC.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch provides support needed to get timing related
information from nios2 based SOC.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch provides support needed to get timing related
information from xtensa based SOC.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The benchmark application timing_info needs certain hooks to be
present in the kernel to get the accurate measurements. This
patch adds these hook at all the required locations.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
irq_lock returns an unsigned int, though, several places was using
signed int. This commit fix this behaviour.
In order to avoid this error happens again, a coccinelle script was
added and can be used to check violations.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.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>
This commit removes redundant reads of RTC_COUNTER register
propagating optimizations made in the k_cycle_get_32() function.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
The previous implementation of _timer_cycle_get_32() (which is directly
mapped to k_cycle_get_32()) taken from 87 to 132 cycles. As result it
was too heavy for using it as source of time for logger.
This commit makes this function faster by removing redundant access
to the RTC register (each access consumed 28 CPU cycles) as well as
loop, which made this call non-deterministic.
After these changes the k_cycle_get_32() needs only 50-52 cycles
in to calculate 32-bit timestamp.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
A few function prototypes were missing in the native_posix
board and its drivers.
Let's add them.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Intel SDM Vol3 10.5.4.1 states that "A write to LVT Timer Register that
changes the timer mode disarms the local APIC timer".
This implies that LVT Timer register needs to be programmed before
Initial Count register, otherwise the LOAPIC timer could not be armed.
Signed-off-by: Zide Chen <zide.chen@intel.com>
On some architectures tick time cannot be expressed as integer
number of microseconds, introducing error in calculations using
sys_clock_us_per_tick variable.
This commit deprecates the sys_clock_us_per_tick variable and
replaces its usage by more precise calculations based on
sys_clock_hw_cycles_per_sec and sys_clock_ticks_per_sec.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
In case of tickless kernel, k_busy_wait() calls __enable_sys_clock()
which in turn calls _set_time() with maximum RTC counter programmable
value. This will set the expected_sys_ticks to maximum tick value even
though there is no explicit timeout is requested from the kernel or from
an application. In this scenario, if an app calls k_sleep() which in
turn calls _add_timeout() which will adjust timeout value as per the
elapsed program time which based on incorrectly set expected_sys_ticks.
To fix this issue, we should not set the expected_sys_ticks in case
of __enable_sys_clock() as it just requests to run the counter but
a timeout event request.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
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>
Uncovered by clang we have some functions being only used conditionally,
so gaurd them to make them only available when those conditions are met.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
To enable for easier testing, replace direct use of registers
from Nordic's nrfx MDK with accesses via its HAL inlined functions
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
The nrf_rtc_timer used own method to calculate number of timer cycles
per tick. As the result value was different than the one used by
the kernel, the reported time was incorrect.
This commit fixes the problem described above by using global
sys_clock_hw_cycles_per_tick instead of custom RTC_TICKS_PER_SYS_TICK.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Remove redundant declaration of youve_print. This probably
had been a review oversight and upstreamed.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
This commit exposes the RTC1 ISR handling function, so the
function can be directly used in tests which generate
customized vector tables manually and require a visible symbol
for the ISR function.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Remove RTOS-2676 from the comment, this is a jira issue number that was
used with zephyr in the past and not available anywhere for reference.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
On a stm32, When we use the k_busy_wait function to wait a
delay (500us) just after an idle tickless period the delay could be
lower than the requested one. Consecutive readings of the cycle counter
made with the function k_cycle_get_32 juste after tickeless period
provides erroneous values (value jump) after some time (100 us).
To fix this issue we needs:
- Add the update of clock_accumulated_count value in the
_timer_idle_exit function.
- Treat the case in the get_elapsed_count function when the reload value
of the timer is set to a remaining value to wait until end of tick (see
_timer_idle_exit) . In this case the time elapsed until the systick
timer restart was not yet added to clock_accumulated_count. To retrieve
a correct cycle count we must therefore consider the number of cycle
since current tick period start and not only the cycle number since the
timer restart.
Fixes#6164
Signed-off-by: Holman Greenhand <greenhandholman@gmail.com>
In SMP, the system timer is used for timeslicing on auxiliary CPUs,
but the base system timekeeping via _nano_sys_clock_tick_announce() is
still done on CPU0 only (because the framework isn't prepared for
asynchronous notification yet). Skip processing on CPU1+.
Also, due to a hardware interaction* that is difficult to work around,
timer initialization on the auxiliary CPUs is done at the very end of
the CPU bringup, just before the swap into the scheduler. A
smp_timer_init() API has been added for this purpose.
* On ESP-32, enabling the timer seems to result in a near-synchronous
interrupt being delivered despite my best attempts to keep it
masked, then blowing things up because the CPU record isn't set up
to handle it yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The earlier xtensa layer put the timer initialization and update
directly into the interrupt handler, which is... weird. Under asm2,
it's just a regular ISR and needs to do the work in the driver.
Really, this driver needs a bunch of cleanup. The xtensa CPU timer is
two registers and one ISR: a global cycle count register, and a
compare register that will fire the IRQ when they match. There is
*way* too much code here.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing hand-written interrupt code is manually calling the timer
ISR, which is sort of silly and about to be replaced. Correctly
declare the ISR with IRQ_CONNECT() so that a conventional interrupt
handling implementation can find it. With current code this is a
noop.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Bugfix in the tickless mode part:
During _time_idle_exit it was not announcing to the kernel the
already passed silent ticks, but it was left for the tick interrupt
itself.
This did not cause any trouble so far as there was only the timer
interrupt in this board.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Added possibility to reconfigure CONFIG_SYS_CLOCK_TICKS_PER_SEC
for the native_posix board (before it could only be 100)
+
Fixed tickless idle support
+
Minor fixes in irq wrapping
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Delete the native timer soft IP driver as we will be reusing
the Altera's HAL drivers for most of the soft IP's.
Add shim driver support for Altera timer system clock soft IP.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Besides the fact that we did not have that for the current supported
boards, that makes sense for this new, virtualized mode, that is meant
to be run on top of full-fledged x86 64 CPUs.
By having xAPIC mode access only, Jailhouse has to intercept those MMIO
reads and writes, in order to examine what they do and arbitrate if it's
safe or not (e.g. not all values are accepted to ICR register). This
means that we can't run away from having a VM-exit event for each and
every access to APIC memory region and this impacts the latency the
guest OS observes over bare metal a lot.
When in x2APIC mode, Jailhouse does not require VM-exits for MSR
accesses other that writes to the ICR register, so the latency the guest
observes is reduced to almost zero.
Here are some outputs of the the command line
$ sudo ./tools/jailhouse cell stats tiny-demo
on a Jailhouse's root cell console, for one of the Zephyr demos using
LOAPIC timers, left for a couple of seconds:
Statistics for tiny-demo cell (x2APIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 7 0
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, xAPIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_xapic 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_msr 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
See that under x2APIC mode on both Jailhouse/root-cell and guest, the
interruptions from the hypervisor are minimal. That is not the case when
Jailhouse is on xAPIC mode, though. Note also that, as a plus, x2APIC
accesses on the guest will map to xAPIC MMIO on the hypervisor just
fine.
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
nrf SOC uses nrf rtc timer (not sys tick), which is 32kHz,
whereas CPU runs at higher speed (nrf52 runs at 64MHz).
So 32Khz is too slow to measure critical kernel parameters.
This patch does :-
1. Add support for nrf SOC for timing_info benchmarking.
2. Uses SOC timer to measure kernel parameters.
Jira: ZEP-2314
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
The API/Variable names in timing_info looks very speicific to
platform (like systick etc), whereas these variabled are used
across platforms (nrf/arm/quark).
So this patch :-
1. changing API/Variable names to generic one.
2. Creating some of Macros whose implimentation is platform
depenent.
Jira: ZEP-2314
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
Add support for TICKLESS KERNEL in nrf_rtc_timer for Nordic family of
processors. This patch includes :-
1. Programming RTC based on "next timer" value from timeout queue while
A. exiting idle_exit.
B. on RTC interrupt.
2. Impliments some of functions which will be required by sys_clock and
scheduler.
ZEP-1819
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
In Tickeless kernel Platform timekeeping is having error because
"_sys_clock_tick_count" is not getting updated correctly.
Currently "OVERFLOW" Flag (bit 16 in timer control register)
is reset before it is taken into account into _sys_clock_tick_count.
This patch sets a flag as soon as Timer Overflow occues and clears
it when time is accounted into _sys_clock_tick_count.
Jira : ZEP-2217
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
By the time we get to POST_KERNEL, kernel services and kernel objects
should be available for use. This should include timers and the random
number generator, but we don't init the system clock until sometime
during the POST_KERNEL phase. Initialize it earlier.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Adithya Baglody