Haiku under qemu-system-riscv64, system timer issues

[kallisti5]

There's some kind of timer issue when booting Haiku riscv64 under qemu. The CPU usage is erratic, and in a few minutes Haiku reports the uptime as 2 hours+.

Test command:

qemu-system-riscv64 -m 2048 -M virt -kernel firmware/u-boot/riscv64/qemu/u-boot.bin -device ati-vga -drive file=haiku-mmc.image,format=raw,if=virtio -usb -device usb-ehci,id=echi -device usb-kbd -device usb-tablet

[X512]

Yes, timer resolution is currently hardcoded to 1MHz for now (HiFive Unmatched settings). Calculation from system timer to BeOS time (microseconds) is needed. Timer resolution is already received in kernel args.

[kallisti5]

ah. right.

src/system/kernel/arch/riscv64/arch_real_time_clock.cpp

[kallisti5]

Commenting out the existing code on qemu gives:

timerFrequency: 10000000
system_time_conversion_factor: 429496729

[X512]

Implementing timer calculation may be a bit tricky because resolution can be bigger or less then system_time() and bigtime_t resolution.

[X512]

x86 calculation code seems not handle small resolutions.

[kallisti5]

goldfish-rtc

[kallisti5]

do we potentially need a driver for the individual rtc?

qemu uses google,goldfish-rtc per fdt. not sure how useful that is though since this code is pretty early.

[kallisti5]

• ​https://reviews.freebsd.org/D25717
• ​https://github.com/freebsd/freebsd-src/blob/master/sys/dev/goldfish/goldfish_rtc.c
• ​https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-goldfish.c

[X512]

do we potentially need a driver for the individual rtc?

Yes, we need. I currently implemented only RTC with custom HTIF call that is supported only in my custom TinyEMU patches.

Note that system timer and RTC are independent things and it may have different hardware time sources that cause drifting between them.

[X512]

HiFive Unmatched seems used different RTC that is a part of power controller. I currently use network time and WiFi to get time at boot.