First, this test is a little suspect. It's assuming that the value
returned from k_cycle_get_32() represents the time since system
power-on. While that's an obvious implementation choice and surely
often true, it's definitely not the way we document this API to the
arch layer. It's perfectly legal for a platform to return any value
as long as the counter is increasing at the correct rate. Leaving for
now as there's no other way to test CONFIG_BOOT_DELAY, but this will
likely be coming back to confuse us at some point.
Regardless, that convention holds for x86 devices using any of the
existing drivers. But on an EFI PC using the TSC counter as the clock
source: (1) the counter is running at 1-2 GHz and (2) the time to get
through an EFI BIOS and into Zephyr is routinely 10+ seconds,
especially on reference hardware. The poor 32 bit API will roll over
several times, and effectively be a random number by the time it
reaches this test.
Just skip this test with fast counter.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
4898e2c613