summaryrefslogtreecommitdiff
path: root/util/cbfstool/elogtool.c
AgeCommit message (Collapse)Author
2023-03-02util/cbfstool/eventlog: Use LocalTime or UTC timestampsWojciech Macek
Add a new flag "--utc" to allow the user to choose if elogtool should print timestamps in Local Time or in UTC. It is useful for generating automated crash reports including all system logs when users are located in various regions (timezones). Add information about timezone to timestamps printed on the console. Signed-off-by: Wojciech Macek <wmacek@google.com> Change-Id: I30ba0e17c67ab4078e3a7137ece69009a63d68fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/73201 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
2023-01-27elogtool: Fix potential buffer overrunKapil Porwal
BUG=b:239110778 TEST=Make sure that the output of elogtool is unaffected by this change. Signed-off-by: Kapil Porwal <kapilporwal@google.com> Change-Id: Ia1a6341abd834dd9ad5f12c9f2eefb0489364a08 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72099 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-06-16util/cbfstool: Decouple elogtool from vboot_ref flashrom codeEdward O'Callaghan
Currently elogtool sub-proccesses flashrom as calling libflashrom requires a missing function from the previous flashrom release. Pending a new release of flashrom we must continue to use subprocess. However the current subprocess wrapper implementation lives in vboot_reference which is a git sub-module of coreboot. This causes all sorts of grief keeping a subprocess ABI stable from vboot_reference when the rest of vboot_reference builds of HEAD of the flashrom tree (i.e., using unreleased libflashrom functions). In order to not keep finding ourseleves in a bind between the two separately moving trees with different build environments, decouple elogtool with its own mini copy of flashrom subprocess wrapping logic. Squash in, util/cbfstool/elogtool.c: Convert args into struct in flashrom helper vboot signatures for flashrom r/w helpers changed in the upstream commit bd2971326ee94fc5. Reflect the change here to allow vboot ref and coreboot to realign. BUG=b:207808292,b:231152447 TEST=builds with vboot_ref uprev. Change-Id: I04925e4d9a44b52e4a6fb6f9cec332cab2c7c725 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65055 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-02-26Revert "util/cbfstool: Port elogtool to libflashrom"Martin Roth
This reverts commit d74b8d9c990780ba64515b36aaff79d719d71ead. This change breaks the 'make all' build of the cbfstool tools from the util/cbfstool directory unless libflashrom-dev is installed, complaining that flashrom is not installed. Even with libflashrom-dev installed, it breaks building elogtool with the public version of libflashrom-dev. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I572daa0c0f3998e20a8ed76df21228fdbb384baf Reviewed-on: https://review.coreboot.org/c/coreboot/+/62404 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: ron minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-01-14util/cbfstool: Port elogtool to libflashromEdward O'Callaghan
This also uncouples cbfstool from being overly Chromium specific. However the main objective is to not subprocess flashrom any more and instead use the programmatic API. BUG=b:207808292 TEST=built and ran `elogtool (list|clear|add 0x16 C0FFEE)`. Change-Id: I79df2934b9b0492a554a4fecdd533a0abe1df231 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59714 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sam McNally <sammc@google.com>
2021-09-21elogtool: compile in 32-bit platformsRicardo Quesada
This CL fixes a compilation error that happens in 32-bit platforms. This error happens because printf() was using %ld instead of %zu to print size_t variables. This CL fixes it. BUG=b:200608182 TEST=emerge-kevin (ARM 32-bit) TEST=emerge-eve (Intel 64-bit) Change-Id: I340e108361c052601f2b126db45caf2e35ee7ace Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57792 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
2021-09-16elogtool: add "add" commandRicardo Quesada
Adds "add" command to elogtool. This command allows adding elog events manually. It supports event type and, optionally, event data. If the free buffer space is < 1/4 of the total space, it shrinks the buffer, making sure that ~1/4 of the free space is available. BUG=b:172210863 TEST=./elogtool add 0x17 0101 ./elogtool add 0x18 Repeated the same tests on buffers that needed to be shrunk. Change-Id: Ia6fdf4f951565f842d1bff52173811b52f617f66 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57397 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-09-16elogtool: add next_available_event_offset functionRicardo Quesada
This function is "extracted" from cmd_clear(). This new function will be called from cmd_add(), and new command that will be added in a future CL (see CL chain). Additional minor fixes: - calls usage() if no valid commands are passed. - Slightly improves usage() output. Needed for cmd_clear() BUG=b:172210863 TEST=elogtool clear Change-Id: I0d8ecc893675758d7f90845282a588d367b55567 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57395 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-09-10elogtool: add "clear" commandRicardo Quesada
Adds "clear" command to cbfsutil/elogtool tool. "clear" clears the RW_ELOG region by using either: * flashrom if no file is provided * or using file write if an input file is provided. The region is filled with ELOG_TYPE_EOL. And a ELOG_TYPE_LOG_CLEAR event is inserted. Additionally, it does a minor cleanup to command "list", like: * use buffer_end() * add "list" to the cmds struct * and make elog_read() very similar to elog_write() Usage: $ elogtool clear BUG=b:172210863 TEST=elogtool clear && elogtool list elogtool clear -f invalid.raw elogtool clear -f valid.raw Change-Id: Ia28a6eb34c82103ab078a0841b022e2e5e430585 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56883 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
2021-08-05util/elogtool: add tool to print elog eventsRicardo Quesada
Add a new tool that that prints elog events. The tool, as input, accepts either a file with the RW_ELOG contents, or if the file is not provided it reads the contents of RW_ELOG by calling the "flashrom" tool. The tool is based on "mosys eventlog list"[1]. For the moment it only supports "list", but future commits will add additional functionality. This commit also adds missing ELOG defines needed for the tool. These defines are added with the rest of the ELOG defines, in include/commonlib/bsd/elog.h The tool is placed inside util/cbfstool. The rationale behind the decision, is that this tool shares a lot in common with the other tools located in cbfstool: vboot dependency, shared files like common.o and valstr.o, and in spirit is similar to some of the tools located in cbfstool/. As an example, you call the tool like the following: $ elogtool list -f rw_elog_dump.bin [1]: https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/lib/eventlog/elog.c BUG=b:172210863 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Change-Id: Ia1fe1c9ed3c4c6bda846055d4b10943b54463935 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56406 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>