Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

On Tue, 28 Apr 2026 at 07:42, Bird, Tim <[email protected]> wrote:
>

> In my experience, although the kernel's blind spot is relatively small on x86, it
> is quite a bit larger on other platforms: 183 milliseconds on a raspberry pi
> and 1700 milliseconds on a FPGA-based riscv board.

Human time is relative, it is 1700ms but what is going on during that time?

The same thing that happens in 0.183 seconds in a x86 powerful silicon?

The blind spot is the same. Just the clock of the CPU is different.

Considering that 200ms is the time in which an entire Linux embedded
system can boot by a Qemu/KVM

~> https://github.com/robang74/uchaosys#quick-start (contains boot example data)

I would suggest that it is better to cut the boot time by an early
CNRG initialisation (which also brings in security) rather than worry
about a short (in terms of operations, whatever is the human time)
blind spot.

Wonderful that U-boot can provide reliable early timings but U-boot
isn't granted. From this point of view considering early timings as a
bounded case for debug/hacking makes sense

~> https://github.com/robang74/uchaosys/blob/v070/cnfg/printk-early-boot-timestamps-hack-v6.patch

as well as cutting down the boot time by providing early CNRG
initialisation. Solving practical problems and creating easy to access
bounded areas of experimentation for what we cannot control. Code or
patch aren't perfect? Humans aren't perfect, but improvable,
hopefully.

Best regards, R-