summaryrefslogtreecommitdiff
path: root/util/cbmem
AgeCommit message (Collapse)Author
2017-12-12util/cbmem: Print timestamp frequency in verbose modeMartin Roth
The code flow is changed slightly to print the timestamp frequency from either method of determining it. BUG=b:70432544 TEST=Build and test cbmem -t -V Change-Id: I02286fa67919e70a3592cdbcc1c9ca2991b7f385 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/22821 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-10-02util/cbmem: fix feedback for 'be explicit about memory map sizes'Aaron Durbin
Julius made some suggestions to fix/improve commit 46300aa2. Implement those. BUG=b:66681446 Change-Id: I6becac9ffdcc65745e88734dfb80d12b581584a1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21757 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-09-28util/cbmem: be explicit about memory map sizesAaron Durbin
The cbmem utility has inherited some workarounds that originated from the default 1 MiB mapping always working. This 1 MiB mmap won't necessarily succeed if the 1 MiB encroaches on a subsequent memory range that has different cacheability. To fix this, map in only 4 KiB when the table size is not known which is the case for any forwarding entry or any low table entries on x86. That smaller mapping is then searched for a valid header. Once a valid header is found the full table is mapped and parsed allowing a forwarding entry to take precedence. Lastly, the lbtable is kept mapped in such that other operations can just operate on mapping that was previously parsed. In order to allow multiple in-flight mappings a struct mapping was added which caused the ripple within the code. However, there shouldn't be any more reasons for putting weird heuristics for when to fail. If the tables are bad then it's very much possible that mappings will fail. Retrying when the exact sizes are already known won't fix those issues. BUG=b:66681446 Change-Id: Ica0737aada8dc07311eae867e87ef2fd24eae98d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21718 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-09-28util/cbmem: make data structure accesses constAaron Durbin
Since the mapping is const just make all the data structure accesses const. BUG=b:66681446 Change-Id: I018cf2f2bfea2e736b097ecd1242af19c878ecb5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21719 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-11 17:57:46 +0000