| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2013-04-09 | util/cbmem: Don't output trailing garbage for cbmemc | Vladimir Serbinenko | |
| 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-01-12 | Implement GCC code coverage analysis | Stefan Reinauer | |
| 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-08 | cbmem utility: Find actual CBMEM area | Stefan Reinauer | |
| ... 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 | cbmem utility: unify debug output | Stefan Reinauer | |
| ... 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 | cbmem utility: Add option to dump cbmem console | Stefan Reinauer | |
| 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-04 | cbmem utility: Use mmap instead of fseek/fread | Stefan Reinauer | |
| 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-03 | cbmem utility: support command line options | Stefan Reinauer | |
| 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) | |||
| 2012-11-12 | cbmem compilation needs to use the hardened toolchain | Vadim Bendebury | |
| 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 | Utility to dump boot timing table | Vadim Bendebury | |
| 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> | |||
 |
index : coreboot | |
| Some coreboot project code with my work | vimacs |
| summaryrefslogtreecommitdiff |