summaryrefslogtreecommitdiffstats
path: root/util/cbfstool
Commit message (Collapse)AuthorAgeFilesLines
* util/cbfstool/.gitignore: Add CSE tool executablesAngel Pons2021-11-291-0/+2
| | | | | | | | | | | | | | | | | | | | Commit 796aeeba96fc (util/cse_fpt: Add a new tool for managing Intel CSE FPT binaries) and commit d7fb6a90e1d0 (util/cse_serger: Add a new tool for stitching CSE components) add two utilities, and building cbfstool also generates executables for them. When building cbfstool standalone, these executables are placed in `util/cbfstool/`, and Git should never track them. Specify these executables' file names in .gitignore in order to prevent unintentional inclusion of these files in commits, which is very likely to happen when using `git add` on directories. Change-Id: I285a4d7aeee642822eaae2eb69e5d52efb4bc8c0 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59670 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool/flashmap/fmap.c: fix fmaptool endianness bugs on BEMarek Kasiewicz2021-11-221-32/+33
| | | | | | | | | | | | | This patch makes all accesses to the FMAP fields explicitly little endian. It fixes issue where build on BE host produced different binary image than on LE. Signed-off-by: Marek Kasiewicz <marek.kasiewicz@3mdeb.com> Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Change-Id: Ia88c0625cefa1e594ac1849271a71c3aacc8ce78 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55039 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* eventlog: Add a log type for Chrome OS diagnosticsHsuan Ting Chen2021-11-221-0/+10
| | | | | | | | | | | | | | | | Add events for Chrome OS diagnostics in eventlog tool: * ELOG_TYPE_CROS_DIAGNOSTICS(0xb6): diagnostics-related events * ELOG_CROS_LAUNCH_DIAGNOSTICS(0x01): sub-type for diagnostics boot These events are not added anywhere currently. They will be added in another separate commit. Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Change-Id: I1b67fdb46f64db33f581cfb5635103c9f5bbb302 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58795 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
* elogtool: add pytest for elogtoolRicardo Quesada2021-10-253-0/+188
| | | | | | | | | | | | | | | | This CL adds a python test for elogtool. It tests the basic functionality of elogtool: list, clear and add. A future CL will include more complex tests. BUG=b:172210863 TEST=pytest elogtool_test.py Change-Id: If1241ad070d1c690c84f5ca61c0487ba27c2a287 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57869 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* util/cbfstool/rmodule: Omit undefined extern symbols from reloc tableRaul E Rangel2021-10-201-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using `DECLARE_OPTIONAL_REGION`, it is assumed that REGION_SIZE(name) == 0 if the region was not defined in the memlayout. When using non-rmodule stages (i.e., bootblock, romstage, etc), this assumption holds true, but breaks down in rmodule (i.e., ramstage) stages. The rmodule tool is not currently omitting undefined externals from the relocation table. e.g., extern u8 _##name##_size[]; This means that when the rmodule loader runs, it will rewrite the symbol from 0 (which is the default the linker assumed) to 0 + offset. This is wrong since the symbol doesn't actually exist. Instead we need to omit the relocation so it continues to keep the default value of 0. BUG=b:179699789 TEST=Print out REGION_SIZE(cbfs_cache) in ramstage and verify it is set to 0. I also see the following printed by the rmodtool now: DEBUG: Omitting relocation for undefined extern: _watchdog_tombstone_size DEBUG: Omitting relocation for undefined extern: _watchdog_tombstone DEBUG: Omitting relocation for undefined extern: _watchdog_tombstone DEBUG: Omitting relocation for absolute symbol: _stack_size DEBUG: Omitting relocation for absolute symbol: _program_size DEBUG: Omitting relocation for absolute symbol: _cbmem_init_hooks_size DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache_size DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache_size DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache DEBUG: Omitting relocation for undefined extern: _cbfs_cache DEBUG: Omitting relocation for undefined extern: _cbfs_cache_size As you can see the _watchdog_tombstone will also be fixed by this CL. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ib57e263fa9014da4f6854637000c1c8ad8eb351a Reviewed-on: https://review.coreboot.org/c/coreboot/+/58376 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
* util/cse_serger: Add command `create-cse-region`Furquan Shaikh2021-10-191-0/+100
| | | | | | | | | | | | | | This change adds a new command `create-cse-region` to cse_serger tool which takes as inputs offset:size and file for different CSE partitions and generates the entire CSE region image. BUG=b:189177186 Change-Id: Ib087f5516e5beb6390831ef4e34b0b067d3fbc8b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58215 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* util/cse_serger: Replace cse_layout_regions with array of regionsFurquan Shaikh2021-10-194-38/+49
| | | | | | | | | | | | | | This change replaces `struct cse_layout_regions` with an array of `struct region` and introduces enums for DP and BP[1-4]. This makes it easier to loop over the different regions in following changes. BUG=b:189177186 Change-Id: If3cced4506d26dc534047cb9c385aaa9418d8522 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58214 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* util/cse*: Add cse_helpers.{c,h}Furquan Shaikh2021-10-197-84/+76
| | | | | | | | | | | | | | This change moves `read_member` and `write_member` helper functions out of cse_fpt.c and cse_serger.c into cse_helpers.c to avoid duplication. BUG=b:189177186,b:189167923 Change-Id: I7b646b29c9058d892bb0fc9824ef1b4340d2510c Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58201 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* util/cse_serger: Add a new tool for stitching CSE componentsFurquan Shaikh2021-10-1910-2/+1957
| | | | | | | | | | | | | This change adds a new tool `cse_serger` which can be used to print, dump and stitch together different components for the CSE region. BUG=b:189177186 Change-Id: I90dd809b47fd16afdc80e66431312721082496aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55503 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* util/cse_fpt: Add a new tool for managing Intel CSE FPT binariesFurquan Shaikh2021-10-197-2/+715
| | | | | | | | | | | | | This change adds a new tool `cse_fpt` which can be used to print and dump CSE partitions in Flash Partition Table (FPT) format. BUG=b:189167923 Change-Id: I93c8d33e9baa327cbdab918a14f2f7a039953be6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* cbfstool: Add helper function `buffer_from_file_aligned_size`Furquan Shaikh2021-10-182-3/+18
| | | | | | | | | | | | | | | This change adds a helper function `buffer_from_file_aligned_size` that loads a file into memory buffer by creating a memory buffer of size rounded up to the provided `size_granularity` parameter. BUG=b:189177186,b:189167923 Change-Id: Iad3430d476abcdad850505ac50e36cd5d5deecb4 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55989 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* util/cbfstool: Add support for ARM64 UefiPayloadRex-BC Chen2021-10-042-2/+3
| | | | | | | | | | | | | UEFI payload is supported on some ARM64 platforms, for example MT8195. As a result, add MACHINE_TYPE_ARM64 to support ARM SystemReady. Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Change-Id: I4c0c6e263bd2f518a62ff9db44d72dd31086756a Reviewed-on: https://review.coreboot.org/c/coreboot/+/58055 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* elogtool: Fix off-by-one error in month in timestampRicardo Quesada2021-09-241-1/+2
| | | | | | | | | | | | | | | | elogtool was setting the timestamp with the wrong value in the month. This CL fixes that by incrementing the month by one. This is needed since gmtime() returns the month value starting at 0. TEST=pytest elogtool_test.py (see next CL in relation chain) Change-Id: I00f89ed99b049caafba2e47feae3c068245f9021 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57868 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
* elogtool: compile in 32-bit platformsRicardo Quesada2021-09-211-2/+2
| | | | | | | | | | | | | | | | | | This CL fixes a compilation error that happens in 32-bit platforms. This error happens because printf() was using %ld instead of %zu to print size_t variables. This CL fixes it. BUG=b:200608182 TEST=emerge-kevin (ARM 32-bit) TEST=emerge-eve (Intel 64-bit) Change-Id: I340e108361c052601f2b126db45caf2e35ee7ace Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57792 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
* elogtool: add "add" commandRicardo Quesada2021-09-161-3/+181
| | | | | | | | | | | | | | | | | | | Adds "add" command to elogtool. This command allows adding elog events manually. It supports event type and, optionally, event data. If the free buffer space is < 1/4 of the total space, it shrinks the buffer, making sure that ~1/4 of the free space is available. BUG=b:172210863 TEST=./elogtool add 0x17 0101 ./elogtool add 0x18 Repeated the same tests on buffers that needed to be shrunk. Change-Id: Ia6fdf4f951565f842d1bff52173811b52f617f66 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57397 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* elogtool: add next_available_event_offset functionRicardo Quesada2021-09-161-22/+32
| | | | | | | | | | | | | | | | | | | This function is "extracted" from cmd_clear(). This new function will be called from cmd_add(), and new command that will be added in a future CL (see CL chain). Additional minor fixes: - calls usage() if no valid commands are passed. - Slightly improves usage() output. Needed for cmd_clear() BUG=b:172210863 TEST=elogtool clear Change-Id: I0d8ecc893675758d7f90845282a588d367b55567 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57395 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* elogtool: add "clear" commandRicardo Quesada2021-09-103-45/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds "clear" command to cbfsutil/elogtool tool. "clear" clears the RW_ELOG region by using either: * flashrom if no file is provided * or using file write if an input file is provided. The region is filled with ELOG_TYPE_EOL. And a ELOG_TYPE_LOG_CLEAR event is inserted. Additionally, it does a minor cleanup to command "list", like: * use buffer_end() * add "list" to the cmds struct * and make elog_read() very similar to elog_write() Usage: $ elogtool clear BUG=b:172210863 TEST=elogtool clear && elogtool list elogtool clear -f invalid.raw elogtool clear -f valid.raw Change-Id: Ia28a6eb34c82103ab078a0841b022e2e5e430585 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56883 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* util/cbftool: Fix the bug in parsing Uefipayload with extended headerDun Tan2021-09-022-0/+12
| | | | | | | | | | | | | | | | | | | | The patch is to fix "Not a usable UEFI firmware volume" issue when creating CBFS/flash image. This issue is caused by adding FvNameGuid in UefiPayloadEntry.fdf in EDKII. There is an ext header between header of Fv and header of PayloadEntry in Fv with FvNameGuid. The ext header causes the UefiPayloadEntry to be found incorrectly when parsing Fv. Commit in EDKII: 4bac086e8e007c7143e33f87bb96238326d1d6ba Bugzila: https://bugzilla.tianocore.org/show_bug.cgi?id=3585 Signed-off-by: Dun Tan <dun.tan@intel.com> Change-Id: Id063efb1c8e6c7a96ec2182e87b71c7e8b7b6423 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57296 Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: King Sumo <kingsumos@gmail.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* cbfstool: add buffer_end() to common.hRicardo Quesada2021-08-311-0/+5
| | | | | | | | | | | | | | | Add buffer_end() function to common.h. This function returns a pointer to the end of the buffer (exclusive). This is needed by elogtool util. (See the next CL in the chain). BUG=b:172210863 Change-Id: I380eecbc89c13f5fe5ab4c31d7a4fef97690a791 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56987 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* elogtool: add to gitignoreJack Rosenthal2021-08-091-0/+1
| | | | | | | | | | | | Add the binary output of the new elogtool to the .gitignore, so that running "make -C util/cbfstool" keeps the tree clean. Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Change-Id: I806338a4b33abbc3d55e4edef2736c19d56fa005 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56864 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ricardo Quesada <ricardoq@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
* util/elogtool: add tool to print elog eventsRicardo Quesada2021-08-055-2/+827
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new tool that that prints elog events. The tool, as input, accepts either a file with the RW_ELOG contents, or if the file is not provided it reads the contents of RW_ELOG by calling the "flashrom" tool. The tool is based on "mosys eventlog list"[1]. For the moment it only supports "list", but future commits will add additional functionality. This commit also adds missing ELOG defines needed for the tool. These defines are added with the rest of the ELOG defines, in include/commonlib/bsd/elog.h The tool is placed inside util/cbfstool. The rationale behind the decision, is that this tool shares a lot in common with the other tools located in cbfstool: vboot dependency, shared files like common.o and valstr.o, and in spirit is similar to some of the tools located in cbfstool/. As an example, you call the tool like the following: $ elogtool list -f rw_elog_dump.bin [1]: https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/lib/eventlog/elog.c BUG=b:172210863 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Change-Id: Ia1fe1c9ed3c4c6bda846055d4b10943b54463935 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56406 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* util/cbfstool: Remove unused pagesize parameterArthur Heymans2021-07-171-18/+5
| | | | | | | | Change-Id: Ib672ba8ed418b1a76e4a48951eabda6923358e7a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55581 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool: Allow setting alignment for payloadRaul E Rangel2021-07-021-1/+1
| | | | | | | | | | | | | | | | | The -a flag was already implemented, it just wasn't exposed for the add-payload command. Setting the alignment of the payload will enable using the SPI DMA controller to read the payload on AMD devices. BUG=b:179699789 TEST=cbfstool foo.bin add-payload -a 64 ... Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I9f4aea5f0cbeaa8e761212041099b37f4718ac39 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55973 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
* cbfstool/cbfs-mkstage.c: Change signature of parse_elf_to_xip_stage()Arthur Heymans2021-07-013-4/+4
| | | | | | | | | | | The dereferced parameter is never updated so passing a copy would work too. Change-Id: Ie36f64f55d4fc7034780116c28aaed65aa304d5e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55792 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* cbfstool: Unset ${DEBUG} when making vboot hostlibNico Huber2021-06-261-0/+1
| | | | | | | | | | | | | | | Vboot's Makefile is controlled by a ${DEBUG} environment variable. As the name is very generic, it may be set by accident without any intention to change the build. Having it set would break reproduci- bility at least but it also turns out that the hostlib build would be incomplete so that linking cbfstool fails due to internal calls to vb2api_fail() which is not built in. Change-Id: I2a9eb9a645c70451a320c455b8f24bfed197117c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55764 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* cbfstool: Make use of spurious null-terminationNico Huber2021-06-251-4/+4
| | | | | | | | | | | | | | | | | | | | The null-termination of `filetypes` was added after the code was written, obviously resulting in NULL dereferences. As some more code has grown around the termination, it's hard to revert the regression, so let's update the code that still used the array length. This fixes commit 7f5f9331d1 (util/cbfstool: fix buffer over-read) which actually did fix something, but only one path while it broke two others. We should be careful with fixes, they can always break something else. Especially when a dumb tool triggered the patching it seems likely that fewer people looked into related code. Change-Id: If2ece1f5ad62952ed2e57769702e318ba5468f0c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55763 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* treewide: Disable R_AMD64_32S relocation supportPatrick Rudolph2021-06-151-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a hard to debug hang that could occur in any stage, but in the end it follows simple rules and is easy to fix. In long mode the 32bit displacement addressing used on 'mov' and 'lea' instructions is sign-extended. Those instructions can be found using readelf on the stage and searching for relocation type R_X86_64_32S. The sign extension is no issue when either running in protected mode or the code module and thus the address is below 2GiB. If the address is greater than 2GiB, as usually the case for code in TSEG, the higher address bits [64:32] are all set to 1 and the effective address is pointing to memory not paged. Accessing this memory will cause a page fault, which isn't handled either. To prevent such problems - disable R_AMD64_32S relocations in rmodtool - add comment explaining why it's not allowed - use the pseudo op movabs, which doesn't use 32bit displacement addressing - Print a useful error message if such a reloc is present in the code Fixes a crash in TSEG and when in long mode seen on Intel Sandybridge. Change-Id: Ia5f5a9cde7c325f67b12e3a8e9a76283cc3870a3 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55448 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* util/cbfstool/linux_trampoline.h: Fix typo in commentAngel Pons2021-06-041-1/+1
| | | | | | | | | | | | inlucde ---> include Change-Id: I38987119ddabb08c457c9a7c8aecb8025fe2d9d3 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55161 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* cbfstool/linux_trampoline.S: Fix up the e820 tableArthur Heymans2021-06-022-6/+21
| | | | | | | | | | | | | | | The e820 type don't fully match the LB_TAG_MEMORY types, so change all unknown types to e820 to '2', reserved memory. TESTED with Linuxboot: e820 now shows the CBMEM region as reserved. Change-Id: Ie0e41c66e002919e41590327afe0f543e0037369 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55074 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Rocky Phagura Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool/Makefile: Check out vboot before trying to use itPatrick Georgi2021-06-011-0/+5
| | | | | | | | | | Change-Id: Ie2044d73b97663f7816964c4d908a46570aafdbc Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55072 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Idwer Vollering <vidwer@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* util/cbfstool/fit.c: Fix getting the topswap tableArthur Heymans2021-05-271-13/+1
| | | | | | | | | | | | | There is a function to fetch the fit table at both the regular address and the TS address. So reuse that function instead of attempting to find the TS fit using some pointer aritmetics that is incorrect. Change-Id: I9114f5439202ede7e01cd0fcbb1e3c4cdb8698b0 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54680 Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-by: Meera Ravindranath <meera.ravindranath@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool: Do not set -D_XOPEN_SOURCE on FreeBSDIdwer Vollering2021-05-101-1/+4
| | | | | | | | | | | | | | Fixes compilation on FreeBSD CURRENT, and possibly other releases. The compiler, clang, complained about: util/cbfstool/cbfstool.c:181:40: error: implicit declaration of function 'memmem' is invalid in C99 [-Werror,-Wimplicit-function-declaration] util/cbfstool/cbfstool.c:181:31: error: incompatible integer to pointer conversion initializing 'struct metadata_hash_anchor *' with an expression of type 'int' [-Werror,-Wint-conversion] Signed-off-by: Idwer Vollering <vidwer@gmail.com> Change-Id: I45c02a21709160df44fc8da329f6c4a9bad24478 Reviewed-on: https://review.coreboot.org/c/coreboot/+/53996 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/ifittool: Add an option to set the FIT pointer a CBFS fileArthur Heymans2021-03-193-30/+105
| | | | | | | | | | | | | | | | | The purpose of this is to eventually move the FIT table out of the bootblock, generate it separately as a cbfs file and then have the FIT pointer point to that cbfs file. TESTED: extracted a FIT table using dd, added it as a cbfs file and see that the FIT pointer correctly points to it. Also test that trying to add a non valid FIT cbfs file results in an error. Change-Id: I6e38b7df31e6b30f75b0ae57a5332f386e00f16b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50925 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
* cbfs: Move stage header into a CBFS attributeJulius Werner2021-03-175-229/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CBFS stage header is part of the file data (not the header) from CBFS's point of view, which is problematic for verification: in pre-RAM environments, there's usually not enough scratch space in CBFS_CACHE to load the full stage into memory, so it must be directly loaded into its final destination. However, that destination is decided from reading the stage header. There's no way we can verify the stage header without loading the whole file and we can't load the file without trusting the information in the stage header. To solve this problem, this patch changes the CBFS stage format to move the stage header out of the file contents and into a separate CBFS attribute. Attributes are part of the metadata, so they have already been verified before the file is loaded. Since CBFS stages are generally only meant to be used by coreboot itself and the coreboot build system builds cbfstool and all stages together in one go, maintaining backwards-compatibility should not be necessary. An older version of coreboot will build the old version of cbfstool and a newer version of coreboot will build the new version of cbfstool before using it to add stages to the final image, thus cbfstool and coreboot's stage loader should stay in sync. This only causes problems when someone stashes away a copy of cbfstool somewhere and later uses it to try to extract stages from a coreboot image built from a different revision... a debugging use-case that is hopefully rare enough that affected users can manually deal with finding a matching version of cbfstool. The SELF (payload) format, on the other hand, is designed to be used for binaries outside of coreboot that may use independent build systems and are more likely to be added with a potentially stale copy of cbfstool, so it would be more problematic to make a similar change for SELFs. It is not necessary for verification either, since they're usually only used in post-RAM environments and selfload() already maps SELFs to CBFS_CACHE before loading them to their final destination anyway (so they can be hashed at that time). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8471ad7494b07599e24e82b81e507fcafbad808a Reviewed-on: https://review.coreboot.org/c/coreboot/+/46484 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cbfstool: Move alignment/baseaddress handling into cbfs_add_component()Julius Werner2021-03-161-60/+57
| | | | | | | | | | | | | | | | | | | The --alignment flag is currently only handled by cbfstool add, but there seems little reason to not handle it for all file-adding commands (the help text actually mentions it for add-stage as well but it doesn't currently work there). This patch moves the related code (and the related baseaddress handling) into cbfs_add_component(). As a nice side effect this allows us to rearrange cbfs_add_component() such that we can conclusively determine whether we need a hash attribute before trying to align the file, allowing that code to correctly infer the final header size even when a hash attribute was implicitly added (for an image built with CBFS verification enabled). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Idc6d68b2c7f30e5d136433adb3aec5a87053f992 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47823 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool/ifittool: Remove dead codeArthur Heymans2021-03-161-30/+0
| | | | | | | | | | The 'x' option is not set up in the getopt options. Change-Id: Ib4aa10b0ea2a3f97e8d2439152b708613bcf43db Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50923 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* cbfstool: Add support for platform "fixups" when modifying bootblockJulius Werner2021-03-135-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support the new CONFIG_CBFS_VERIFICATION feature, cbfstool needs to update the metadata hash embedded in the bootblock code every time it adds or removes a CBFS file. This can lead to problems on certain platforms where the bootblock needs to be specially wrapped in some platform-specific data structure so that the platform's masked ROM can recognize it. If that data structure contains any form of hash or signature of the bootblock code that is checked on every boot, it will no longer match if cbfstool modifies it after the fact. In general, we should always try to disable these kinds of features where possible (they're not super useful anyway). But for platforms where the hardware simply doesn't allow that, this patch introduces the concept of "platform fixups" to cbfstool. Whenever cbfstool finds a metadata hash anchor in a CBFS image, it will run all built-in "fixup probe" functions on that bootblock to check if it can recognize it as the wrapper format for a platform known to have such an issue. If so, it will register a corresponding fixup function that will run whenever it tries to write back modified data to that bootblock. The function can then modify any platform-specific headers as necessary. As first supported platform, this patch adds a fixup for Qualcomm platforms (specifically the header format used by sc7180), which recalculates the bootblock body hash originally added by util/qualcomm/createxbl.py. (Note that this feature is not intended to support platform-specific signature schemes like BootGuard directly in cbfstool. For anything that requires an actual secret key, it should be okay if the user needs to run a platform-specific signing tool on the final CBFS image before flashing. This feature is intended for the normal unsigned case (which on some platforms may be implemented as signing with a well-known key) so that on a board that is not "locked down" in any way the normal use case of manipulating an image with cbfstool and then directly flashing the output file stays working with CONFIG_CBFS_VERIFICATION.) Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I02a83a40f1d0009e6f9561ae5d2d9f37a510549a Reviewed-on: https://review.coreboot.org/c/coreboot/+/41122 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* cbfstool: Support CONFIG_CBFS_VERIFICATION and metadata hash anchorJulius Werner2021-03-134-18/+261
| | | | | | | | | | | | | | | | | | This patch adds support for the new CONFIG_CBFS_VERIFICATION feature to cbfstool. When CBFS verification is enabled, cbfstool must automatically add a hash attribute to every CBFS file it adds (with a handful of exceptions like bootblock and "header" pseudofiles that are never read by coreboot code itself). It must also automatically update the metadata hash that is embedded in the bootblock code. It will automatically find the metadata hash by scanning the bootblock for its magic number and use its presence to auto-detect whether CBFS verification is enabled for an image (and which hash algorithm to use). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I61a84add8654f60c683ef213b844a11b145a5cb7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41121 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/cbfstool: Update MakefilesMartin Roth2021-02-252-2/+14
| | | | | | | | | | | | | - Add a distclean target - Add a help target - Add the -Wshadow option Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ie31d61bd0e28b1e228656dfa09b5ab1996868706 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50848 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* cbfstool: Replace FILENAME_ALIGN 16 with ATTRIBUTE_ALIGN 4Julius Werner2021-02-182-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cbfstool has always had a CBFS_FILENAME_ALIGN that forces the filename field to be aligned upwards to the next 16-byte boundary. This was presumably done to align the file contents (which used to come immediately after the filename field). However, this hasn't really worked right ever since we introduced CBFS attributes. Attributes come between the filename and the contents, so what this code currently does is fill up the filename field with extra NUL-bytes to the boundary, and then just put the attributes behind it with whatever size they may be. The file contents don't end up with any alignment guarantee and the filename field is just wasting space. This patch removes the old FILENAME_ALIGN, and instead adds a new alignment of 4 for the attributes. 4 seems like a reasonable alignment to enforce since all existing attributes (with the exception of weird edge cases with the padding attribute) already use sizes divisible by 4 anyway, and the common attribute header fields have a natural alignment of 4. This means file contents will also have a minimum alignment guarantee of 4 -- files requiring a larger guarantee can still be added with the --alignment flag as usual. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I43f3906977094df87fdc283221d8971a6df01b53 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47827 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cbfstool: Ensure attributes always come last in the metadataJulius Werner2021-02-181-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a rare placement edge case when adding a file with alignment requirements, cbfstool may need to generate a CBFS header that's slightly larger than it needs to be. The way we do this is by just increasing the data offset field in the CBFS header until the data falls to the desired value. This approach works but it may confuse parsing code in the presence of CBFS attributes. Normally, the whole area between the attribute offset and the data offset is filled with valid attributes written back to back, but when this header expansion occurs the attributes are followed by some garbage data (usually 0xff). Parsers are resilient against this but may show unexpected error messages. This patch solves the problem by moving the attribute offset forwards together with the data offset, so that the total area used for attributes doesn't change. Instead, the filename field becomes the expanded area, which is a closer match to how this worked when it was originally implemented (before attributes existed) and is less confusing for parsers since filenames are zero-terminated anyway. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I3dd503dd5c9e6c4be437f694a7f8993a57168c2b Reviewed-on: https://review.coreboot.org/c/coreboot/+/47824 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cbfstool: Remove location pointer from parse_elf_to_stage()Julius Werner2021-02-183-26/+9
| | | | | | | | | | | | | | | | | | | The *location argument to parse_elf_to_stage() is a relic from code all the way back to 2009 where this function was still used to parse XIP stages. Nowadays we have a separate parse_elf_to_xip_stage() for that, so there is no need to heed XIP concerns here. Having a pointer to represent the location in flash is absolutely irrelevant to a non-XIP stage, and it is used incorrectly -- we just get lucky that no code path in cbfstool can currently lead to that value being anything other than 0, otherwise the adjustment of data_start to be no lower than *location could easily screw things up. This patch removes it. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ia7f850c0edd7536ed3bef643efaae7271599313d Reviewed-on: https://review.coreboot.org/c/coreboot/+/49369 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* rmodtool: Make memlayout symbols absolute and do not relocate themJulius Werner2021-02-182-29/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Memlayout is a mechanism to define memory areas outside the normal program segment constructed by the linker. Therefore, it generally doesn't make sense to relocate memlayout symbols when the program is relocated. They tend to refer to things that are always in one specific spot, independent of where the program is loaded. This hasn't really hurt us in the past because the use case we have for rmodules (ramstage on x86) just happens to not really need to refer to any memlayout-defined areas at the moment. But that use case may come up in the future so it's still worth fixing. This patch declares all memlayout-defined symbols as ABSOLUTE() in the linker, which is then reflected in the symbol table of the generated ELF. We can then use that distinction to have rmodtool skip them when generating the relocation table for an rmodule. (Also rearrange rmodtool a little to make the primary string table more easily accessible to the rest of the code, so we can refer to symbol names in debug output.) A similar problem can come up with userspace unit tests, but we cannot modify the userspace relocation toolchain (and for unfortunate historical reasons, it tries to relocate even absolute symbols). We'll just disable PIC and make those binaries fully static to avoid that issue. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ic51d9add3dc463495282b365c1b6d4a9bf11dbf2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50629 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* treewide: Remove trailing whitespaceMartin Roth2021-02-172-42/+42
| | | | | | | | | | Remove trailing whitespace in files that aren't typically checked. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I8dfffbdeaadfa694fef0404719643803df601065 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50704 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* util/cbfstool: Fix build in 32-bit userspaceKyösti Mälkki2021-02-141-1/+2
| | | | | | | | | | | | | | | | | | | Fix regression from commit 0dcc0662f3 util/cbfstool: Introduce concept of mmap_window. Use of region_end() wraps around at 4 GiB, if utility is run in 32bit userspace. The build completes with an invalid coreboot.rom, while one can find error message in stdout or make.log: E: Host address(ffc002e4) not in any mmap window! Change-Id: Ib9b6b60c7b5031122901aabad7b3aa8d59f1bc68 Signed-off-by: Furquan Shaikh <furquan@google.com> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50618 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* 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>
* 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>
* 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>
* 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>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-02 05:35:13 +0000