6ddacd6f5b
The placement calculation logic in cbfs_add_component() has become quite a mess, and this patch can only fix that to a limited degree. The interaction between all the different pathways of how the `offset` variable can be set and at what point exactly the final placement offset is decided can get quite convoluted. In particular, one existing problem is that the offset for a file added with the --align flag is decided before the convert() function is called, which may change the form (and thereby the size) of the file again after its location was found -- resulting in a location that ends up being too small, or being unable to find a location for a file that should fit. This used to be okay under the assumption that forced alignment should really only be necessary for use cases like XIP where the file is directly "used" straight from its location on flash in some way, and those cases can never be compressed -- however, recent AMD platforms have started using the --align flag to meet the requirements of their SPI DMA controller and broken this assumption. This patch fixes that particular problem and hopefully eliminates a bit of the convolution by moving the offset decision point in the --align case after the convert() step. This is safe when the steps in-between (add_topswap_bootblock() and convert() itself) do not rely on the location having already been decided by --align before that point. For the topswap case this is easy, because in practice we always call it with --base-address (and as far as I can tell that's the only way it was ever meant to work?) -- so codify that assumption in the function. For convert() this mostly means that the implementations that do touch the offset variable (mkstage and FSP) need to ensure they take care of the alignment themselves. The FSP case is particularly complex so I tried to rewrite the code in a slightly more straight-forward way and clearly document the supported cases, which should hopefully make it easier to see that the offset variable is handled correctly in all of them. For mkstage the best solution seems to be to only have it touch the offset variable in the XIP case (where we know compression must be disabled, so we can rely on it not changing the file size later), and have the extra space for the stage header directly taken care of by do_cbfs_locate() so that can happen after convert(). NOTE: This is changing the behavior of `cbfstool add -t fsp` when neither --base-address nor --xip are passed (e.g. FSP-S). Previously, cbfstool would implicitly force an alignment of 4K. As far as I can tell from the comments, this is unnecessary because this binary is loaded into RAM and CBFS placement does not matter, so I assume this is an oversight caused by accidentally reusing code that was only meant for the XIP case. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ia49a585988f7a74944a6630b77b3ebd79b3a9897 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59877 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <patrick@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> |
||
|---|---|---|
| 3rdparty | ||
| configs | ||
| Documentation | ||
| LICENSES | ||
| payloads | ||
| spd | ||
| src | ||
| tests | ||
| util | ||
| .checkpatch.conf | ||
| .clang-format | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| .gitreview | ||
| AUTHORS | ||
| COPYING | ||
| gnat.adc | ||
| MAINTAINERS | ||
| Makefile | ||
| Makefile.inc | ||
| README.md | ||
| toolchain.inc | ||
coreboot README
coreboot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload.
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like PC BIOS services or UEFI. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.
coreboot was formerly known as LinuxBIOS.
Payloads
After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot.
See https://www.coreboot.org/Payloads for a list of supported payloads.
Supported Hardware
coreboot supports a wide range of chipsets, devices, and mainboards.
For details please consult:
Build Requirements
- make
- gcc / g++
Because Linux distribution compilers tend to use lots of patches. coreboot
does lots of "unusual" things in its build system, some of which break due
to those patches, sometimes by gcc aborting, sometimes - and that's worse -
by generating broken object code.
Two options: use our toolchain (eg. make crosstools-i386) or enable the
ANY_TOOLCHAINKconfig option if you're feeling lucky (no support in this case). - iasl (for targets with ACPI support)
- pkg-config
- libssl-dev (openssl)
Optional:
- doxygen (for generating/viewing documentation)
- gdb (for better debugging facilities on some targets)
- ncurses (for
make menuconfigandmake nconfig) - flex and bison (for regenerating parsers)
Building coreboot
Please consult https://www.coreboot.org/Build_HOWTO for details.
Testing coreboot Without Modifying Your Hardware
If you want to test coreboot without any risks before you really decide to use it on your hardware, you can use the QEMU system emulator to run coreboot virtually in QEMU.
Please see https://www.coreboot.org/QEMU for details.
Website and Mailing List
Further details on the project, a FAQ, many HOWTOs, news, development guidelines and more can be found on the coreboot website:
You can contact us directly on the coreboot mailing list:
https://www.coreboot.org/Mailinglist
Copyright and License
The copyright on coreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details.
coreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details.
This makes the resulting coreboot images licensed under the GPL, version 2.