ARC: Boot_time test not functioning

[zephyrbot]

Reported by Chuck Jordan:

The following tests malfunction for ARC cpu targets:

tests/benchmarks/boot_time
legacy/benchmark/boot_time/<microkernel,nanokernel>

When CONFIG_BOOT_TIME_MEASUREMENT is defined,
some very early initialization is supposed to assign the value
__start_tsc.
This can't be done with ARC because _tsc_read is implemented to rely
on tick interrupts, and that hasn't come alive during this early time.

What could be done, is the ARC timer0 could be activated very early, w/o it causing an interrupt, just so that COUNT register increments.
__start_tsc could be initialized to zero early (but after bss zeroed if this is in bss).
Or perhaps just let the bss zeroing zero it.

Then later, when the timer0 is to be activated for interrupts, to the necessary math to keep the COUNT up to that point as part of the TIME being maintained by the sys_clock.c implementation.
In this way, 64-bit time, as returned by _tsc_read(), can be functional from very early init.

(Imported from Jira ZEP-1747)

[zephyrbot]

by Mark Linkmeyer:

Ruud Derwig , can you please assess this bug and set an appropriate priority? Thx.

[zephyrbot]

by Chuck Jordan:

priority is low

[galak]

@ruuddw @vonhust can you see if this is still an issue.

[ruuddw]

Yes, this is still an issue. Though slightly different than the initial issue. k_cycle_get_32() is used for reading timestamps, and on ARC (also ARM, maybe other arches as well) this counter is (re)set to 0 when the sys clock driver is initialized -> boot time numbers reported are slightly optimistic.

[vonhust]

I will make an investigation and try to fix it

[galak]

@vonhust any updates on this?

[vonhust]

@ruuddw ? Yes, some time is lost between the reset and the inti of systick , do we need very accurate number on this ? IF not, i suggest to close this issue.

[vonhust]

@galak #14664 will fix this