This also adds an option -x/--hexdump to dump the whole
CBMEM area for debugging.
Change-Id: I244955394c6a2199acf7af78ae4b8b0a6f3bfe33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62287
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4312
Tested-by: build bot (Jenkins)
on ARM the CBMEM utility requires the procfs entry
/proc/device-tree/firmware/coreboot/coreboot-table
provided by the FDT (dynamically created by depthcharge
at the moment)
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit b8ad224 changed the memory address in lb_cbmem_ref coreboot
table entries from a pointer to a uint64_t. This change was introduced
to make the cbmem utility work on both 32bit and 64bit userland.
Unfortunately, this broke the cbmem utility running on older versions
of coreboot because they were still providing a 32bit only field for
the address while the cbmem utility would now take the following 4
bytes as upper 32bits of a pointer that can obviously not be
mmapped. This change checks if the size of the lb_cbmem_ref structure
provided by coreboot is smaller than expected, and if so, ignore the
upper 32bit of the address read.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If4c8e9b72b2a38c961c11d7071b728e61e5f1d18
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use PRIx64 to print a u64 instead of "llx". Fixes the following error:
cbmem.c: In function 'parse_cbtable':
cbmem.c:135:2: error: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 'u64' [-Werror=format=]
Change-Id: Ibc2bf8597cb86db5b2e71fba77ec837a08c5e3d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbmem currently fails to build due to `-Werror` and the following
warning.
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cbmem.c: In function ‘map_memory’:
cbmem.c:87:2: error: format ‘%zx’ expects argument of type ‘size_t’, but argument 2 has type ‘off_t’ [-Werror=format]
[…]
Casting the argument of type `off_t` to `intmax_t` and using the
length modifier `j`
$ man 3 printf
[…]
j A following integer conversion corresponds to an intmax_t or uintmax_t argument.
[…]
instead of `z` as suggested in [1] and confirmed by stefanct and
segher in #coreboot on <irc.freenode.net>, gets rid of this warning
and should work an 32-bit and 64-bit systems, as an `off_t` fits
into `intmax_t`.
[1] http://www.pixelbeat.org/programming/gcc/int_types/
Change-Id: I1360abbc47aa1662e1edfbe337cf7911695c532f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3083
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently on a 32-bit system cbmem fails to build due to `-Werror`
and the following warning.
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
[…]
cbmem.c: In function ‘parse_cbtable’:
cbmem.c:135:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘u64’ [-Werror=format]
cc1: all warnings being treated as errors
[…]
Using the length modifier `ll` instead of `l` gets rid of this
warning.
Change-Id: Ib2656e27594c7aaa687aa84bf07042933f840e46
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3084
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Current code outputs the whole cbmemc buffer even if only part of
it is really used. Fix it to output only the used part and notify
the user if the buffer was too small for the required data.
Change-Id: I68c1970cf84d49b2d7d6007dae0679d7a7a0cb99
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2991
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... without the need for a coreboot table entry for each of them.
Change-Id: I2917710fb9d00c4533d81331a362bf0c40a30353
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2117
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and indent it to make output more comprehensible.
Change-Id: If321f3233b31be14b2723175b781e5dd60dd72b6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2116
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds an option to the cbmem utility to dump the cbmem console.
To keep the utility backwards compatible, specifying -c disables
printing of time stamps. To print both console and time stamps, run
the utility with -ct
Change-Id: Idd2dbf32c3c44f857c2f41e6c817c5ab13155d6f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2114
Tested-by: build bot (Jenkins)
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The kernel on Ubuntu 12.04LTS does not allow to use
fseek/fread to read the coreboot table at the end of
memory but will instead abort cbmem with a "Bad Address"
error.
Whether that is a security feature (some variation of
CONFIG_STRICT_DEVMEM) or a kernel bug is not yet clear,
however using mmap works nicely.
Change-Id: I796b4cd2096fcdcc65c1361ba990cd467f13877e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2097
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The tool could print much more useful information than
just time stamps, for example the cbmem console on systems
that don't have a kernel patched to support /sys/firmware/log.
Hence, add command line option parsing to make adding such
features easier in the future.
Change-Id: Ib2b2584970f8a4e4187da803fcc5a95469f23a6a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2091
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: build bot (Jenkins)
The appropriate compiler (provided by the build system) is used to
ensure proper toolchain options are used.
cbmem.c is being modified to suppress pointer to integer typecast
warnings.
Change-Id: Ibab2faacbd7bdfcf617ce9ea4296ebe7d7b64562
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1791
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Coreboot and u-boot create a table of timestamps which allows to see
the boot process performance. The util/cbmem/cbmem.py script allows to
access the table after ChromeOS boots up and display its contents on
the console. The problem is that shipping images do not include Python
interpreter, so there is no way to access the table on a production
machine.
This change introduces a utility which is a Linux app displaying the
timestamp table. Conceivably the output of this utility might be
included in one of the ChromeOS :/system sections, so it was attempted
to write this procedure 'fail safe', namely reporting errors and not
continuing processing if something goes wrong.
Including of coreboot/src .h files will allow to keep the firmware
timestamp implementation and this utility in sync in the future.
Test:
. build the utility (run 'make' while in chroot in util/cbmem)
. copy `cbmem' and 'cbmem.py' to the target
. run both utilities (limiting cbmem.py output to 25 lines or so)
. observe that the generated tables are identical (modulo rounding
up of int division, resulting in 1 ns discrepancies in some
cases)
localhost var # ./cbmem
18 entries total:
1:62,080
2:64,569 (2,489)
3:82,520 (17,951)
4:82,695 (174)
8:84,384 (1,688)
9:131,731 (47,347)
10:131,821 (89)
30:131,849 (27)
40:132,618 (769)
50:134,594 (1,975)
60:134,729 (134)
70:363,440 (228,710)
75:363,453 (13)
80:368,165 (4,711)
90:370,018 (1,852)
99:488,217 (118,199)
1000:491,324 (3,107)
1100:760,475 (269,150)
localhost var # ./cbmem.py | head -25
time base 4249800, total entries 18
1:62,080
2:64,569 (2,489)
3:82,520 (17,951)
4:82,695 (174)
8:84,384 (1,688)
9:131,731 (47,347)
10:131,821 (89)
30:131,849 (27)
40:132,618 (769)
50:134,594 (1,975)
60:134,729 (134)
70:363,440 (228,710)
75:363,453 (13)
80:368,165 (4,711)
90:370,018 (1,852)
99:488,217 (118,199)
1000:491,324 (3,107)
1100:760,475 (269,150)
Change-Id: I013e594d4afe323106d88e7938dd40b17760621c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1759
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Stefan Reinauer