Commit Graph

24 Commits

Author SHA1 Message Date
Vadim Bendebury 8b143c5c8b cbmem: use a single id to name mapping table
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.

BUG=none
TEST=manual
  . the new firmware still displays proper CBMEM table entry descriptions:

    coreboot table: 276 bytes.
    CBMEM ROOT  0. 5ffff000 00001000
    COREBOOT    1. 5fffd000 00002000

  . running make in util/cbmem still succeeds

Original-Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199791
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5217446a536bb1ba874e162c6e2e16643caa592a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: I0d839316e9697bd3afa0b60490a840d39902dfb3
Reviewed-on: http://review.coreboot.org/7938
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-12-30 19:17:47 +01:00
Paul Menzel 29635415a6 util/cbmem: Print name instead of ID of CBMEM_ID_SMM_SAVE_SPACE
Commit b4b9eb39 (x86: provide infrastructure to backup default SMM
region) introduced the new CBMEM type `CBMEM_ID_SMM_SAVE_SPACE`, but
did not add its name `SMM BACKUP` to the utility `cbmem`, causing the
following output, when running `cbmem` on a system making
use of `BACKUP_DEFAULT_SMM_REGION`.

	 7. 07e9acee   7f7e5000   00010000

Fix that by adding the name `SMM BACKUP` to the struct
`cbmem_id_to_name`.

Change-Id: Ib24088c07af4daf6b7d8d5854283b5faa2ad6503
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/7176
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-12-03 12:33:43 +01:00
Paul Menzel 747c07f08a util/cbmem: Fix CBMEM TOC printing
Since commit c0199078 (cbmem utility: Find actual CBMEM area) [1], at least on
the Lenovo X201, X230 and X60, printing the CBMEM table of contents did
not work.  It still worked on the ASRock E350M1 though.

	$ sudo /src/coreboot/util/cbmem/cbmem -l --verbose # Lenovo X60t
	Looking for coreboot table at 0
	Mapping 1MB of physical memory at 0x0.
	Found!
	  coreboot table entry 0x11
	    Found forwarding entry.
	Unmapping 1MB of virtual memory at 0xb74dc000.
	Looking for coreboot table at 7f6c4000
	Mapping 1MB of physical memory at 0x7f6c4000.
	Found!
	  coreboot table entry 0xc8
	  coreboot table entry 0x01
	    Found memory map.
	  coreboot table entry 0x03
	  coreboot table entry 0x04
	  coreboot table entry 0x05
	  coreboot table entry 0x06
	  coreboot table entry 0x07
	  coreboot table entry 0x08
	  coreboot table entry 0x09
	  coreboot table entry 0x0a
	  coreboot table entry 0x16
	    Found timestamp table.
	      cbmem_addr = 7f7dd000
	  coreboot table entry 0x17
	    Found cbmem console.
	      cbmem_addr = 7f7de000
	Unmapping 1MB of virtual memory at 0xb74dc000.
	No coreboot CBMEM area found!

The address of the boot info record has to be used for checking, that reading
takes place in the bounds of the boot info record.

	$ sudo ~/src/coreboot/util/cbmem/cbmem -l # Lenovo X60
	CBMEM table of contents:
	    ID           START      LENGTH
	[…]

Big thanks to David and Stefan for their help.

[1] http://review.coreboot.org/2117

Change-Id: I1eb09a6445d9ea17e1e16b6866dece74315d3c73
Found-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/7093
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-10-18 14:29:29 +02:00
Paul Menzel e4626bfc5b util/cbmem/cbmem: Remove obsolete comment
Originally the utility cbmem was just used for reading out the time
stamps and was later extented. The removed comment is currently at the
wrong place and `cbmem` does much more now, so that the comment is just
removed.

Change-Id: Ief1d7aef38a4b439e3e224e6e6c65f7aa57f821f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/7091
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
2014-10-18 10:29:33 +02:00
Gabe Black 06b13a37f0 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.

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>
(cherry picked from commit 8ec61e52a6a27ed518d0abb5a19d6261edf9dab1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6404
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-30 11:49:45 +02:00
Kyösti Mälkki b3594ab489 util/cbmem: Workaround for IS_ENABLED()
Our include files reference CONFIG_xxx declarations, which we should
ignore for utility build.

We cannot include kconfig.h to get IS_ENABLED() as that file
would require build/config.h and we do not want to enforce a build
of the firmware to be able to build the utility.

Since we do not include build/config.h each occurence of CONFIG_xxx
in the included header files is undefined and will be treated as
disabled.

Change-Id: I74f1627fc3f294410db8ce486ab553dac9e967f4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6066
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-06-20 19:49:11 +02:00
Aaron Durbin ab180d85f7 util/cbmem: handle larger than 1MiB mappings for console
In some cases the cbmem console can be larger than the default
mapping size of 1MiB. Therefore, add the ability to do a mapping
that is larger than the default mapping using map_memory_size().
The console printing code will unconditionally map the console based
on the size it finds in the cbmem entry.

Change-Id: I016420576b9523ce81195160ae86ad16952b761c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5440
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-04-02 17:01:01 +02:00
Stefan Reinauer 0db924d74c cbmem: print timestamp names
The numbers alone are hard to parse, so add
some timestamp names to make it easier to read.

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>
Reviewed-on: http://review.coreboot.org/4314
Tested-by: build bot (Jenkins)
2013-12-05 19:23:49 +01:00
Stefan Reinauer d8ef9e9e9b 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>

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>
Reviewed-on: http://review.coreboot.org/4313
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-12-05 19:23:40 +01:00
Stefan Reinauer a9c8361c02 cbmem: fix userspace utility to work with dynamic CBMEM
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)
2013-12-04 22:21:13 +01:00
Stefan Reinauer 7f68150f1e cbmem: Implement ARM support
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>
2013-12-04 22:21:03 +01:00
Stefan Reinauer 8c5947709a 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.

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>
2013-11-25 23:02:07 +01:00
Nico Huber 8e4bb92898 util/cbmem: Fix format string in cbmem.c
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>
2013-06-03 22:24:41 +02:00
Paul Menzel 8d9ffd93b5 cbmem: map_memory: Use length modifier `j` and cast for an `off_t` argument
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>
2013-04-16 17:46:28 +02:00
Paul Menzel cb891de07f cbmem: parse_cbtable: Use length modifier `ll` `u64` argument
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>
2013-04-14 02:06:21 +02:00
Vladimir Serbinenko f4a0d019fa util/cbmem: Don't output trailing garbage for cbmemc
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>
2013-04-09 23:52:36 +02: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