Attention is currently required from: Boris Mittelberg, Caveh Jalali, Jayvik Desai, Kapil Porwal, Paul Menzel, Subrata Banik.
Julius Werner has posted comments on this change by Jayvik Desai. ( https://review.coreboot.org/c/coreboot/+/85326?usp=email )
Change subject: ec/google/chromeec: Add debug timestamp for host EC commands ......................................................................
Patch Set 11:
(1 comment)
File src/ec/google/chromeec/ec_lpc.c:
https://review.coreboot.org/c/coreboot/+/85326/comment/e9730130_b71b8831?usp... : PS9, Line 286: printk
If we have better ways to append the host cmd number into the timestamp string, then we can avoid making several entries.
Timestamps aren't stored with a string, only with an ID. The only way to associate extra information with them is to make a separate ID for every possible state.
There are timestamps before and after certain coreboot APIs that may call into other EC host commands. Therefore, when EC started populating more timestamps, it would only be in between those two outer layer timestamps.
Yes, but not all coreboot timestamps have a start or an end. If you normally have e.g. "cbmem post", "write tables" and "finalize chips" following one after the other, but turning on this debugging Kconfig adds a ton of EC host command timestamps in between, things will get confusing.
I still think that the timestamp system is fundamentally not the right tool to add detailed debugging information that can be turned on or off with a Kconfig. The timestamp system is meant to extract a consistent high-level overview of the boot time situation from production systems for metrics analysis (e.g. what we do with feedback reports). For detailed debugging on individual units, the console log is a much better tool.