summaryrefslogtreecommitdiffstats
path: root/util
Commit message (Collapse)AuthorAgeFilesLines
* util/cbfstool: unbreak compilation on FreeBSDIdwer Vollering2021-01-131-0/+2
| | | | | | | | | | | | Compilation has been broken in commit I022468f6957415ae68a7a7e70428ae6f82d23b06 Adding a missing define solved this. See https://cgit.freebsd.org/src/tree/sys/sys/fcntl.h#n319 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Change-Id: I3433e4c9269880d3202dd494e5b2e962757a6b87 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49314 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* util/superiotool: add IT5570E registersMichael Niewöhner2021-01-131-0/+54
| | | | | | | | | | | | Add registers from IT5570E datsheet v0.3.1. Tested on Clevo L141CU. Change-Id: Idc764c6180e235298835d7639fcb0b562a2c21a4 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48922 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/ifdtool: Add coreboot build system supportPatrick Georgi2021-01-121-0/+18
| | | | | | | | | | | | | When building as part of the coreboot build system, use the same mechanism as other tools (cbfstool, amdfwtool, ...) so that abuild builds ifdtool once into sharedutils instead of once per board (while avoiding other race conditions, too). Change-Id: I42c7b43cc0859916174d59cba6b62630e70287fd Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49312 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* util/superiotool: Add IT8720F EC registersMichael Büchler2021-01-121-0/+29
| | | | | | | | | | | | | Registers and their default values are from the datasheet ("IT8720F", "Preliminary Specification V0.1"). Tested on an Acer G43T-AM3. Signed-off-by: Michael Büchler <michael.buechler@posteo.net> Change-Id: I69987be4f5cb50b3c20f06733f30b308891d5ad0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44985 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
* util/sconfig: Emit chip config pointers for PCI devices on root busFurquan Shaikh2021-01-111-5/+20
| | | | | | | | | | | | | | | This change emits chip config pointers for PCI devices on root bus in static_devices.h so that the config structure can be accessed directly without having to reference the device structure. This allows the linker to optimize out unused parts of the device tree from early stages like bootblock. Change-Id: I1d42e926dbfae14b889ade6dda363d8607974cae Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49214 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/sconfig: Change __pci*|__pnp* device pointers to constFurquan Shaikh2021-01-111-4/+4
| | | | | | | | | | | | | | This change updates the device pointers exposed in static_devices.h to const instead of DEVTREE_CONST. The pointer itself doesn't really need to be DEVTREE_CONST. Change-Id: I061b05d994fc5c4156ee8bddabadf940f0aeeac3 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49242 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
* superiotool/nuvoton: Set NCT6791D GPIO inputs to NANANico Huber2021-01-101-3/+3
| | | | | | | | | | | | | | There were several default values given for GPIO data and status registers. As all GPIO are configured as inputs by default, we can't predict the values of these registers, hence set their default values to NANA. Change-Id: I0507dd75e0f2a5c7e4d2e9cdbe1f860b544deac3 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49241 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Clay Daniels <clay.daniels.jr@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* util/autoport: Rename to mainboard_fill_gnvs()Kyösti Mälkki2021-01-102-3/+4
| | | | | | | | Change-Id: Ia8d7083ca2f21abbb5f184c1b55dcf1bf047a7be Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49231 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* util/amdfwtool,post: add missing distclean targetFelix Held2021-01-082-0/+4
| | | | | | | | | | | Without this target some spurious errors occurred when running make distclean at the top level of coreboot. Change-Id: I3d3061b386fc5b4a043cfc7ff8fd3c0da33c0e83 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49227 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/testing: remove genprof targetFelix Held2021-01-081-1/+0
| | | | | | | | | | | | | commit 8c99c27df10f6c5a120e41ffb0948e357f5a2d20 removed util/genprof, so it needs to be dropped here as well to avoid spurious breakages of the build. Change-Id: I420b5c43e2d97373a8e665f457463a06e16ecfb9 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49226 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Singer <felixsinger@posteo.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/crossgcc/.gitignore: Add cmakeArthur Heymans2021-01-081-0/+2
| | | | | | | | | | Change-Id: I5ce346515f4468699396e214acfaa3b62f6d891d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49115 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* cbfstool: Use flock() when accessing CBFS filesJulius Werner2021-01-081-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Trying to do multiple operations on the same CBFS image at the same time likely leads to data corruption. For this reason, add BSD advisory file locking (flock()) to cbfstool (and ifittool which is using the same file I/O library), so that only one process will operate on the same file at the same time and the others will wait in line. This should help resolve parallel build issues with the INTERMEDIATE target on certain platforms. Unfortunately, some platforms use the INTERMEDIATE target to do a direct dd into the CBFS image. This should generally be discouraged and future platforms should aim to clearly deliminate regions that need to be written directly by platform scripts with custom FMAP sections, so that they can be written with `cbfstool write`. For the time being, update the legacy platforms that do this with explicit calls to the `flock` utility. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I022468f6957415ae68a7a7e70428ae6f82d23b06 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49190 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Furquan Shaikh <furquan@google.com>
* cpu/intel/model_206ax: Rename `cX_acpower` optionsAngel Pons2021-01-061-3/+3
| | | | | | | | | | They aren't specific to AC power operation anymore. Also adapt autoport. Change-Id: Ib04d0a08674b7d2773d440d39bd6dfbd4359e0fb Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49089 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* cpu/intel/model_206ax: Unify ACPI C-state optionsAngel Pons2021-01-061-3/+0
| | | | | | | | | | | | | | | | All mainboards use the same values for AC and battery, even desktop boards without a battery. Use the AC values everywhere and drop the battery values. Subsequent commits will rename the AC power options accordingly, and will also clean up the corresponding acpigen code. This is intentional so as to ease reviewing the devicetree changes. Also update util/autoport accordingly. Change-Id: I581dc9b733d1f3006a4dc81d8a2fec255d2a0a0f Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49088 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* util/testing: Build test more of our toolsPatrick Georgi2021-01-061-0/+4
| | | | | | | | | | | | https://qa.coreboot.org/job/untested-coreboot-files reports a bunch of untouched Makefiles, so we never even attempt to build those tools. Change-Id: I70ca658d9642b84fa8388c72ecb83327a6a74291 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47446 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
* drivers/vpd: Add VPD region to default FMAP when selectedMatt DeVillier2021-01-041-0/+1
| | | | | | | | | | | | | | | | | | Currently, use of the VPD driver to read VPD tables from flash requires the use of a custom FMAP with one or more VPD regions. Extend this funtionality to boards using the default FMAP by creating a dedicated VPD region when the driver is selected. Test: build qemu target with CONFIG_VPD selected, verify entry added to build/fmap.fmd. Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* util: Make sure all util dirs have description files at top levelMartin Roth2021-01-046-1/+24
| | | | | | | | | | | | | New util directories have been added with no description.md file. The description file for supermicro was added at a secondary level, which doesn't help a user find the util since no path was added. Move it up to the top level. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I40b4c25dd7706513e96c6b8078a34160f8bb901e Reviewed-on: https://review.coreboot.org/c/coreboot/+/48961 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tom Hiller <thrilleratplay@gmail.com>
* util/amdfwtool: portability fixes for FreeBSDIdwer Vollering2020-12-313-8/+2
| | | | | | | | | | Add the stdint.h header, and drop the GLIBC section from amdfwtool.h to build this tool on FreeBSD as well as Linux. Signed-off-by: Idwer Vollering <vidwer@gmail.com> Change-Id: I295fd308b0f5e2902931f02c9455823a614976de Reviewed-on: https://review.coreboot.org/c/coreboot/+/48977 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/xcompile: fix XGCCPATH handlingrnhmjoj2020-12-291-1/+1
| | | | | | | | | | | | | | | | | | This patch fixes the build with an external (coreboot) toolchain. When the toolchain is not under util/crossgcc/xgcc, setting XGCCPATH to /path/to/toolchain results in the error: toolchain.inc:169: The coreboot toolchain version of iasl '<date>' was not found The reason is that the xcompile script incorrectly assumes XGCCPATH to have a trailing slash. Change-Id: Ifcc4bd2b081fa3603420dc0a8cab3b47967ebc65 Signed-off-by: Michele Guerini Rocco <rnhmjoj@inventati.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48937 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device + util/sconfig: introduce new device `gpio`Michael Niewöhner2020-12-286-402/+312
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Makefile: Add $(xcompile) to specify where to write xcompileRaul E Rangel2020-12-234-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file was being written to the root src directory. It is the only file being written to src during a normal build, while all others are being written to $(obj). I added a new variable to allow specifying the xcompile path. This allows generating a single file if building multiple boards. I also moved the default location into $(obj) so we don't pollute the src directory by default. I also cleaned up the generation of xcompile by removing the unnecessary eval and NOCOMPILE check. I also left .xcompile in distclean so it cleans up stale files. Since .xcompile is written into $(obj), `make clean` will now remove it. The tegra Makefiles are outside of the normal build process, so I just updated those Makefiles to point to the default xcompile location of a normal build. The what-jenkins-does target had to be updated to support these special targets. We generate an xcompile specifically for these targets and pass it into the Makefile. Ideally we should get these targets added to the main build. BUG=b:112267918 TEST=ran `emerge-grunt coreboot` and `make what-jenkins-does` Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ia83f234447b977efa824751c9674154b77d606b0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/28101 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* amdfwtool: Add support of cezanne and renoirZheng Bao2020-12-213-15/+124
| | | | | | | | Change-Id: I9e932631e88062b4c385567ed2eff76eda6e10c4 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48525 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util: Modify LPDDR4 spd_tools to generate SPDs for ADL boardsAmanda Huang2020-12-171-6/+7
| | | | | | | | | | | | | | | | Generates de-duplicated SPD files using a global memory part list provided by the mainboard in JSON format. BUG=b:173132516 Change-Id: I4964ec28d74ab36c6b6f2e9dce6c923d1df95c84 Signed-off-by: Amanda Huang <amanda_hwang@compal.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48526 Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* autoport: Add a license header to non-empty filesIru Cai2020-12-174-1/+9
| | | | | | | | Change-Id: I8078d8babf24feabb22856ee820ab45b7d466f62 Signed-off-by: Iru Cai <mytbk920423@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45464 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* src/lib: Add Kconfig option for SPD cache in FMAPMatt DeVillier2020-12-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the option to cache DIMM SPD data in an FMAP region is closely coupled to a single board (google/hatch) and requires a custom FMAP to utilize. Loosen this coupling by introducing a Kconfig option which adds a correctly sized and aligned RW_SPD_CACHE region to the default FMAP. Add a Kconfig option for the region name, replacing the existing hard- coded instance in spd_cache.h. Change the inclusion of spd_cache.c to use this new Kconfig, rather than the board-specific one currently used. Lastly, have google/hatch select the new Kconfig when appropriate to ensure no change in current functionality. Test: build/boot WYVERN google/hatch variant with default FMAP, verify FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log. Also tested on an out-of-tree Purism board. Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc Signed-off-by: Matt DeVillier <matt.devillier@puri.sm> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* amdfwtool: Register APCB and APCB_BK respectivelyZheng Bao2020-12-111-3/+5
| | | | | | | | | | | We took the assumption the APCB(0x60) and APCB_BK(0x68) are the same file. For picasso, they are. For later programe, they are not. Change-Id: Idea7847691c2b511b489c306f04a8cb8945fd057 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48524 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* util/amdfwtool: Fix EFS generation polarityMarshall Dawson2020-12-111-4/+11
| | | | | | | | | | | | | | | | | | | The DWORD used to indicate the Embedded Firmware Structure's generation uses 1 to indicate a first-gen structure, e.g. a SPI device's erased value of 0xffffffff. A 0 in bit 0 is how Client PSPs will interpret the structure as designed for second-gen. This change and the original addition should have no effects on any current products as none interpret offset 0x24. BUG=b:158755102 TEST=inspect EFS in coreboot.rom Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Change-Id: If391f356a1811ed04acdfe9ab9de2e146f6ef5fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/47769 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* util/cbfstool/fit.c: Add support for adding Boot Guard manifestsMichał Żygowski2020-12-111-2/+45
| | | | | | | | | | Change-Id: I8221590cad16cffea3f8b50dd880a77934b78ea8 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Christian Walter <christian.walter@9elements.com> Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48469 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* util/cbfstool/fmaptool: Generate list of terminal sectionsFurquan Shaikh2020-12-081-0/+24
| | | | | | | | | | | | | | | This change adds support in fmaptool to generate a macro in C header file that provides a list of section names that do not have any subsections. This is useful for performing build time tests on these sections. BUG=b:171534504 Change-Id: Ie32bb8af4a722d329f9d4729722b131ca352d47a Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47883 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* util/cbfstool: Add support for mapping extended window for x86 platformsFurquan Shaikh2020-12-081-8/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All x86 platforms until now have memory mapped up to a maximum of 16MiB of SPI flash just below 4G boundary in host address space. For newer platforms, cbfstool needs to be able to accommodate additional windows in the host address space for mapping SPI flash size greater than 16MiB. This change adds two input parameters to cbfstool ext-win-base and ext-win-size which a platform can use to provide the details of the extended window in host address space. The extended window does not necessarily have to be contiguous with the standard decode window below 4G. But, it is left upto the platform to ensure that the fmap sections are defined such that they do not cross the window boundary. create_mmap_windows() uses the input parameters from the platform for the extended window and the flash size to determine if extended mmap window is used. If the entire window in host address space is not covered by the SPI flash region below the top 16MiB, then mapping is assumed to be done at the top of the extended window in host space. BUG=b:171534504 Change-Id: Ie8f95993e9c690e34b0e8e792f9881c81459c6b6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47882 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool: Introduce concept of mmap_windowFurquan Shaikh2020-12-081-14/+140
| | | | | | | | | | | | | | | | | | | | | | | | | This change adds the concept of mmap_window to describe how the SPI flash address space is mapped to host address space on x86 platforms. It gets rid of the assumption that the SPI flash address space is mapped only below the 4G boundary in host space. This is required in follow up changes to be able to add more decode windows for the SPI flash into the host address space. Currently, a single mmap window is added i.e. the default x86 decode window of maximum 16MiB size living just below the 4G boundary. If the window is smaller than 16MiB, then it is mapped at the top of the host window. BUG=b:171534504 TEST=Verified using abuild with timeless option for all coreboot boards that there is no change in the resultant coreboot.rom file. Change-Id: I8dd3d1c922cc834c1e67f279ffce8fa438d8209c Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47831 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* util/cbfstool: Rename IS_TOP_ALIGNED_ADDRESS to IS_HOST_SPACE_ADDRESSFurquan Shaikh2020-12-083-4/+9
| | | | | | | | | | | | | | | | This change renames the macro `IS_TOP_ALIGNED_ADDRESS` to `IS_HOST_SPACE_ADDRESS` to make it clear that the macro checks if given address is an address in the host space as opposed to the SPI flash space. BUG=b:171534504 Change-Id: I84bb505df62ac41f1d364a662be145603c0bd5fa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47830 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool: Treat region offsets differently than absolute addressesFurquan Shaikh2020-12-082-43/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cbfstool overloads baseaddress to represent multiple things: 1. Address in SPI flash space 2. Address in host space (for x86 platforms) 3. Offset from end of region (accepted as negative number) This was done so that the different functions that use these addresses/offsets don't need to be aware of what the value represents and can use the helper functions convert_to_from* to get the required values. Thus, even if the user provides a negative value to represent offset from end of region, it was stored as an unsigned integer. There are special checks in convert_to_from_top_aligned which guesses if the value provided is really an offset from the end of region and converts it to an offset from start of region. This has worked okay until now for x86 platforms because there is a single fixed decode window mapping the SPI flash to host address space. However, going forward new platforms might need to support more decode windows that are not contiguous in the host space. Thus, it is important to distinguish between offsets from end of region and addresses in host/SPI flash space and treat them separately. As a first step towards supporting this requirement for multiple decode windows on new platforms, this change handles the negative offset provided as input in dispatch_command before the requested cbfs operation is performed. This change adds baseaddress_input, headeroffset_input and cbfsoffset_input to struct param and converts them to offsets from start of region before storing into baseaddress, headeroffset and cbfsoffset if the inputs are negative. In follow up changes, cbfstool will be extended to add support for multiple decode windows. BUG=b:171534504 TEST=Verified using abuild with timeless option for all coreboot boards that there is no change in the resultant coreboot.rom file. Change-Id: Ib74a7e6ed9e88fbc5489640d73bedac14872953f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47829 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool/.gitignore: Add ifittoolArthur Heymans2020-12-071-0/+1
| | | | | | | | | | Change-Id: Ie0ee6511e91c0bf1ff2f4ca49b24e3e5a36a06f2 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48005 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Felix Singer <felixsinger@posteo.net>
* cbfs: Add verification for RO CBFS metadata hashJulius Werner2020-12-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION feature. It's not useful to end-users in this stage so it cannot be selected in menuconfig (and should not be used other than for development) yet. With this patch coreboot can verify the metadata hash of the RO CBFS when it starts booting, but it does not verify individual files yet. Likewise, verifying RW CBFSes with vboot is not yet supported. Verification is bootstrapped from a "metadata hash anchor" structure that is embedded in the bootblock code and marked by a unique magic number. This anchor contains both the CBFS metadata hash and a separate hash for the FMAP which is required to find the primary CBFS. Both are verified on first use in the bootblock (and halt the system on failure). The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes to show some paths that need to be different when full protection against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For normal verification it is sufficient to check the FMAP and the CBFS metadata hash only once in the bootblock -- for TOCTOU verification we do the same, but we need to be extra careful that we do not re-read the FMAP or any CBFS metadata in later stages. This is mostly achieved by depending on the CBFS metadata cache and FMAP cache features, but we allow for one edge case in case the RW CBFS metadata cache overflows (which may happen during an RW update and could otherwise no longer be fixed because mcache size is defined by RO code). This code is added to demonstrate design intent but won't really matter until RW CBFS verification can be supported. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* cbfstool: Hide hash printing behind -v and add to parseable outputJulius Werner2020-12-033-14/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the upcoming introduction of CBFS verification, a lot more CBFS files will have hashes. The current cbfstool default of always printing hash attributes when they exist will make cbfstool print very messy. Therefore, hide hash attribute output unless the user passed -v. It would also be useful to be able to get file attributes like hashes in machine parseable output. Unfortunately, our machine parseable format (-k) doesn't really seem designed to be extensible. To avoid breaking older parsers, this patch adds new attribute output behind -v (which hopefully no current users pass since it doesn't change anything for -k at the moment). With this patch cbfstool print -k -v may print an arbitrary amount of extra tokens behind the predefined ones on a file line. Tokens always begin with an identifying string (e.g. 'hash'), followed by extra fields that should be separated by colons. Multiple tokens are separated by the normal separator character (tab). cbfstool print -k -v may also print additional information that applies to the whole CBFS on separate lines. These lines will always begin with a '[' (which hopefully nobody would use as a CBFS filename character although we technically have no restrictions at the moment). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I9e16cda393fa0bc1d8734d4b699e30e2ae99a36d Reviewed-on: https://review.coreboot.org/c/coreboot/+/41119 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cbfstool: Rename cbfs_walk() to cbfs_legacy_walk()Julius Werner2020-12-032-11/+13
| | | | | | | | | | | | | | | | | This function name clashes with cbfs_walk() in the new commonlib CBFS stack, so rename it to cbfs_legacy_walk(). While we could replace it with the new commonlib implementation, it still has support for certain features in the deprecated pre-FMAP CBFSes (such as non-standard header alignment), which are needed to handle old files but probably not something we'd want to burden the commonlib implementation with. So until we decide to deprecate support for those files from cbfstool as well, it seems easier to just keep the existing implementation here. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I37c7e7aa9a206372817d8d0b8f66d72bafb4f346 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41118 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cbfstool: Use cbfs_serialized.h and standard vboot helpersJulius Werner2020-12-0311-345/+129
| | | | | | | | | | | | | | This patch reduces some code duplication in cbfstool by switching it to use the CBFS data structure definitions in commonlib rather than its own private copy. In addition, replace a few custom helpers related to hash algorithms with the official vboot APIs of the same purpose. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I22eae1bcd76d85fff17749617cfe4f1de55603f4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41117 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
* lib/trace: Remove TRACE supportKyösti Mälkki2020-12-026-179/+0
| | | | | | | | | | | | | | | | | | | | | Looks like the option is generally not compatible with garbage collections. Nothing gets inlined, for example is_smp_boot() no longer evaluates to constant false and thus the symbols from secondary.S would need to be present for the build to pass even if we set SMP=n. Also the addresses of relocatable ramstage are currently not normalised on the logs, so util/genprof would be unable dress those. Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* util/mb/google/puff: remove HECI from overridetreePaul Fagerburg2020-12-011-3/+0
| | | | | | | | | | | | | | | The template for overridetree.cb includes HeciEnabled, which has been removed from the CNL config struct, so remove it from the overridetree. BUG=b:174360951 TEST=`new_variant_fulltest.sh puff` succeeds Signed-off-by: Paul Fagerburg <pfagerburg@google.com> Change-Id: I87f67c53cc75d9ddd40b4960739180a95de6ecd6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48129 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* util/pgtblgen: Improve compatibilityPatrick Georgi2020-11-302-1/+2
| | | | | | | | | | Fix build on Debian/jessie Change-Id: I987e7a03441b40ab06ccd54a21e38aac81a1c28d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48004 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
* util/docker/Makefile: Add missing separatorFrans Hendriks2020-11-301-1/+1
| | | | | | | | | | | | | | | | Build using docker results in error: Makefile:86: *** missing separator. Add space after ifeq. Tested: Building Facebook FBG1701 binary. Change-Id: Ib42abe966e67dac380173ec982c9f6bd4cf074cc Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47992 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* lp4x: Add new memory parts and generate SPDsNick Vaccaro2020-11-301-0/+12
| | | | | | | | | | | | | | | | Add MT53D512M64D4NW-046 WT:F memory part to LP4x global list of available LP4x parts and to the global JSON file containing LP4x parts and their characteristics. BUG=b:172993397 TEST=none Change-Id: I09c6eab640c169dbdb451964967d14a31e314496 Signed-off-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47980 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Rob Barnes <robbarnes@google.com>
* inteltool: Add support to print TME/MKTME statusPratik Prajapati2020-11-303-2/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | Print whether the SOC supports TME/MKTME. If the SOC supports the feature, print the status of enable and lock bit from TME_ACTIVATE MSR. -t option prints this status. Sample output: If TME/MKTME is supported: ============= Dumping INTEL TME/MKTME status ============= TME supported : YES TME locked : YES TME enabled : YES ==================================================== If TME/MKTME is not supported: ============= Dumping INTEL TME status ============= TME supported : NO ==================================================== Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com> Change-Id: I584ac4b045ba80998d454283e02d3f28ef45692d Reviewed-on: https://review.coreboot.org/c/coreboot/+/45088 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* util/inteltool: drop OS-specific rdmsr/wrmsr prototypesIdwer Vollering2020-11-261-2/+0
| | | | | | | | | | | | | | The previous commit (that was not touching inteltool.h) marking internal functions as static is commit 6faccd1f00 Tested on: FreeBSD 13.0-CURRENT r355582 Change-Id: I4aba72f39b528fd70451a4656fd6c835ff766e49 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37767 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* util/crossgcc: ensure curl writes downloaded bytes to a fileIdwer Vollering2020-11-251-1/+1
| | | | | | | | | | | Commit 82a30a134c (util/crossgcc: Retry package downloads on failure) caused a regression for curl users. Signed-off-by: Idwer Vollering <vidwer@gmail.com> Change-Id: I0d946b86baad3f6409a5042701808da307e5bcb7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47911 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* cbfstool: Don't add compression attribute for uncompressed filesJulius Werner2020-11-251-1/+5
| | | | | | | | | | | | | | | | Our current cbfstool has always added a compression attribute to the CBFS file header for all files that used the cbfstool_convert_raw() function (basically anything other than a stage or payload), even if the compression type was NONE. This was likely some sort of oversight, since coreboot CBFS reading code has always accepted the absence of a compression attribute to mean "no compression". This patch fixes the behavior to avoid adding the attribute in these cases. Change-Id: Ic4a41152db9df66376fa26096d6f3a53baea51de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46835 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* crossgcc: Upgrade binutils to 2.35.1Elyes HAOUAS2020-11-257-2/+2
| | | | | | | | Change-Id: I8694a154d48c5a718b27d4beb858942db0feb997 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45550 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* crossgcc: Upgrade LLVM to version 11.0.0Elyes HAOUAS2020-11-259-5/+5
| | | | | | | | Change-Id: I1cc02355e3fea7eb9ad98be6396a492dbbdc47b2 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46379 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* util/docker: Minor Makefile updatesMartin Roth2020-11-221-12/+17
| | | | | | | | | | | | | | - Update url for docker install instructions. - Update docker-cleanall target to require verification. - Update docker-jenkins-attach target to check for docker and use docker variable. - Update spaces to tabs in the docs targets. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ic1e1a545024fe1fdc37d7d8c7e6f54f124d1697b Reviewed-on: https://review.coreboot.org/c/coreboot/+/47342 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-02 00:02:16 +0000