summaryrefslogtreecommitdiff
path: root/util/cbmem
AgeCommit message (Collapse)Author
2017-09-06util/cbmem: Pretty print STAGEx_META and _CACHEKyösti Mälkki
Also align entries without name with additional indents. Change-Id: Ia6aa303daa11e6aec249232aadf4e346bad659d5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21383 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-08-11util/cbmem, util/cbfstool: resolve macro errors on FreeBSDIdwer Vollering
Using sys/cdefs.h would come to mind, however this include would not solve the build error. Built and runtime tested on FreeBSD 12.0-CURRENT, r322031 Change-Id: I6ec9bc7fea72aa69a41439e002f381bd5e5b6bc6 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: https://review.coreboot.org/20924 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-08add __must_check to */compiler.hCaveh Jalali
the __must_check function attribute is pretty much straight from the linux kernel - used to encourage callers to consume function return values. Change-Id: I1812d957b745d6bebe2a8d34a9c4862316aa8530 Signed-off-by: Caveh Jalali <caveh@google.com> Reviewed-on: https://review.coreboot.org/20881 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-13Rename __attribute__((packed)) --> __packedStefan Reinauer
Also unify __attribute__ ((..)) to __attribute__((..)) and handle ((__packed__)) like ((packed)) Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/15921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-06-14cbmem: Escape literal asterisks in log banner regexJulius Werner
I had a stupid. :( Asterisks have a special meaning in regexes, but I just wanted to match three literal ones. This kills the regex parser. Change-Id: Ia6149e72715d651c914583ed3235680ce5b7a2e0 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/20171 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-18cbmem_console: Improve 'cbmem -1' behavior for truncated pre-CBMEM logsJulius Werner
The 'cbmem -1' flag that cuts off console output before the last boot will ignore content from earlier stages if it was truncated due to lack of pre-CBMEM console space. This patch makes the "log truncated" message more specific and adds it as an additional cut-off marker to 'cbmem -1' to counteract that problem. Also raise the log level of the coreboot banner one step to BIOS_NOTICE to make it more likely to be included in the output for 'cbmem -1' to find. (I believe NOTICE is reasonable but I wouldn't want to go as far as WARN which should be reserved for actual problems. Of course this is not ideal, but then again, our whole log-level system really isn't... it would be better if we could make it always print a banner to the CBMEM console without affecting the UART at the same time, but that would require a larger amount of work.) Change-Id: I58288593dfa757e14f4a9da4ffa7e27b0b66feb9 Reported-by: https://ticket.coreboot.org/issues/117 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19720 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-05-15util/cbmem: mmap underflow on low addressesAaron Durbin
There is code to adjust the mapping down if a mmap fails at a physical address. However, if the address is less than the page size of the system then the physical offset will underflow. This can actually cause a kernel panic on when operating on /dev/mem. The failing condition happens when the requested mapping at 0 fails in the kernel. The fallback path is taken and page size is subtracted from 0 making a very large offset. The PAT code in the kernel fails with a BUG_ON in reserve_memtype() checking start >= end. The kernel needs to be fixed as well, but this fallback path is wrong as well. BUG=b:38211793 Change-Id: I32b0c15b2f1aa43fc57656d5d2d5f0e4e90e94ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/19679 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-05-02cbmem: Add new command line flag to dump console for one boot onlyJulius Werner
Even though the persistent CBMEM console is obviously awesome, there may be cases where we only want to look at console output from the last boot. It's easy to tell where one boot ends and another begins from the banner message that coreboot prints at the start of every stage, but in order to make it easier to find that point (especially for external tools), let's put that functionality straight into the cbmem utility with a new command line flag. Use the POSIX/libc regular expression API to find the banner string for maximum compatilibity, even though it's kinda icky. Change-Id: Ic17383507a884d84de9a2a880380cb15b25708a1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19497 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
2017-04-20Turn CBMEM console into a ring buffer that can persist across rebootsJulius Werner
This patch allows the CBMEM console to persist across reboots, which should greatly help post factum debugging of issues involving multiple reboots. In order to prevent the console from filling up, it will instead operate as a ring buffer that continues to evict the oldest lines once full. (This means that if even a single boot doesn't fit into the buffer, we will now drop the oldest lines whereas previous code would've dropped the newest lines instead.) The console control structure is modified in a sorta backwards-compatible way, so that new readers can continue to work with old console buffers and vice versa. When an old reader reads a new buffer that has already once overflowed (i.e. is operating in true ring buffer mode) it will print lines out of order, but it will at least still print out the whole console content and not do any illegal memory accesses (assuming it correctly implemented cursor overflow as it was already possible before this patch). BUG=chromium:651966 TEST=Rebooted and confirmed output repeatedly on a Kevin and a Falco. Also confirmed correct behavior across suspend/resume for the latter. Change-Id: Ifcbf59d58e1ad20995b98d111c4647281fbb45ff Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18301 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-04-14cbmem: Add custom aligned memcpy() implementationJulius Werner
On some architectures (like AArch64), /dev/mem mappings outside of the area marked as normal RAM use a memory type that does not support unaligned accesses. The libc memcpy() implementation on these architectures may not know or expect that and make an unaligned access for certain source/dest/length alignments. Add a custom memcpy() implementation that takes these restrictions into account and use it anywhere we copy straight out of /dev/mem memory. Change-Id: I03eece380a14a69d4be3805ed72fba640f6f7d9c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18300 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-09-15cbmem: Exit with an errorlevel of 0 after printing helpMartin Roth
cbmem --help should not return an error to the OS. Change-Id: Id00091c679dbb109bc352cf8a81d67c2ae5666ec Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16574 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2016-07-31util/cbmem: Initialize variablePatrick Georgi
There can be cases where "found" wasn't initialized, do so. Change-Id: Ifef8d61daa70e27ec39b7a8f3481d2316dfaa36e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Found-by: Coverity Scan #1347334 Reviewed-on: https://review.coreboot.org/15969 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-31Remove extra newlines from the end of all coreboot files.Martin Roth
This removes the newlines from all files found by the new int-015-final-newlines script. Change-Id: I65b6d5b403fe3fa30b7ac11958cc0f9880704ed7 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/15975 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-20cbmem: share additional time stamps IDsAntonello Dettori
Split the additional time stamps concerning depthcharge from the cbmem utility sourcecode and move them into commonlib/timestamp_serialized.h header. Change-Id: Ic23c3bc12eac246336b2ba7c7c39eb2673897d5a Signed-off-by: Antonello Dettori <dev@dettori.io> Reviewed-on: https://review.coreboot.org/15725 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-03-14util/cbmem: Scale time stamp values correctlyAaron Durbin
Commit c49014e (timestamp: add tick frequency to exported table) refactors the code, but forgets to correctly scale the frequency to megahertz, where the value is read from sysfs, so that printing time stamp information shows milliseconds instead of microseconds, as can be seen on the output `cbmem -t` for the ASRock E350M1 below. ``` 0:1st timestamp 515 10:start of ramstage 515 (0) 30:device enumeration 515 (0) 40:device configuration 610 (94) 50:device enable 614 (4) 60:device initialization 624 (9) 70:device setup done 639 (14) 75:cbmem post 844 (205) 80:write tables 844 (0) 90:load payload 849 (4) 15:starting LZMA decompress (ignore for x86) 849 (0) 16:finished LZMA decompress (ignore for x86) 869 (20) 99:selfboot jump 869 (0) Total Time: 350 ``` So scale the return value correctly to megahertz, by dividing it with 1000. ``` 0:1st timestamp 515,655 10:start of ramstage 515,655 (0) 30:device enumeration 515,663 (7) 40:device configuration 610,620 (94,957) 50:device enable 614,680 (4,059) 60:device initialization 624,618 (9,938) 70:device setup done 639,553 (14,934) 75:cbmem post 844,707 (205,154) 80:write tables 844,710 (2) 90:load payload 849,532 (4,821) 15:starting LZMA decompress (ignore for x86) 849,655 (123) 16:finished LZMA decompress (ignore for x86) 869,903 (20,247) 99:selfboot jump 869,922 (19) Total Time: 354,261 ``` Change-Id: Iea032c62487c7946b6194a90268755034c6350df Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: https://review.coreboot.org/14086 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2016-02-22cbfs: Add LZ4 in-place decompression support for pre-RAM stagesJulius Werner
This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-04util/cbmem: Add new depthcharge timestampsJulius Werner
This patch adds strings for the timestamp changes and additions in the Chrome OS bootloader (depthcharge). See http://crosreview.com/323783 for details and justification. BRANCH=none BUG=None TEST=Booted Oak, confirmed that cbmem output includes new timestamps. Change-Id: I9ad68edca660f4e4286e680316b4e14f1259d1bc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c1b1f6d669f62217ed701cd3561b9d14973d890a Original-Change-Id: I7256ca62c69f2ab7279fd2656fbbfa610e04fc44 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/323871 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13576 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-27chromeos: Add timestamps to measure VPD read timesJulius Werner
This patch adds three timestamps to coreboot and the cbmem utility that track the time required to read in the Chrome OS Vital Product Data (VPD) blocks (RO and RW). It's useful to account for these like all other large flash accesses, since their size is variable. BRANCH=None BUG=None TEST=Booted Oak, found my weird 100ms gap at the start of ramstage properly accounted for. Change-Id: I2024ed4f7d5e5ae81df9ab5293547cb5a10ff5e0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b97288b5ac67ada56e2ee7b181b28341d54b7234 Original-Change-Id: Ie69c1a4ddb6bd3f1094b3880201d53f1b5373aef Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/322831 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://review.coreboot.org/13139 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-13utils: Remove old license text from help & disclaimer fileMartin Roth
The license text that we decided to remove was removed from the headers of these files, but was still left in the help text. Remove it from those locations as well. Change-Id: I0e1b3b79f1afa35e632c4a4dd09a8bf2b02eaa6d Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12913 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-29cbmem: Makefile: Add install targetDenis 'GNUtoo' Carikli
Change-Id: Ib20481e43e6ca5b56c630cdc0eb7b1b01311cbb6 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: https://review.coreboot.org/12404 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-20util/cbmem: Add --rawdump <cbtable ID> and extend -l outputPratik Prajapati
Changed following things, (1) cbmem -l would give both ID and Name for coreboot table along with START and LENGTH of each entry e.g. localhost ~ # cbmem -l CBMEM table of contents: NAME ID START LENGTH <.....> 3. TIME STAMP 54494d45 77ddd000 000002e0 4. MRC DATA 4d524344 77ddb000 00001880 5. ROMSTG STCK 90357ac4 77dd6000 00005000 6. VBOOT WORK 78007343 77dd2000 00004000 7. VBOOT 780074f0 77dd1000 00000c3c 8. RAMSTAGE 9a357a9e 77d13000 000be000 9. REFCODE 04efc0de 77c01000 00112000 10. ACPI GNVS 474e5653 77c00000 00001000 11. SMM BACKUP 07e9acee 77bf0000 00010000 <..etc..> (2) With this patch, new command line arg "rawdump" or "-r" will be added to cbmem user can grab the ID with "cbmem -l" and execute "cbmem -r <ID>" to get raw dump of cbtable for the <ID> in interest. This change is needed to get MMA results data from cbtable. Coreboot stores the MMA results in cbmem. Separate post processing scripts uses cbmem utility to get the these data. This feature in the cbmem tool can also help debugging some issues where some specific ID of cbtable needs examination. BRANCH=none BUG=chrome-os-partner:43731 TEST=Build and Boot kunimitsu (FAB3). Cbmem -r and -l works as described. Not tested on Glados CQ-DEPEND=CL:299476,CL:299475,CL:299473,CL:299509,CL:299508,CL:299507,CL:*230478,CL:*230479 Change-Id: I70ba148113b4e918646b99997a9074300a9c7876 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f60c79d845d4d4afca480b6884c564a0d5e5caf8 Original-Change-Id: I1dde50856f0aa8d4cdd3ecf013bd58d37d76eb72 Original-Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com> Original-Signed-off-by: Icarus Sparry <icarus.w.sparry@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/299474 Original-Commit-Ready: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Original-Tested-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Reviewed-on: http://review.coreboot.org/12482 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-20util/cbmem: Fix out of bounds accessAaron Durbin
Building cbmem with ASan $ CC=gcc-5 CFLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-fsanitize=address" make it sometimes finds a heap-buffer-overflow, while dumping the CBMEM console. $ sudo ./cbmem -c ================================================================= ==11208==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5d5782b at pc 0x0804a4d7 bp 0xbfe23bc8 sp 0xbfe23bbc WRITE of size 1 at 0xb5d5782b thread T0 #0 0x804a4d6 in dump_console /home/joey/src/coreboot/util/cbmem/cbmem.c:553 #1 0x804a4d6 in main /home/joey/src/coreboot/util/cbmem/cbmem.c:1134 #2 0xb70a3a62 in __libc_start_main (/lib/i386-linux-gnu/i686/cmov/libc.so.6+0x19a62) #3 0x8048cf0 (/home/joey/src/coreboot/util/cbmem/cbmem+0x8048cf0) 0xb5d5782b is located 50 bytes to the right of 131065-byte region [0xb5d37800,0xb5d577f9) allocated by thread T0 here: #0 0xb72c64ce in __interceptor_malloc (/usr/lib/i386-linux-gnu/libasan.so.2+0x924ce) #1 0x804a407 in dump_console /home/joey/src/coreboot/util/cbmem/cbmem.c:542 #2 0x804a407 in main /home/joey/src/coreboot/util/cbmem/cbmem.c:1134 #3 0xb70a3a62 in __libc_start_main (/lib/i386-linux-gnu/i686/cmov/libc.so.6+0x19a62) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/joey/src/coreboot/util/cbmem/cbmem.c:553 dump_console Shadow bytes around the buggy address: 0x36baaeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36baaec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36baaed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36baaee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36baaef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 =>0x36baaf00: fa fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa 0x36baaf10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36baaf20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36baaf30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36baaf40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36baaf50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe ==11208==ABORTING Fix up commit 06b13a37 (cbmem: Terminate the cbmem console at the cursor position.) by reverting setting the cursor to 0. Change-Id: Id614a8e0f1a202671dd091f825d826a17176bfcc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/10572 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-04util/cbmem: remove duplicated cbmem data structure logic.Aaron Durbin
The cbmem utility shouldn't be using the intra coreboot data structures for obtaining the produced data/information. Instead use the newly added cbmem records in the coreboot tables for pulling out the data one wants by using the generic indexing of coreboot table entries. BUG=chrome-os-partner:43731 BRANCH=None TEST=Interrogated cbmem table of contents with updated code. Change-Id: I51bca7d34baf3b3a856cd5e585c8d5e3d8af1d1c Reviewed-on: http://review.coreboot.org/11758 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-10-29util/cbmem: Handle EC_VBOOT_DONE timestampShawn Nematbakhsh
This timestamp marks that EC verification has completed. BUG=chromium:537269 TEST=Run cbmem on glados, verify "1030:finished EC verification" is seen. BRANCH=None Change-Id: I0114febae689584ec8b12c169e70f2d3995d8d4d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: deeb2ab8085e5ea0a180633eb8fb1c86aadffe94 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: I4f09e970ffedc967c82e6283973cbbcb2fbe037f Original-Reviewed-on: https://chromium-review.googlesource.com/309280 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12230 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Tested-by: build bot (Jenkins)
2015-10-24util: Update makefiles for junit testingMartin Roth
- Have clean remove junit.xml files. - Remove junit.xml target from cbmem makefile - this is in the top level Makefile.inc now. - add distclean targets to makefiles. - Make sure all makefiles have .PHONY set up. - rm commands need -f or they will fail if the file they're trying to remove doesn't exist, causing the build to fail. Change-Id: I2f0635f2c0a9417e3377a90c8d67103323c4a72f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: http://review.coreboot.org/12120 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-16util/cbmem: Fix failure with certain cbmem base alignmentsTimothy Pearson
Change-Id: Icd28af388c49ad36d7a8e414b3c82e18e1f8f523 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/11932 Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se>
2015-09-22coreboot: introduce commonlibAaron Durbin
Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-08-31util/cbmem: add -T option for machine parseable timestampsAaron Durbin
In order to make analysis easier provide an option (-T) to print timestamps in a parseable format: ID<tab>raw timestamp<tab>time from previous entry<tab>description BUG=chrome-os-partner:44669 BRANCH=firmware-strago-7287.B TEST=Built and tested on glados. Used the following script: cbmem -T | awk 'BEGIN { FS="\t" } { tot += $3 } END { print tot }' Change-Id: I06dc0487d1462b6a78924130f0ad74b0d787d3f8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11471 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-31timestamp: add tick frequency to exported tableAaron Durbin
Add the timestamp tick frequency within the timestamp table so the cbmem utility doesn't try to figure it out on its own. Those paths still exist for x86 systems which don't provide tsc_freq_mhz(). All other non-x86 systems use the monotonic timer which has a 1us granularity or 1MHz. One of the main reasons is that Linux is reporting /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true turbo frequency on turbo enables machines. This change also fixes the p-state values honored in cpufreq for turbo machines in that turbo p-pstates were reported as 100MHz greater than nominal. BUG=chrome-os-partner:44669 BRANCH=firmware-strago-7287.B TEST=Built and booted on glados. Confirmed table frequency honored. Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11470 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-14util/cbmem: accumulate total time for all entriesAaron Durbin
Display the total accumulated time using each timestamp entry. It purposefully doesn't take into account the first timestamp because that can be a platform dependent value that may not contribute to the concept of "total". BUG=None BRANCH=None TEST=Ran cbmem on glados where TSC doesn't reset to 0 on reboots. Clear total value given at end. Original-Change-Id: Idddb8b88d3aaad11d72c58b18e8fd9fd1447a30e Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/291480 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Original-Trybot-Ready: David James <davidjames@chromium.org> Change-Id: I79a0954d3b738323aaebb3e05171bcf639e5d977 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11202 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-14cbmem: export base_time in timestamp tableAaron Durbin
It's helpful to know the base_time (1st timestamp) in the timestamp table because it provides more information like the accumulated time before the first timestamp was recorded. In order to maximize this information report the base time as an entry that is printed. It's called '1st timestamp'. The implementation turns all the timestamp entries into absolute times so one can observe both absolute and relative time for each marker. Change-Id: I1334a2d980e3bcc2968a3bd6493c68b9efcca7ae Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10883 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-14cbmem: convert x86 timestamps on OpenBSDPatrick Georgi
Change-Id: I16bfe42a00d73209307655601edaa3a8ffc9c902 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/10905 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-09cbmem: Break out CBMEM_ID to a separate header fileMarc Jones
The cbmem util needs the CBMEM_IDs and the strings for reporting and shares the cbmem.h file with coreboot. Split out the IDs so for a simpler sharing and no worries about overlap of standard libraries and other things in the header that coreboot requires, but the tool does not. Change-Id: Iba760c5f99c5e9838ba9426e284b59f02bcc507a Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/10430 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-18util/cbmem: Update cbmem utility to parse the new IMD structuresTimothy Pearson
This resolves the cbmem table of contents access failure introduced in commit 0dff57dd. Change-Id: Ie143ae11d97f26bd17fe10e1382fae9e5ad1a60e Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/10236 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-30cbmem: Add FSP timestampsLee Leahy
Add additional FSP timestamp values to cbmem.h and specify values for the existing ones. Update cbmem.c with the FSP timestamp values and descriptions. BRANCH=none BUG=None TEST=Build for Braswell and Skylake boards using FSP 1.1. Change-Id: I835bb090ff5877a108e48cb60f8e80260773771b Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10025 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-22cbmem: switch over to imd-based cbmemAaron Durbin
By design, the imd library still provdes dynamic growth so that feature is consistent. The imd-based cbmem packs small allocations into a larger entry using a tiered imd. The following examples show the reduced fragmentation and reduced memory usage. Before with dynamic cbmem: CBMEM ROOT 0. 023ff000 00001000 aaaabbbb 1. 023fe000 00001000 aaaabbbc 2. 023fd000 00001000 aaaabbbe 3. 023fc000 00001000 aaaacccc 4. 023fa000 00002000 aaaacccd 5. 023f9000 00001000 ROMSTAGE 6. 023f8000 00001000 CONSOLE 7. 023d8000 00020000 COREBOOT 8. 023d6000 00002000 After with tiered imd: IMD ROOT 0. 023ff000 00001000 IMD SMALL 1. 023fe000 00001000 aaaacccc 2. 023fc000 00001060 aaaacccd 3. 023fb000 000007cf CONSOLE 4. 023db000 00020000 COREBOOT 5. 023d9000 00002000 IMD small region: IMD ROOT 0. 023fec00 00000400 aaaabbbb 1. 023febe0 00000020 aaaabbbc 2. 023feba0 00000040 aaaabbbe 3. 023feb20 00000080 ROMSTAGE 4. 023feb00 00000004 Side note: this CL provides a basis for what hoops one needs to jump through when there are not writeable global variables on a particular platform in the early stages. Change-Id: If770246caa64b274819e45a26e100b62b9f8d2db Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9169 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-14timestamps: You can never have enough of them!Julius Werner
Now that we have timestamps in pre-RAM stages, let's actually make use of them. This patch adds several timestamps to both the bootblock and especially the verstage to allow more fine-grained boot time tracking. Some of the introduced timestamps can appear more than once per boot. This doesn't seem to be a problem for both coreboot and the cbmem utility, and the context makes it clear which operation was timestamped at what point. Also simplifies cbmem's timestamp printing routine a bit, fixing a display bug when a timestamp had a section of exactly ",000," in it (e.g. 1,000,185). BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show up and contained sane values. Booted Storm (no timestamps here since it doesn't support pre-RAM timestamps yet). Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234063 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9608 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08timestamp: Add bootblock start and end to timestamp constantsFurquan Shaikh
BUG=chrome-os-partner:32973 BRANCH=None TEST=cbmem -t to check proper timestamps on ryu Change-Id: Ic31c5d9f3e397d90b08fe1c5e152148f4a278b95 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 92469e04c1c52bd60a8a37f017d865d0a838bff5 Original-Change-Id: I95419a6d240c168c8b6a489cac969390ecf6dea0 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223345 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9340 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21cbmem: stop assuming 1MiB of memory can be mappedAaron Durbin
The default mapping size is 1MiB of ram. However, not all systems allow 1MiB of memory to mapped depending on the kernel's memory map. Therefore, be explicit about the sizes to mmap(). The only path that wasn't cleaned up was the coverage path as that needs to handle dynamic cbmem. The correct way to fix that is to add a global like the timestamps that is set while parsing cbtable. BUG=chrome-os-partner:31355 BRANCH=None TEST=Can cbmem -ltc on ryu. Change-Id: I548afa5ddbe0a859f52bc2ab2d0931186ee378a5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: df4991ce1da7f0c25e99d84222cbc8d3189d0d66 Original-Change-Id: I27b70ae8a8fba168d1c1829bbef0135c7b651eac Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/221971 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/8829 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-13cbmem: Add support for new 'coreboot' compatible device tree bindingJulius Werner
This patch brings the cbmem utility in line with the recent change to coreboot's device tree binding. Since trying to find the right node to place this binding has been so hard (and still isn't quite agreed upon), and because it's really the more correct thing to do, this code searches through the device tree for the 'coreboot' compatible property instead of looking up a hardcoded path. It also provides bullet-proof '#address-cells' handling that should work for any endianness and size. BUG=chrome-os-partner:29311 TEST=Ran cbmem -c and cbmem -t on Nyan_Big. Also straced the to make sure everything looks as expected. 'time cbmem -t' = ~35ms shows that there is no serious performance problem from the more thorough lookup code. Original-Change-Id: I806a21270ba6cec6e81232075749016eaf18508b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/204274 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit 3e64e28f684e60e8b300906c1abffee75ec6a5c2) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I0a0a4f69330d3d8c5c3ea92b55f5dde4d43fca65 Reviewed-on: http://review.coreboot.org/8141 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-30cbmem: use a single id to name mapping tableVadim Bendebury
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-03util/cbmem: Print name instead of ID of CBMEM_ID_SMM_SAVE_SPACEPaul Menzel
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-10-18util/cbmem: Fix CBMEM TOC printingPaul Menzel
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-18util/cbmem/cbmem: Remove obsolete commentPaul Menzel
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-07-30cbmem: Terminate the cbmem console at the cursor position.Gabe Black
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-06-20util/cbmem: Workaround for IS_ENABLED()Kyösti Mälkki
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-04-02util/cbmem: handle larger than 1MiB mappings for consoleAaron Durbin
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-01-11util/cbmem/Makfile: Add rule `junit.xml` for JenkinsPaul Menzel
The rule has the target `junit.xml` and runs `make clean` and `make` and logs the result in the file `junit.xml` suitable for consumption by Jenkins. Change-Id: I42a31f6c7a45fa9c3773969d78f745fcc4e09dbd Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/4611 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-05cbmem: print timestamp namesStefan Reinauer
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-05Fix timestamp output in cbmem utility on ARMStefan Reinauer
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-04cbmem: fix userspace utility to work with dynamic CBMEMStefan Reinauer
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-04cbmem: Implement ARM supportStefan Reinauer
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-11-25cbmem utility: compatibility with older coreboot versionsStefan Reinauer
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-07-01cbmem: Fix makefileStefan Tauner
The .dependencies rule did not use the CPPFLAGS variable which led to funny behavior: a spurious termination message the first time (after checkout/make distclean) one executes make. Afterwards the (wrongly) empty .dependencies file hides the problem and the binary is created anyway. $ make cbmem.c:37:34: fatal error: boot/coreboot_tables.h: No such file or directory compilation terminated. cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c cc cbmem.o -o cbmem $ make make: Nothing to be done for `all'. $ make clean rm -f cbmem *.o *~ $ make cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c cc cbmem.o -o cbmem $ make distclean rm -f cbmem *.o *~ rm -f .dependencies $ make cbmem.c:37:34: fatal error: boot/coreboot_tables.h: No such file or directory compilation terminated. cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c cc cbmem.o -o cbmem I fixed that by adding the CPPFLAGS variable to the .dependencies recipe, just like Stefan Reinauer did in Chromium (Ia9d2e10a3ef122f30d681d16c2291eb108ead835), hence the split sign-off for this tiny change. :) Change-Id: Icd11b146ad762cbdf9774630b950f70e1253a072 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-on: http://review.coreboot.org/3548 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-06-03util/cbmem: Fix format string in cbmem.cNico Huber
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-04-16cbmem: map_memory: Use length modifier `j` and cast for an `off_t` argumentPaul Menzel
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-15cbmem: Makefile: Allow to override `CC` variablePaul Menzel
Now users can use a different compiler from GCC like Clang by for example doing `CC=clang make`. Change-Id: I664a36df79f7496a56d89bdb61948b2eda33a6b4 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3082 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14cbmem: parse_cbtable: Use length modifier `ll` `u64` argumentPaul Menzel
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-09util/cbmem: Don't output trailing garbage for cbmemcVladimir 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-12Implement GCC code coverage analysisStefan 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-08cbmem utility: Find actual CBMEM areaStefan 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-08cbmem utility: unify debug outputStefan 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-08cbmem utility: Add option to dump cbmem consoleStefan 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-08cbmem utility: drop obsolete python based implementationStefan Reinauer
The first version of the cbmem utility was written in python, but it had issues with 64bit systems and other little hick ups. Since the C version has much fewer dependencies (no python needed on target system), and it works in all corner cases, drop the python version. Change-Id: Ida3d6c9bb46f6d826f45538e4ceaa4fc1e771ff5 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2115 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Tested-by: build bot (Jenkins)
2013-01-04cbmem utility: Use mmap instead of fseek/freadStefan 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-03cbmem utility: support command line optionsStefan 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-12cbmem compilation needs to use the hardened toolchainVadim 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-12Utility to dump boot timing tableVadim 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>
2012-11-08Get more informative output from cbmem.pyVadim Bendebury
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-08Fix cbmem to work on 64 bit platformsVadim Bendebury
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-03-30Revamp cbmem.py to use the coreboot tables.Gabe Black
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-29Introduce utility for parsing CBMEM contents.Vadim Bendebury
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>