4898e2c613
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> |
||
|---|---|---|
| .. | ||
| atomic.c | ||
| bitarray.c | ||
| bitfield.c | ||
| boot_delay.c | ||
| byteorder.c | ||
| clock.c | ||
| errno.c | ||
| irq_offload.c | ||
| main.c | ||
| multilib.c | ||
| printk.c | ||
| timeout_order.c | ||