Commit Graph

58 Commits

Author SHA1 Message Date
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
Vadim Bendebury 00ba25decb Get more informative output from cbmem.py
This is a cosmetic change which formats timestamp information
retrieved by cbmem.py.

Instead of printing timestamps in a single line, print them one per
line and add time (in us) elapsed since the previous timestamp.

     time base 4149594, total entries 18
     1:56,928
     2:58,851  (1,923)
     3:175,230  (116,378)
     4:175,340  (109)
     8:177,199  (1,859)
     9:214,368  (37,168)
     10:214,450  (81)
     30:214,462  (11)
     40:215,205  (743)
     50:217,180  (1,974)
     60:217,312  (132)
     70:436,984  (219,671)
     75:436,993  (8)
     80:441,424  (4,431)
     90:442,487  (1,062)
     99:553,777  (111,289)
     1000:556,513  (2,736)
     1100:824,621  (268,107)

Change-Id: I0d25cafe766c10377017697e6b206276e1a92992
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-08 19:39:06 +01:00
Vadim Bendebury f27d36c361 Fix cbmem to work on 64 bit platforms
For some reason which I fail to understand, specifying endiannes using
'@' (which means 'native' and should be the same as '<' on x86
platforms) causes cbmem.py to crash the machine on 64 bit systems.

What happens is that the addresses read from various table headers'
struct representations do not make sense, when bogus address gets
passed to get_phys_mem, the crash happens while that function is
executed.

dlaurie@ found out that replacing "@" with "<" in fact fixes the
issue. After some investigation I am just submitting this fix without
much understanding of the root cause.

Change-Id: Iaba9bc72a3f6b1d0407a5f1e3b459ccf5063969d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1715
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-08 19:38:59 +01:00
Gabe Black 5d3438de41 Revamp cbmem.py to use the coreboot tables.
This change makes significant changes to cbmem.py to make it use the
coreboot tables to find the memory console and timestamp areas instead
of looking for the in memory table TOC structure. That appears to be
more robust and gets cbmem.py working again after some unrelated
changes that affected memory layout.

It also introduces some small infrastructure to make accessing C style
structures in physical memory easier and more transparent.

Change-Id: I51833055a50c2d76423520ba6e059bf8fc50adea
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/762
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-30 17:46:26 +02:00
Vadim Bendebury b93f74bb07 Introduce utility for parsing CBMEM contents.
This is a python script which is supposed to run on a target
which is controlled by coreboot. The script examines top of
memory looking for the CBMEM signature at addresses aligned at
128K boundary. Once the script finds the CBMEM, it iterates
through the CBMEM table of contents and parses two entries: the
timestamps and the console log.

This submission is just a template to build upon to create a
utility for displaying CBMEM information while running Linux on
the target.

BUG=chrome-os-partner:4200
TEST=manual

See test description of d81e6b8c8d41f2d6 for test procedure.

Change-Id: Id863a8598eaadc2d20d728f9186843e65cbe6f37
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/5942
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/723
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-29 20:15:26 +02:00