Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35026 )
Change subject: soc/intel/{cnl, icl}: Cache the TSEG region ......................................................................
Patch Set 7:
(2 comments)
https://review.coreboot.org/c/coreboot/+/35026/7//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/35026/7//COMMIT_MSG@10 PS7, Line 10: normal boot and s3 resume on CML-hatch.
929 - 910 would be 19ms. I expect some variance here though.
i will update commit msg saying 19ms exactly.
https://review.coreboot.org/c/coreboot/+/35026/7//COMMIT_MSG@19 PS7, Line 19: Total Time: 910ms
Aug 23 15:05 Total Time till picking kernel: 818,078
I cannot really determine from the comments if there was some major rebase of vboot or if the numbers even come from the same reference board. I'd like confirmation it was not a regression from some of the work done on common intel romstage, stack guards, or FSP heap/stack changes.
yes, there is a boot time regression with latest FSP code base hence it moved from 800ms range to 900ms range. we are working on fixing the same. Right now boot time is 100ms extra from previous builds.
Once merged, performance data (cbmem -t) of this (and the parent) commit should be available for download somewhere.
i'm not sure if you have access to this devices, if not then may be access to the bug might be good to know the cbmem -t data that i planned to post there to close the bug.
Those will become the reference when we evaluate if POSTCAR_STAGE=n makes any sense. If timestamp 1100 is now (mysteriously) fixed, POSTCAR_STAGE=n approaches are a regression for boot speed.
i need to rebase old POSTCAR_STAGE=n Cl's with latest code base to see how much is boot time and i agree it might regress by 5-7ms for sure