summaryrefslogtreecommitdiff
path: root/common/flash_log.c
Commit message (Collapse)AuthorAgeFilesLines
* flash_log: prevent console output garblingVadim Bendebury2019-08-301-3/+2
| | | | | | | | | | | | | | | | Dumping the flash log including many short entries results in garbled console output. Let's move cflush() invocation to the main loop, it is not a problem for a console command be throttled like this. BRANCH=cr50 BUG=none TEST=verified that flash logs of many short and long messages are printed out accurately. Change-Id: Id4b988d4eab29aaf118d6495f9a3d61e5d9f9a56 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1776335 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* flash_log: add api for setting base timestampVadim Bendebury2019-05-231-6/+47
| | | | | | | | | | | | | | | | | | | | | | | | The Cr50 environment does not have a wall clock, which makes it impossible to associate flash log entries with real time. This patch provides an API which allows to set a base time value and then use it plus current Cr50 uptime to generate more sensible flash log timestamps. Care is taken to ensure that attempts to set timestamp base such that it would cause a log timestamps rollback do not succeed. A unit test is being added to verify this behavior. BRANCH=none BUG=b:132287488 TEST='make buildall -j' (which runs the new tests) succeeds. Change-Id: I7521df1bac5aef67e0cf634c183bf1618655f48d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1610719 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* common: add flash event log facilityVadim Bendebury2019-03-261-0/+549
This patch adds implementation and test for a generic logger saving log entries in the flash. The entries payload are limited to 64 bytes in size, each entry starts with a header, which includes - 8 bit type type to allow to interpret the payload - 6 bit size field (two top bits of the byte are left for user flags, not yet used) - 32 bit timestamp to allow to identify newer log entries (presently this is just a monotonically increasing number) - 8 bit crc field protecting the entire entry The entries are padded to make sure that they are ending on the flash write boundary. The location of the log is defined by the platform using it. There is a provision for allowing the platform to register a callback which is needed to be called to allow write access to the log (as is the case on H1). While the device is running, the log is growing until the allotted flash space is 90% full. If there is an attempt save another entry after that the log is compacted, namely the last 25% worth of flash space is preserved, the log space is erased and the saved contents written back. On restarts the log is compacted if its size exceeds 75% of the allotted flash space. An API is provided to add entries to the log and to retrieve an entry newer than a certain timestamp value. Thus starting with timestamp zero will result in reading the very first log entry. To read the next entry, the read function needs to be called with the timestamp value of the current entry. This allows to browse the entire log, one entry at a time. A CLI command compiled in when CONFIG_CMD_FLASH_LOG is defined, allows to add log and retrieve log entries. BUG=b:63760920 BRANCH=cr50, cr50-mp TEST=the included test case can be invoked by make run-flash_log and it passes. More tests are done when the rest of the patch stack is added. Change-Id: I3dcdf2704a1e08fd3101183e434ac4a4e4cf1b9a Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1525143 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>