riscv/m2gl025: timer tests broken

Describe the bug

It seems that 669730f from #16782 has introduced some regressions in timer-related tests for the m2gl025 board.

In order to reproduce locally with sanitycheck, the renode emulator must be installed on your system. Then just $ sanitycheck -p m2gl025_miv and behold the failures the below. Backing out to f288d1e will eliminate almost all of these (except kernel/timer/timer_api, I guess that's another bug report).

m2gl025_miv               samples/portability/cmsis_rtos_v2/timer_synchronization/sample.portability.cmsis_rtos_v2.timer_synchronization FAILED: timeout
        see: sanity-out/m2gl025_miv/samples/portability/cmsis_rtos_v2/timer_synchronization/sample.portability.cmsis_rtos_v2.timer_synchronization/handler.log

total complete:   31/ 126  24%  failed:    1

m2gl025_miv               tests/cmsis_rtos_v2/portability.cmsis_rtos_v2      FAILED: timeout
        see: sanity-out/m2gl025_miv/tests/cmsis_rtos_v2/portability.cmsis_rtos_v2/handler.log

total complete:   46/ 126  36%  failed:    2

m2gl025_miv               tests/kernel/context/kernel.common                 FAILED: failed
        see: sanity-out/m2gl025_miv/tests/kernel/context/kernel.common/handler.log

total complete:   50/ 126  39%  failed:    3

m2gl025_miv               tests/kernel/fatal/kernel.common.stack_sentinel    FAILED: timeout
        see: sanity-out/m2gl025_miv/tests/kernel/fatal/kernel.common.stack_sentinel/handler.log

total complete:   52/ 126  41%  failed:    4

m2gl025_miv               tests/kernel/fifo/fifo_timeout/kernel.fifo.timeout FAILED: timeout
        see: sanity-out/m2gl025_miv/tests/kernel/fifo/fifo_timeout/kernel.fifo.timeout/handler.log

total complete:   53/ 126  42%  failed:    5

m2gl025_miv               tests/kernel/fifo/fifo_timeout/kernel.fifo.timeout.poll FAILED: timeout
        see: sanity-out/m2gl025_miv/tests/kernel/fifo/fifo_timeout/kernel.fifo.timeout.poll/handler.log

total complete:   90/ 126  71%  failed:    6

m2gl025_miv               tests/kernel/sleep/kernel.common.timing            FAILED: timeout
        see: sanity-out/m2gl025_miv/tests/kernel/sleep/kernel.common.timing/handler.log

total complete:   95/ 126  75%  failed:    7

m2gl025_miv               tests/kernel/timer/timer_api/kernel.timer          FAILED: failed
        see: sanity-out/m2gl025_miv/tests/kernel/timer/timer_api/kernel.timer/handler.log

total complete:   97/ 126  76%  failed:    8

m2gl025_miv               tests/kernel/workq/work_queue/kernel.workqueue     FAILED: failed
        see: sanity-out/m2gl025_miv/tests/kernel/workq/work_queue/kernel.workqueue/handler.log

total complete:   99/ 126  78%  failed:    9

m2gl025_miv               tests/kernel/workq/work_queue/kernel.workqueue.poll FAILED: failed
        see: sanity-out/m2gl025_miv/tests/kernel/workq/work_queue/kernel.workqueue.poll/handler.log

total complete:  126/ 126  100%  failed:   10
116 of 126 tests passed with 0 warnings in 706 seconds

[andrewboie]

To reproduce, need to install 'renode'. I did this on my Ubuntu 18.04 system:

1. Add mono repository at https://www.mono-project.com/download/stable/#download-lin
2. Then install the .deb at https://renode.io/#downloads

Once renode is installed and in PATH, sanitycheck automatically starts using it.

[andrewboie]

@kgugala @andyross pinging you guys as owners of RISCV and kernel timing, respectively

[andyross]

Looks like the root cause is a SoC bug. From soc/riscv32/riscv-privilege/miv/Kconfig.defconfig.series:

config SYS_CLOCK_HW_CYCLES_PER_SEC
        int
        default 660000

Needless to say a 660 kHz processor is going to have a really rough time reliably delivering a default tick rate precision of 10 kHz.

There is an (AFAICT otherwise unused) "clock-frequency" DTS setting for this board of 66 MHz, which looks much more reasonable.

We could surely also fix this by setting the default tick rate back to 100 Hz for this SoC, but let's try fixing the base clock first. The same driver works just fine with qemu_riscv32 at an emulated 10 MHz.

[andyross]

Oh, and I should also mention: I think renode is a cycle simulator and doesn't use host realtime like qemu does. But if that's wrong not then 10 kHz will never work and we need to set this to 100, as is done on qemu targets. I still no basically nothing about renode.

I think renode is a cycle simulator and doesn't use host realtime like qemu does.

If that's the case, maybe we should use it instead of qemu and save ourselves future grief.

.... only half-joking here.

[andrewboie]

@nategraff-sifive who's the right person to work on this? This is blocking a lot of people's PRs since this is broken in master

[andyross]

Sorry, I didn't realize this was actually breaking CI. FWIW: if the earlier rate was working at 660 kHz, then it's probably enough to add something like this (completely untested) as a temporary fix:

--- a/boards/riscv32/m2gl025_miv/m2gl025_miv_defconfig
+++ b/boards/riscv32/m2gl025_miv/m2gl025_miv_defconfig
@@ -13,3 +13,6 @@ CONFIG_PLIC=y
 CONFIG_RISCV_MACHINE_TIMER=y
 CONFIG_GPIO=n
 CONFIG_XIP=y
+
+# Workaround for incorect SYS_CLOCK_HW_CYCLES_PER_SEC
+SYS_CLOCK_TICKS_PER_SEC=100

[nategraff-sifive]

@nategraff-sifive who's the right person to work on this? This is blocking a lot of people's PRs since this is broken in master

@andrewboie My first thought would be @mgielda and the folks at Antmicro.