Age | Commit message (Collapse) | Author |
|
Change-Id: I7dd7b0b7c5fdb63fe32915b88e69313e3440b64a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80587
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It seems that we have some applications where we need to calculate a GCD
in 64 bits. Now, we could instantiate the algorithm multiple times for
different bit width combinations to be able to use the most efficient
one for each problem... but considering that the function usually only
gets called once per callsite per stage, and that software emulation of
64-bit division on 32-bit systems doesn't take *that* long either, we
would probably usually be paying more time loading the second instance
of the function than we save with faster divisions. So let's just make
things easy and always do it in 64-bit and then nobody has to spend time
thinking on which version to call.
Change-Id: I028361444c4048a0d76ba4f80c7334a9d9983c87
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80319
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
|
|
In case printk does not work the current exception handler will print a
simple "!" to notify the developer that coreboot is actually there but
something went wrong.
The "!" can be quite confusing when it actually happens that printk does
not work. Since "!" doesn't really say much (if you don't know the
exception arm64 code) the developer (like me) can easily assume that
something went wrong while configuring clocks or baud rate of UART,
since the output seemingly does not seem to make sense.
This adds a little bit more output to assure the developer that what was
printed was actually intended to be printed. Therefore it prints
"EXCEPT" which assures the developer that this was intended output.
It also adds a comment above so that developer can more easily grep
for this message.
It has intentionally not been written as:
```
const char *msg = "\r\n!EXCPT!";
while (*msg)
__uart_tx_byte(*msg++);
```
because in this case the compiler will generate code that will place
`msg` somewhere in bootblock and the code will try to access this using
a memory address. In rare cases (if you link bootblock at the wrong
address) this memory address can be wrong and coreboot will not print
the message. Using individual calls to `__uart_tx_byte` ensures that the
compiler will generate code which directly puts the character bytes into
the argument register without referencing a variable in bootblock.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2f858730469fff3cae120fd7c32fec53b3d309ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ieaf7894f49a90f562b164924cc025e3eab5a3f7f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ice5dadd3eaadfa9962225520a3a75b05b44518ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80066
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
When preprocessing the linker script the target arch needs to be
specified.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Id18af3da93d2d06a2ebb83eddd03377c9026c8fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
With the update to GCC 13 a new warning about subtracting numbers from
arrays appears.
src/arch/arm64/armv8/mmu.c:296:9: error: array subscript -1 is outside array bounds of 'u8[]' {aka 'unsigned char[]'} [-Werror=array-bounds=]
Change-Id: I4757ca2e7ad3f969d7416041ea40c3e9866cdf49
Signed-off-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79014
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia005915a05d02725f77b52ccd7acebefaf25d058
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78964
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The value from raw_read_cntfrq_el0() could be large enough to cause
overflow when multiplied by USECS_PER_SEC. To prevent this, both
USECS_PER_SEC and tfreq can be reduced by dividing them by their GCD.
BUG=b:307790895
TEST=emerge-geralt coreboot
TEST=boot to kernel and check the timestamps from `cbmem`
Change-Id: I366667de05392913150414f0fa9058725be71c52
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78800
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is required for compliant ACPI/SMBIOS implementations on AArch64,
and can optionally be displayed to the user.
Change-Id: I7022fc3c0035208bc3fdc716fc33f6b78d8e74fc
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
CONFIG_HAVE_ACPI_SUPPORT does not exist. Replace it with
HAVE_ACPI_TABLES.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icc7c00dc19cae4be13e6c8cc0084a69aed8fb8f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
Linux v6.3.5 is able to detect and use ACPI tables on an out of tree
target using hacked version of u-boot to pass ACPI through UEFI.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4f60c546ec262ffb4d447fe6476844cf5a1b756d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76071
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Change-Id: I0cba99070f251d86679c068bb737c05178f4a7c5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77771
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Arm needs very little of FADT. Just a HW reduced model bit and low power
idle bit set.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I197975f91cd47e418c8583cb0e7b7ea2330363b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76180
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I93860a20a425c833b41e16347722e9a879f83ab1
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76202
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
The linter requests spaces around colons. Add them.
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Change-Id: I46d11666126dd8585ef7d4bab68a5b4b01fb7c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73748
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Coding style requires a space before the question mark in ternary
operators. Fix that.
Found by the linter.
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Change-Id: I894d6efd5673e9ad5f166ae59967a8d4bb42fb06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72484
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It is no longer necessary to explicitly add "CRIT: " in front of
BIOS_CRIT message.
Change-Id: I506c1d278960c91d1283e9b1936c9c1678a10e17
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Change-Id: Ic4ce44865544c94c39e8582780a7eca7876f5c38
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The header file `rules.h` is automatically included in the build by the
top level makefile using the command:
`-include src/soc/intel/common/block/scs/early_mmc.c`.
Similar to `config.h` and 'kconfig.h`, this file does not need to be
included manually, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I23a1876b4b671d8565cf9b391d3babf800c074db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67348
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Prepare platforms for linking romstage code in the bootblock.
Change-Id: Ic20799b4d6e3f62cd05791a2bd275000a12cc83c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Ibcbaa39ee3922e1f7add8694d8c7c491881d7124
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
Found using:
diff <(git grep -l '<cbfs.h>' -- src/) <(git grep -l 'cbfs_allocator_t\|cbfs_load\|cbfs_ro_load\|cbfs_type_load\|cbfs_ro_type_load\|cbfs_unverified_area_load\|cbfs_map\|cbfs_ro_map\|cbfs_type_map\|cbfs_ro_type_map\|cbfs_unverified_area_map\|cbfs_alloc\|cbfs_ro_alloc\|cbfs_type_alloc\|cbfs_ro_type_alloc\|cbfs_unverified_area_alloc\|cbfs_cbmem_alloc\|cbfs_ro_cbmem_alloc\|cbfs_type_cbmem_alloc\|cbfs_ro_type_cbmem_alloc\|cbfs_unverified_area_cbmem_alloc\|cbfs_preload\|cbfs_unmap\|cbfs_prog_stage_load\|cbfs_get_size\|cbfs_ro_get_size\|cbfs_get_type\|cbfs_ro_get_type\|cbfs_type\|cbfs_file_exists\|cbfs_ro_file_exists\|mem_pool\|cbfs_cache\|cbfs_boot_device\|cbfs_boot_device_find_mcache\|cbfs_boot_device\|cbfs_get_boot_device\|cbfs_init_boot_device\|cbfs_boot_lookup\|cbfs_alloc\|cbfs_unverified_area_alloc\|cbfs_default_allocator_arg\|cbfs_default_allocator\|cbfs_cbmem_allocator\|cbfs_alloc\|cbfs_ro_alloc\|cbfs_type_alloc\|cbfs_ro_type_alloc\|cbfs_unverified_area_alloc\|cbfs_map\|cbfs_ro_map\|cbfs_type_map\|cbfs_ro_type_map\|cbfs_unverified_area_map\|cbfs_load\|cbfs_type_load\|cbfs_ro_load\|cbfs_ro_type_load\|cbfs_unverified_area_load\|cbfs_cbmem_alloc\|cbfs_ro_cbmem_alloc\|cbfs_type_cbmem_alloc\|cbfs_ro_type_cbmem_alloc\|cbfs_unverified_area_cbmem_alloc\|cbfs_get_size\|cbfs_ro_get_size\|cbfs_get_type\|cbfs_ro_get_type\|cbfs_file_exists\|cbfs_ro_file_exists\|cbfs_mdata\|cbfs_find_attr\|cbfs_file_hash' -- src/)|grep "<"
Change-Id: Ib4dca6da1eb66bbba5b6e94fd623f4fcfc2f0741
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
The cpu_relax method is defined for x86. This CL adds a no-op method so
that it can be used in common code.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcb4546ceb2894eeb37589d0282b7e076d7a4747
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<clocks.h> and smp_processor_id() aren't used anywhere anymore. Get rid
of them.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1a8c892b066e6ac0e7cec5316633d44165344e78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This patch removes the prog_locate() call for all instances of loading
payload formats (SELF and FIT), as the previous patch did for stages.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I582b37f36fe6f9f26975490a823e85b130ba49a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch removes the prog_locate() step for stages and rmodules.
Instead, the stage and rmodule loading functions will now perform the
locate step directly together with the actual loading. The long-term
goal of this is to eliminate prog_locate() (and the rdev member in
struct prog that it fills) completely in order to make CBFS verification
code safer and its security guarantees easier to follow. prog_locate()
is the main remaining use case where a raw rdev of CBFS file data
"leaks" out of cbfs.c into other code, and that other code needs to
manually make sure that the contents of the rdev get verified during
loading. By eliminating this step and moving all code that directly
deals with file data into cbfs.c, we can concentrate the code that needs
to worry about file data hashing (and needs access to cbfs_private.h
APIs) into one file, making it easier to keep track of and reason about.
This patch is the first step of this move, later patches will do the
same for SELFs and other program types.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia600e55f77c2549a00e2606f09befc1f92594a3a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This will remove "ARCH_ARMV8_EXTENSION=0" from ".config" when unneeded.
Change-Id: Idd4ad67fb4a3efdb0864803f87c6b5f508fb4364
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49598
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
For arch/arm[64], the offsets to board identification strings and
CONFIG_ROM_SIZE inside .id were never really used; it was only a
convenience to have the strings appear near the start of image.
Add the same strings in an uncompressed file in CBFS.
Change-Id: I35d3312336e9c66d657d2ca619cf30fd79e18fd4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47602
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since most assembly files are no longer concatenated together
but built separately, section changes with .previous at the
end of the files have become spurious.
TEST=BUILD_TIMELESS
Change-Id: I2970eed2b114a53475ba385eec4e97bb7ae7095c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47963
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This patch enables bootblock compression on SC7180. In my tests, that
makes it boot roughly 10ms faster (which isn't much, but... might as
well take it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ibbe06eeb05347cc77395681969e6eaf1598b4260
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45855
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It seems that GCC's LTO doesn't like the way we implement
DECLARE_OPTIONAL_REGION(). This patch changes it so that rather than
having a normal DECLARE_REGION() in <symbols.h> and then an extra
DECLARE_OPTIONAL_REGION() in the C file using it, you just say
DECLARE_OPTIONAL_REGION() directly in <symbols.h> (in place and instead
of the usual DECLARE_REGION()). This basically looks the same way in the
resulting object file but somehow LTO seems to like it better.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6096207b311d70c8e9956cd9406bec45be04a4a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Change-Id: Ic86d2e6ad00cf190a2a728280f1a738486cb18c8
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44591
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Found using:
diff <(git grep -l '#include <stdint.h>' -- src/) <(git grep -l 'int8_t\|int16_t\|int32_t\|int64_t\|intptr_t\|intmax_t\|s8\|u8\|s16\|u16\|s32\|u32\|s64\|u64\|INT8_MIN\|INT8_MAX\|INT16_MIN\|INT16_MAX\|INT32_MIN\|INT32_MAX\|INT64_MIN\|INT64_MAX\|INTMAX_MIN\|INTMAX_MAX' -- src/) |grep -v vendorcode |grep '<'
Change-Id: I5e14bf4887c7d2644a64f4d58c6d8763eb74d2ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41827
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows
SoC/mainboard to provide a linker file for the platform. x86 already
provides a default memlayout.ld under src/arch/x86. With this new
Kconfig variable, it is possible for the SoC/mainboard code for x86 to
provide a custom linker file as well.
Makefile.inc is updated for all architectures to use this new Kconfig
variable instead of assuming memlayout.ld files under a certain
path. All non-x86 boards used memlayout.ld under mainboard
directory. However, a lot of these boards were simply including the
memlayout from SoC. So, this change also updates these mainboards and
SoCs to define the Kconfig as required.
BUG=b:155322763
TEST=Verified that abuild with --timeless option results in the same
coreboot.rom image for all boards.
Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>,
<stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes
each time when <types.h> is included.
Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I8a207e30a73d10fe67c0474ff11324ae99e2cec6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41360
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I6374bc2d397800d574c7a0cc44079c09394a0673
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37984
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This also drops individual copyright notices, all mentioned authors in
that part of the tree are already listed in AUTHORS.
Change-Id: Ic5eddc961d015328e5a90994b7963e7af83cddd3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Interpretation if # starts a comment inside a variable definition varies
between GNU make versions. Use a wildcard to match the first # and use
`sed` instead of `grep | cut` to avoid unbalanced quoting chars.
Tested with GNU make 4.2.1 and 4.3. Both produce the same output as
4.2.1 did before the patch.
Change-Id: Ib7c4d7323e112968d3f14ea0590b7dabc57c9c45
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch creates a new commonlib/bsd subdirectory with a similar
purpose to the existing commonlib, with the difference that all files
under this subdirectory shall be licensed under the BSD-3-Clause license
(or compatible permissive license). The goal is to allow more code to be
shared with libpayload in the future.
Initially, I'm going to move a few files there that have already been
BSD-licensed in the existing commonlib. I am also exracting most
contents of the often-needed <commonlib/helpers.h> as long as they have
either been written by me (and are hereby relicensed) or have an
existing equivalent in BSD-licensed libpayload code. I am also
relicensing <commonlib/compression.h> (written by me) and
<commonlib/compiler.h> (same stuff exists in libpayload).
Finally, I am extracting the cb_err error code definitions from
<types.h> into a new BSD-licensed header so that future commonlib/bsd
code can build upon a common set of error values. I am making the
assumption here that the enum constants and the half-sentence fragments
of documentation next to them by themselves do not meet the threshold of
copyrightability.
Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Change-Id: I79f065703b5249ca9630b06de7142bc52675076e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32820
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Over time our printk() seems to acquire more and more features... which
is nice, but it also makes it a little less robust when something goes
wrong. If the wrong global is trampled by some buffer overflow, it
suddenly doesn't print anymore. It would be nice to have at least some
way to tell that we triggered a real exception in that case.
With this patch, arm64 exceptions will print a '!' straight to the UART
before trying any of the more fancy printk() stuff. It's not much but it
should tell the difference between an exception and a hang and hopefully
help someone dig in the right direction sooner. This violates loglevels
(which is part of the point), but presumably when you have a fatal
exception you shouldn't care about that anymore.
Change-Id: I3b08ab86beaee55263786011caa5588d93bbc720
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37465
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To avoid trampling over interesting exception artifacts on the real
stack, our arm64 systems switch to a separate exception stack when
entering an exception handler. We don't want that to use up too much
SRAM so we just set it to 512 bytes. I mean it just prints a bunch of
registers, how much stack could it need, right?
Quite a bit it turns out. The whole vtxprintf() call stack goes pretty
deep, and aarch64 generally seems to be very generous with stack space.
Just the varargs handling seems to require 128 bytes for some reason,
and the other stuff adds up too. In the end the current implementation
takes 1008 bytes, so bump the exception stack size to 2K to make sure it
fits.
Change-Id: I910be4c5f6b29fae35eb53929c733a1bd4585377
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37464
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Arm CPUs have always had an odd feature that allows you to mask not only
true interrupts, but also "external aborts" (memory bus errors from
outside the CPU). CPUs usually have all of these masked after reset,
which we quickly learned was a bad idea back when bringing up the first
arm32 systems in coreboot. Masking external aborts means that if any of
your firmware code does an illegal memory access, you will only see it
once the kernel comes up and unmasks the abort (not when it happens).
Therefore, we always unmask everything in early bootblock assembly code.
When arm64 came around, it had very similar masking bits and we did the
same there, thinking the issue resolved. Unfortunately Arm, in their
ceaseless struggle for more complexity, decided that having a single bit
to control this masking behavior is no longer enough: on AArch64, in
addition to the PSTATE.DAIF bits that are analogous to arm32's CPSR,
there are additional bits in SCR_EL3 that can override the PSTATE
setting for some but not all cases (makes perfect sense, I know...).
When aborts are unmasked in PSTATE, but SCR.EA is not set, then
synchronous external aborts will cause an exception while asynchronous
external aborts will not. It turns out we never intialize SCR in
coreboot and on RK3399 it comes up with all zeroes (even the reserved-1
bits, which is super weird). If you get an asynchronous external abort
in coreboot it will silently hide in the CPU until BL31 enables SCR.EA
before it has its own console handlers registered and silently hangs.
This patch resolves the issue by also initializing SCR to a known good
state early in the bootblock. It also cleans up some bit defintions and
slightly reworks the DAIF unmasking... it doesn't actually make that
much sense to unmask anything before our console and exception handlers
are up. The new code will mask everything until the exception handler is
installed and then unmask it, so that if there was a super early
external abort we could still see it. (Of course there are still dozens
of other processor exceptions that could happen which we have no way to
mask.)
Change-Id: I5266481a7aaf0b72aca8988accb671d92739af6f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
This patch changes all existing instances of clrsetbits_leXX() to the
new endian-independent clrsetbitsXX(), after double-checking that
they're all in SoC-specific code operating on CPU registers and not
actually trying to make an endian conversion.
This patch was created by running
sed -i -e 's/\([cs][le][rt]bits\)_le\([136][624]\)/\1\2/g'
across the codebase and cleaning up formatting a bit.
Change-Id: I7fc3e736e5fe927da8960fdcd2aae607b62b5ff4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Kill off NO_GLOBAL_MIGRATION finally!
Change-Id: Ieb7d9f5590b3a7dd1fd5c0ce2e51337332434dbd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37054
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The romcc bootblock will be deprecated soon and most platforms use
C_ENVIRONMENT_BOOTBLOCK already. This patch drops the
CONFIG_C_ENVIRONMENT_BOOTBLOCK symbol and adds CONFIG_ROMCC_BOOTBLOCK
where needed.
Change-Id: I773a76aade623303b7cd95ebe9b0411e5a7ecbaf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37154
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
Kconfig became stricter on what it accepts, so accomodate before
updating to a new release.
Change-Id: I92a9e9bf0d557a7532ba533cd7776c48f2488f91
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37156
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
All targets now have the _cbmem_top_ptr symbol populated via calling
arguments or in the nvidia/tegra210 case worked around by populating
it with cbmem_top_chipset explicitly at the start of ramstage, so the
Kconfig guarding this behavior can be removed.
Change-Id: Ie7467629e58700e4d29f6e735840c22ed687f880
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36422
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
On this platform the ramstage is run on a different core so passing
cbmem_top via calling arguments is not an option. To work around this
populate _cbmem_top_ptr with cbmem_top_chipset which is also used in
romstage.
Change-Id: I8799c12705e944162c05fb7225ae21d32a2a882b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36557
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This solution is very generic and can in principle be implemented on
all arch/soc. Currently the old infrastructure to pass on information
from romstage to ramstage is left in place and will be removed in a
follow-up commit.
Nvidia Tegra will be handled in a separate patch because it has a
custom ramstage entry.
Instead trying to figure out which files can be removed from stages
and which cbmem_top implementations need with preprocessor, rename all
cbmem_top implementation to cbmem_top_romstage.
Mechanisms set in place to pass on information from rom- to ram-stage
will be replaced in a followup commit.
Change-Id: I86cdc5c2fac76797732a3a3398f50c4d1ff6647a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch uprevs the Arm Trusted Firmware submodule to the new upstream
master (commit 42cdeb930).
Arm Trusted Firmware unified a bunch of stuff related to BL31 handoff
parameters across platforms which involved changing a few names around.
This patch syncs coreboot back up with that. They also made header
changes that now allow us to directly include all the headers we need
(in a safer and cleaner way than before), so we can get rid of some
structure definitions that were duplicated. Since the version of entry
point info parameters we have been using has been deprecated in Trusted
Firmware, this patch switches to the new version 2 parameter format.
NOTE: This may or may not stop Cavium from booting with the current
pinned Trusted Firmware blob. Cavium maintainers are still evaluating
whether to fix that later or drop the platform entirely.
Tested on GOOGLE_KEVIN (rk3399).
Change-Id: I0ed32bce5585ce191736f0ff2e5a94a9d2b2cc28
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
These platforms return to romstage from FSP only after
already having torn CAR down. A copy of the entire CAR
region is available and discoverable via HOB.
Previously, CBMEM console detected on-the-fly that CAR
migration had happened and relocated cbmem_console_p
accoringlin with car_sync_var(). However, if the CAR_GLOBAL
pointing to another object inside CAR is a relative offset
instead, we have a more generic solution that can be used
with timestamps code as well.
Change-Id: Ica877b47e68d56189e9d998b5630019d4328a419
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35140
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch renames arm_tf.c and arm_tf.h to bl31.c and bl31.h,
respectively. That name is closer to the terminology used in most
functions related to Trusted Firmware, and it removes the annoying
auto-completion clash between arm64/arm_tf.c and arm64/armv8.
Change-Id: I2741e2bce9d079b1025f82ecb3bb78a02fe39ed5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Also don't define the default as this result in spurious lines in the
.config.
The only difference in config.h is on boards with the Nvidia tegra210
SOC that now select ARCH_ARM64, because its ramstage runs in that
mode. The resulting binary is identical however.
Change-Id: Iaa9cd902281e51f823717f6ea4c72e5736fefb31
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31315
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As discussed on the mailing list and voted upon, the coreboot project
is going to move the majority of copyrights out of the headers and into
an AUTHORS file. This will happen a bit at a time, as we'll be unifying
license headers at the same time.
Additional changes in this patch:
- Make sure files say that they're part of the coreboot project
- Move descriptions below the license header
Note that the file include/arch/acpi.h is a fantastic example of why
moving to the authors file is needed. Excluding the guard statements,
it has 8 lines of copyrights for 3 function declarations.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I334baab2b4311eb1bd9ce3f67f49a68e8b73630c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34606
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Register exception handlers to avoid a Synchronous External Abort
that is raised when you try to access a non-memory address on ARMv8.
An exception handler can jump over the faulting instruction.
This is the feature only for QEMU/AArch64.
Signed-off-by: Asami Doi <d0iasm.pub@gmail.com>
Change-Id: I09a306ca307ba4027d9758c3debc2e7c844c66b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Change-Id: Id8918f40572497b068509b5d5a490de0435ad50b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
There are only minimal differences between the architecture specific
stdint.h implementations, so let's tidy them up and merge them together
into a single file. In particular,
- Use 'unsigned long' for uintptr_t. This was already the case for x86
and riscv, while arm and mips used 'unsigned int', and arm64 and ppc64
used 'unsigned long long'. This change allows using a single integer
type for uintptr_t across all architectures, and brings it into
consistency with the rest of the code base, which generally uses
'unsigned long' for memory addresses anyway. This change required
fixing several assumptions about integer types in the arm code.
- Use _Bool as the boolean type. This is a specialized boolean type that
was introduced in C99, and is preferrable over hacking booleans
using integers. romcc sadly does not support _Bool, so for that we
stick with the old uint8_t.
- Drop the least and fast integer types. They aren't used
anywhere in the code base and are an unnecessary maintenance burden.
Using the standard fixed width types is essentially always better anyway.
- Drop the UINT64_C() macro. It also isn't used anywhere and doesn't
provide anything that a (uint64_t) cast doesn't.
- Implement the rest of the MIN and MAX numerical limits.
- Use static assertions to check that the integer widths are correct.
Change-Id: I6b52f37793151041b7bdee9ec3708bfad69617b2
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
ALIGN((a), b) and ALIGN_UP(a, b) needs 'helpers.h'
Change-Id: I029c7c5cbb19c7e69997b3d84f929cb61e8e2b23
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This patch makes some minor refactoring to the way the FIT parser
handles config nodes. A lot of this code was written in the dawn age of
depthcharge when its device tree library wasn't as well-stocked yet, so
some of it can be rewritten nicer with more high-level primitives.
There's no point in storing both the string name and the actual FDT node
of a FIT image node separately, since the latter also contains the
former, so remove that. Also eliminate code for the case of not having
an FDT (which makes no sense), and move some more FDT validity/compat
checking into fit_update_compat() (mostly in anticipation of later
changes).
This patch was adapted from depthcharge's http://crosreview.com/1553456
with a couple of modifications specific to coreboot's custom FIT loading
code.
Change-Id: Ia79e0fd0e1159c4aca64c453b82a0379b133350d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32870
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I37b8d5715cb6a32d4853e77098094cd5cffb9a4c
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: I4fe5771dd1ebf3d2a981dab08e98f1c018d14133
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: Ib843eb7144b7dc2932931b9e8f3f1d816bcc1e1a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/26796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Guckian
|
|
Change-Id: Ie21c390ab04adb5b05d5f9760d227d2a175ccb56
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Drop 'include <string.h>' when it is not used and
add it when it is missing.
Also extra lines removed, or added just before local includes.
Change-Id: Iccac4dbaa2dd4144fc347af36ecfc9747da3de20
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
This patch is a raw application of
find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ie32f1d43168c277be46cdbd7fbfa2445d9899689
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31699
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I9cc3dc51764f24b986434080f480932dceb8d133
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
After CL:31122, we can finally define a memory type specific for BL31,
to make sure BL31 is not loaded on other reserved area.
Change-Id: Idbd9a7fe4b12af23de1519892936d8d88a000e2c
Signed-off-by: Ting Shen <phoenixshen@google.com>
Reviewed-on: https://review.coreboot.org/c/31123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Currently, selflock_check() verifies that the binary is loaded in an
usable RAM area.
Extend its functionality so we can also check that BL31 is loaded in
a manually reserved area, and fail early if the range is not protected.
Change-Id: Iecdeedd9e8da67f73ac47d2a82e85b306469a626
Signed-off-by: Ting Shen <phoenixshen@google.com>
Reviewed-on: https://review.coreboot.org/c/31122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Does not fix 3rdparty/, *.S or *.ld or yet.
Change-Id: I66b48013dd89540b35ab219d2b64bc13f5f19cda
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/17656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Definitions of these types are arch-agnostic. Shared device
subsystem files cannot include arch/pci_ops.h for ARM
and arch/io.h for x86.
Change-Id: I6a3deea676308e2dc703b5e06558b05235191044
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Use of device_t is deprecated.
Change-Id: Ie05869901ac33d7089e21110f46c1241f7ee731f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/30047
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I89e03b6def5c78415bf73baba55941953a70d8de
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29302
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I40f8b4c7cbc55e16929b1f40d18bb5a9c19845da
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The selfboot function was changed at some point to take a parameter
which meant "check the allocated descriptors to see if they target
regions of real memory."
The region check had to be buried deep in the last step of loading since
that is where those descriptors were created and used.
An issue with the use of the parameter was that it was not possible
for compilers to easily divine whether the check code was used,
and it was hence possible for the code, and its dependencies, to be
compiled in even if never used (which caused problems for the
rampayload code).
Now that bounce buffers are gone, we can hoist the check code
to the outermost level. Further, by creating a selfload_check
and selfload function, we can make it easy for compilers
to discard unused code: if selfload_check is never called, all
the code it uses can be discarded too.
Change-Id: Id5b3f450fd18480d54ffb6e395429fba71edcd77
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/29259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch adds the new, faster architectural register accessors to
libpayload that were already added to coreboot in CB:27881. It also
hardcodes the assumption that coreboot payloads run at EL2, which has
already been hardcoded in coreboot with CB:27880 (see rationale there).
This means we can drop all the read_current/write_current stuff which
added a lot of unnecessary helpers to check the current exception level.
This patch breaks payloads that used read_current/write_current
accessors, but it seems unlikely that many payloads deal with this stuff
anyway, and it should be a trivial fix (just replace them with the
respective _el2 versions).
Also add accessors for a couple of more registers that are required to
enable debug mode while I'm here.
Change-Id: Ic9dfa48411f3805747613f03611f8a134a51cc46
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/29017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
|
|
Bounce buffers used to be used in those cases where the payload
might overlap coreboot.
Bounce buffers are a problem for rampayloads as they need malloc.
They are also an artifact of our x86 past before we had relocatable
ramstage; only x86, out of the 5 architectures we support, needs them;
currently they only seem to matter on the following chipsets:
src/northbridge/amd/amdfam10/Kconfig
src/northbridge/amd/lx/Kconfig
src/northbridge/via/vx900/Kconfig
src/soc/intel/fsp_baytrail/Kconfig
src/soc/intel/fsp_broadwell_de/Kconfig
The first three are obsolete or at least could be changed
to avoid the need to have bounce buffers.
The last two should change to no longer need them.
In any event they can be fixed or pegged to a release which supports
them.
For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the
value needed in 1999 for the 32-bit Linux kernel, the original ramstage)
to 0xe00000 (14 Mib) which will put the non-relocatable x86
ramstage out of the way of any reasonable payload until we can
get rid of it for good.
14 MiB was chosen after some discussion, but it does fit well:
o Fits in the 16 MiB cacheable range coreboot sets up by default
o Most small payloads are well under 14 MiB (even kernels!)
o Most large payloads get loaded at 16 MiB (especially kernels!)
With this change in place coreboot correctly still loads a bzImage payload.
Werner reports that the 0xe00000 setting works on his broadwell systems.
Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/28647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a __always_inline macro that wraps __attribute__((always_inline))
and replace current users with the macro, excluding files under
src/vendorcode.
Change-Id: Ic57e474c1d2ca7cc0405ac677869f78a28d3e529
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/28587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@google.com>
|
|
The romstage main() entry point on arm64 boards is usually in mainboard
code, but there are a handful of lines that are always needed in there
and not really mainboard specific (or chipset specific). We keep arguing
every once in a while that this isn't ideal, so rather than arguing any
longer let's just fix it. This patch moves the main() function into arch
code with callbacks that the platform can hook into. (This approach can
probably be expanded onto other architectures, so when that happens this
file should move into src/lib.)
Tested on Cheza and Kevin. I think the approach is straight-forward
enough that we can take this without testing every board. (Note that in
a few cases, this delays some platform-specific calls until after
console_init() and exception_init()... since these functions don't
really take that long, especially if there is no serial console
configured, I don't expect this to cause any issues.)
Change-Id: I7503acafebabed00dfeedb00b1354a26c536f0fe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/28199
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since commit 372d0ff1d1 (arch/arm64: mmu: Spot check TTB memory
attributes), we already check the memory attributes that the TTB region
is mapped with to avoid configuration mistakes that cause weird issues
(because the MMU walks the page tables with different memory attributes
than they were written with). Unfortunately, we only checked
cachability, but the security state attribute is just as important for
this (because it is part of the cache tag, meaning that a cache entry
created by accessing the non-secure mapping won't be used when trying to
read the same address through a secure mapping... and since AArch64 page
table walks are cache snooping and we rely on that behavior, this can
lead to the MMU not seeing the new page table entries we just wrote).
This patch adds the check for security state and cleans up that code a
little.
Change-Id: I70cda4f76f201b03d69a9ece063a3830b15ac04b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/28017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Accesses to architectural registers should be really fast -- they're
just registers, after all. In fact, the arm64 architecture uses them for
some timing-senstive uses like the architectural timer. A read should be:
one instruction, no data dependencies, done.
However, our current coreboot framework wraps each of these accesses
into a separate function. Suddenly you have to spill registers on a
stack, make a function call, move your stack pointer, etc. When running
without MMU this adds a significant enough delay to cause timing
problems when bitbanging a UART on SDM845.
This patch replaces all those existing functions with static inline
definitions in the header so they will get reduced to a single
instruction as they should be. Also use some macros to condense the code
a little since they're all so regular, which should make it easier to
add more in the future. This patch also expands all the data types to
uint64_t since that's what the actual assembly instruction accesses,
even if the register itself only has 32 bits (the others will be ignored
by the processor and set to 0 on read). Arm regularly expands registers
as they add new bit fields to them with newer iterations of the
architecture anyway, so this just prepares us for the inevitable.
Change-Id: I2c41cc3ce49ee26bf12cd34e3d0509d8e61ffc63
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
When we first created the arm64 port, we weren't quite sure whether
coreboot would always run in EL3 on all platforms. The AArch64 A.R.M.
technically considers this exception level optional, but in practice all
SoCs seem to support it. We have since accumulated a lot of code that
already hardcodes an implicit or explicit assumption of executing in EL3
somewhere, so coreboot wouldn't work on a system that tries to enter it
in EL1/2 right now anyway.
However, some of our low level support libraries (in particular those
for accessing architectural registers) still have provisions for
running at different exception levels built-in, and often use switch
statements over the current exception level to decide which register to
access. This includes an unnecessarily large amount of code for what
should be single-instruction operations and precludes further
optimization via inlining.
This patch removes any remaining code that dynamically depends on the
current exception level and makes the assumption that coreboot executes
at EL3 official. If this ever needs to change for a future platform, it
would probably be cleaner to set the expected exception level in a
Kconfig rather than always probing it at runtime.
Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
CNTFRQ_EL0 is a normal AArch64 architectural register like hundreds of
others that are all accessed through the raw_(read|write)_${register}()
family of functions. There's no reason why this register in particular
should have an inconsistent accessor, so replace all instances of
set_cntfrq() with raw_write_cntfrq_el0() and get rid of it.
Change-Id: I599519ba71c287d4085f9ad28d7349ef0b1eea9b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I24d219b4ce6033f64886e22973ca8716113d319f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
cache_sync_instructions() has been superseded by
arch_program_segment_loaded() and friends for a while. There are no uses
in common code anymore, so let's remove it from <arch/cache.h> for all
architectures.
arm64 still has an implementation and one reference, but they are not
really needed since arch_program_segment_loaded() does the same thing
already. Remove them.
Leave it in arm(32) since there are several references (including in SoC
code) that I don't feel like tracking down and testing right now.
Change-Id: I6b776ad49782d981d6f1ef0a0e013812cf408524
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
coreboot payloads expect to be entered with MMU disabled on arm64. The
usual path via Arm TF already does this, so let's align the legacy path
(without Secure Monitor) to do the same.
Change-Id: I18717e00c905123d53b27a81185b534ba819c7b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add Kconfig options to not build the Arm Trusted Firmware, but use
a precompiled binary instead. To be used on platforms that do not
have upstream Arm Trusted Firmware support and useful for development
purposes.
It is recommended to use upstream Arm Trusted Firmware where possible.
Change-Id: I17954247029df627a3f4db8b73993bd549e55967
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/27559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
Change-Id: I3873cc8ff82cb043e4867a6fe8c1f253ab18714a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Disabling the MMU with proper cache behavior is a bit tricky on ARM64:
you can flush the cache first and then disable the MMU (like we have
been doing), but then you run the risk of having new cache lines
allocated in the tiny window between the two, which may or may not
become a problem when those get flushed at a later point (on some
platforms certain memory regions "go away" at certain points in a way
that makes the CPU very unhappy if it ever issues a write cycle to
them again afterwards).
The obvious alternative is to first disable the MMU and then flush the
cache, ensuring that every memory access after the flush already has the
non-cacheable attribute. But we can't just flip the order around in the
C code that we have because then those accesses in the tiny window
in-between will go straight to memory, so loads may yield the wrong
result or stores may get overwritten again by the later cache flush.
In the end, this all shouldn't really be a problem because we can do
both operations purely from registers without doing any explicit memory
accesses in-between. We just have to reimplement the function in
assembly to make sure the compiler doesn't insert any stack accesses at
the wrong points.
Change-Id: Ic552960c91400dadae6f130b2521a696eeb4c0b1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|