arm: Use the counter in the early arm64 DELAY

[andrew]

Summary

The current code assumes we can loop for a fixed timer per-usec. As
this depends on the CPU frequency and micro-architecture of the CPU
it is invalid in the general case.

On arm64 we can assume the virtual timer is available, so use this to
calculate how long to wait for.

Sponsored by: Arm Ltd

[mmel]

sys/arm/arm/generic_timer.c

862

Comment should be also updated.

865

Are you sure that CNTFREQ is always set up correctly?

The DT binding allows you to supply frequency counts from the DT timer node (using the clock-frequency property) and is still used for new SoCs -> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/exynos/exynos8895.dtsi#L459

A corrupted bootloader (in ROM or secure flash) is rare, but not that uncommon.

[andrew]

sys/arm/arm/generic_timer.c

865

It will be less broken than it is currently. We don't know how long it takes to call a function 200 times in a loop as it depends on the cpu frequency and micro-architecture.

[mmel]

sys/arm/arm/generic_timer.c

865

I disagree, while the original code may have caused a shorter than desired delay, the new code may do, at worst cause, something like a livelock. The CNTFREQ reset value is undefined, so new code with broken fw can cause anything from almost zero to extremely long delays.
It's hard to say which is worse.

However, we can easily work around this by trimming CNTFREQ to the range of expected values. With high probability, we can expect CNTFREQ to be greater than 10 MHz and less than (or equal to) 1 GHz (which is also required by v8.6). So if CNTFREQ is not in the above range, we can use 1 GHz.

The implementation is trivial and gives the safest result, IMHO.