Commit graph

15 commits

Author SHA1 Message Date
Stefan Reinauer
ae07051590 cbmem: print timestamp names
BUG=chrome-os-partner:18637
BRANCH=none
TEST=see timestamp names in cbmem -t output

Change-Id: Ie32d3e7ca759bd15e7c160bdd829dec19943e6cb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65333
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
2013-08-19 12:23:28 -07:00
Gabe Black
8ec61e52a6 cbmem: Terminate the cbmem console at the cursor position.
If the cbmem console buffer isn't zero filled before it's used, there won't be
a terminator at the end. We need to put one at the cursor position manually.

BUG=chrome-os-partner:19420
TEST=Booted and ran cbmem -c on pit. No longer saw lots of garbage printed
after the actual console output.
BRANCH=None

Change-Id: I69870c2b24b67ce3cbcd402b62f3574acb4c2a8f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65300
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
2013-08-09 11:18:50 -07:00
Stefan Reinauer
dc673f9979 Fix timestamp output in cbmem utility on ARM
On ARM the timestamps are already in micro seconds, so
no need to convert them.

Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
BRANCH=none
TEST=cbmem -t prints more reasonable timestamps.

Change-Id: If7363b0703e144bde62d9dab4ba845e1ace5bd18
Reviewed-on: https://gerrit.chromium.org/gerrit/63991
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
2013-08-02 16:44:39 -07:00
Stefan Reinauer
cc78ac7000 cbmem: fix userspace utility to work with dynamic CBMEM
This also adds an option -x/--hexdump to dump the whole
CBMEM area for debugging.

BRANCH=none
BUG=chrome-os-partner:18637
TEST=cbmem -l works on snow

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>
2013-07-30 17:08:47 -07:00
Stefan Reinauer
292a54e240 cbmem: Implement ARM support
Signed-off-by: Stefan Reinauer <reinauer@google.com>

BUG=chrome-os-partner:18637
TEST=Run sudo cbmem -l on Snow w/ coreboot, observe that it finds
     CBMEM
BRANCH=none

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>
2013-06-20 13:54:35 -07:00
Stefan Reinauer
d13688a7b8 cbmem utility: compatibility with older coreboot versions
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.

BUG=chrome-os-partner:18638
TEST=Build image, boot image on Link with original firmware,
     See it not rebooting.
BRANCH=none

Signed-off-by: Stefan Reinauer <reinauer@google.com>

Change-Id: I9dff766a89663322b1854b425ca5fd32e9e502d7
Reviewed-on: https://gerrit.chromium.org/gerrit/48725
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2013-04-25 15:49:49 -07:00
David James
6ba8deb56d Cast addresses and offsets to long long to work on all platforms.
Right now, these offsets are not declared with the correct printf
specifiers. Fix that.

BUG=none
TEST=launch trybots on all platforms

Change-Id: Ic6ac0afe047ab7b61b5753cc5bab261d1a860ba6
Reviewed-on: https://gerrit.chromium.org/gerrit/48321
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
2013-04-16 17:33:21 -07:00
Stefan Reinauer
d37ab454d4 Implement GCC code coverage analysis
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>
2013-01-12 19:09:55 +01:00
Stefan Reinauer
c01990789f cbmem utility: Find actual CBMEM area
... 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>
2013-01-08 20:40:26 +01:00
Stefan Reinauer
d7144dcd57 cbmem utility: unify debug output
... 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>
2013-01-08 20:25:21 +01:00
Stefan Reinauer
19f8756f00 cbmem utility: Add option to dump cbmem console
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>
2013-01-08 01:24:11 +01:00
Stefan Reinauer
05cbce672e cbmem utility: Use mmap instead of fseek/fread
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)
2013-01-04 06:37:59 +01:00
Stefan Reinauer
1e0e55615f cbmem utility: support command line options
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)
2013-01-03 01:09:50 +01:00
Vadim Bendebury
7c6b6bb593 cbmem compilation needs to use the hardened toolchain
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>
2012-11-12 17:12:23 +01:00
Vadim Bendebury
6d18fd09c3 Utility to dump boot timing table
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>
2012-11-12 03:35:20 +01:00