| Age | Commit message (Collapse) | Author |
|---|
|
The CBFS mcache size default was eyeballed to what should be "hopefully
enough" for most users, but some recent Chrome OS devices have already
hit the limit. Since most current (and probably all future) x86 chipsets
likely have the CAR space to spare, let's just double the size default
for all supporting chipsets right now so that we hopefully won't run
into these issues again any time soon.
The CBFS_MCACHE_RW_PERCENTAGE default for CHROMEOS was set to 25 under
the assumption that Chrome OS images have historically always had a lot
more files in their RO CBFS than the RW (because l10n assets were only
in RO). Unfortunately, this has recently changed with the introduction
of updateable assets. While hopefully not that many boards will need
these, the whole idea is that you won't know whether you need them yet
at the time the RO image is frozen, and mcache layout parameters cannot
be changed in an RW update. So better to use the normal 50/50 split on
Chrome OS devices going forward so we are prepared for the eventuality
of needing RW assets again.
The RW percentage should really also be menuconfig-controllable, because
this is something the user may want to change on the fly depending on
their payload requirements. Move the option to the vboot Kconfigs
because it also kinda belongs there anyway and this makes it fit in
better in menuconfig. (I haven't made the mcache size
menuconfig-controllable because if anyone needs to increase this, they
can just override the default in the chipset Kconfig for everyone using
that chipset, under the assumption that all boards of that chipset have
the same amount of available CAR space and there's no reason not to use
up the available space. This seems more in line with how this would work
on non-x86 platforms that define this directly in their memlayout.ld.)
Also add explicit warnings to both options that they mustn't be changed
in an RW update to an older RO image.
BUG=b:187561710
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I046ae18c9db9a5d682384edde303c07e0be9d790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Rename and update POST_ENTRY_RAMSTAGE postcode value from 0x80 to 0x6f
to make the ramstage postcodes appear in an incremental order.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I60f4bd8b2e6b2b887dee7c4991a14ce5d644fdba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Commit 6b5bc77c9b22c398262ff3f4dae3e14904c57366 (treewide: Remove "this
file is part of" lines) removed most of them, but missed some files.
Change-Id: Ib8e7ab26a74b52f86d91faeba77df3331531763f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53976
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
When using a hardware assisted root of trust measurement, like Intel
TXT/CBnT, the TPM init needs to happen inside the bootblock to form a
proper chain of trust.
Change-Id: Ifacba5d9ab19b47968b4f2ed5731ded4aac55022
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51923
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ib93617867b946e208c31275d55d380aab7e51a50
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52729
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Prints out the following:
eSPI Slave Peripheral configuration:
Peripheral Channel Maximum Read Request Size: 64 bytes
Peripheral Channel Maximum Payload Size Selected: 64 bytes
Peripheral Channel Maximum Payload Size Supported: 64 bytes
Bus master: disabled
Peripheral Channel: ready
Peripheral Channel: enabled
BUG=none
TEST=boot guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I7d598ee4f0f9d8ec0b37767e6a5a70288be2cb86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
We had the addrspace_32bit rdev in prog_loaders.c for a while to help
represent memory ranges as an rdev, and we've found it useful for a
couple of things that have nothing to do with program loading. This
patch moves the concept straight into commonlib/region.c so it is no
longer anchored in such a weird place, and easier to use in unit tests.
Also expand the concept to the whole address space (there's no real need
to restrict it to 32 bits in 64-bit environments) and introduce an
rdev_chain_mem() helper function to make it a bit easier to use. Replace
some direct uses of struct mem_region_device with this new API where it
seems to make sense.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie4c763b77f77d227768556a9528681d771a08dca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Found-by: Paul Fagerburg <pfagerburg@chromium.org>
Change-Id: Ic434c969141c67ce317a5db0c8805de02c84eb08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
|
|
Algorithm used to calculate weekday is now based on Zeller's rule, so it
does not need if statement constraining year to 1971 and later.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I25e2e6a1c9b2fb1ac2576e028b580db0ea474d37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
|
|
CBFS_VERIFICATION requires the CBFS metadata hash anchor to be linked
into an uncompressed stage, but for platforms using COMPRESS_BOOTBLOCK,
this is only the decompressor stage. The first CBFS accesses are made in
the bootblock stage after decompression, so if we want to make
CBFS_VERIFICATION work on those platforms, we have to pass the metadata
hash anchor from the decompressor into the bootblock. This patch does
just that. (Note that this relies on the decompressor data remaining
valid in memory for as long as the metadata hash anchor is needed. This
is always true even for OVERLAP_DECOMPRESSOR_ROMSTAGE() situations
because the FMAP and CBFS metadata necessarily need to have finished
verification before a new stage could be loaded.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2e6d7384cfb8339a24369eb6c01fc12f911c974e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52085
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch adds file data hashing for CONFIG_CBFS_VERIFICATION. With
this, all CBFS accesses using the new CBFS APIs (cbfs_load/_map/_alloc
and variants) will be fully verified when verification is enabled. (Note
that some use of legacy APIs remains and thus the CBFS_VERIFICATION
feature is not fully finished.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic9fff279f69cf3b7c38a0dc2ff3c970eaa756aa8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
With the last external user to cbfs_load_and_decompress() gone, we can
stop exporting this function to the rest of coreboot and make it local
to cbfs.c. Also remove a couple of arguments that no longer really make
a difference and fold the stage-specific code for in-place LZ4
decompression into cbfs_prog_stage_load().
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4b459650a28e020c4342a66090f55264fbd26363
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The calloc() function is useful in addition to malloc and friends, so
add the obvious definition.
Change-Id: I57a568e323344a97b35014b7b8bec16adc2fd720
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51949
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Right before CB:49334 was submitted, I changed the signature of
cbfs_allocator_t function pointers to include another argument passing
in the already loaded CBFS metadata (to allow for the rare edge case of
allocators needing to read CBFS attributes). This interface is not meant
to be able to modify the passed-in metadata, so to clarify that and
prevent potential errors, we should declare the argument const.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7e3756490b9ad7ded91268c61797cef36c4118ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
These used to be printed before CB:46605. Having them in the logs can be
a huge timesaver when debugging logs sent to you by other people
(especially from systems that don't boot all the way). Let's add them
back.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ifdbfdd29d25a0937c27113ace776f7aec231a57d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
In pursuit of the goal of eliminating the proliferation of raw region
devices to represent CBFS files outside of the CBFS core code, this
patch removes the get_spd_cbfs_rdev() API and instead replaces it with
spd_cbfs_map() which will find and map the SPD file in one go and return
a pointer to the relevant section. (This makes it impossible to unmap
the mapping again, which all but one of the users didn't bother to do
anyway since the API is only used on platforms with memory-mapped
flash. Presumably this will stay that way in the future so this is not
something worth worrying about.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iec7571bec809f2f0712e7a97b4c853b8b40702d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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>
|
|
This patch rewrites the last few users of prog_locate() to access CBFS
APIs directly and removes the call. This eliminates the double-meaning
of prog_rdev() (referring to both the boot medium where the program is
stored before loading, and the memory area where it is loaded after) and
makes sure that programs are always located and loaded in a single
operation. This makes CBFS verification easier to implement and secure
because it avoids leaking a raw rdev of unverified data outside the CBFS
core code.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7a5525f66e1d5f3a632e8f6f0ed9e116e3cebfcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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 patchs adds a new CBFS primitive that allows callers to pass in an
allocator function that will be called once the size of the file to load
is known, to decide on its final location. This can be useful for
loading a CBFS file straight into CBMEM, for example. The new primitive
is combined with cbfs_map() and cbfs_load() into a single underlying
function that can handle all operations, to reduce the amount of code
that needs to be duplicated (especially later when file verification is
added). Also add a new variation that allows restraining or querying the
CBFS type of a file as it is being loaded, and reorganize the
documentation/definition of all these accessors and variations in the
header file a little.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5fe0645387c0e9053ad5c15744437940fc904392
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch pulls control of the memory pool serving allocations from the
CBFS_CACHE memlayout area into cbfs.c and makes it a core part of the
CBFS API. Previously, platforms would independently instantiate this as
part of boot_device_ro() (mostly through cbfs_spi.c). The new cbfs_cache
pool is exported as a global so these platforms can still use it to
directly back rdev_mmap() on their boot device, but the cbfs_cache can
now also use it to directly make allocations itself. This is used to
allow transparent decompression support in cbfs_map().
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0d52b6a8f582a81a19fd0fd663bb89eab55a49d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The new CBFS API contains a couple of trivial wrappers that all just
call the same base functions with slightly different predetermined
arguments, and I'm planning to add several more of them as well. This
patch changes these functions to become static inlines, and reorganizes
the cbfs.h header a bit for better readability while I'm at it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If0170401b2a70c158691b6eb56c7e312553afad1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Doing this all in one go keeps the files consistent and should make
future refactoring easier.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Returning an error on a failure to measure makes the system not
bootable.
Change-Id: Ifd20e543d3b30de045c0656eccdcc494c2fb10ce
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
This patch changes the memlayout macro infrastructure so that the size
of a region "xxx" (i.e. the distance between the symbols _xxx and _exxx)
is stored in a separate _xxx_size symbol. This has the advantage that
region sizes can be used inside static initializers, and also saves an
extra subtraction at runtime. Since linker symbols can only be treated
as addresses (not as raw integers) by C, retain the REGION_SIZE()
accessor macro to hide the necessary typecast.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ifd89708ca9bd3937d0db7308959231106a6aa373
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
TEST=Not seeing default msg "Defaulting to using DDR4 params." with
this CL.
Change-Id: Ib751396ec74b1491fd08b88b07462b315c4a152d
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50745
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ica4254297f5d05e75f852d7e9a9e7bb833dfcea7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50397
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The lb_gpio coreboot table entries use name fields fixed to 16 bytes.
GCC will not allow creating a static initializer for such a field with a
string of more than 16 characters... but exactly 16 characters is fine,
meaning there's no room for the terminating NUL byte. The payloads (at
least depthcharge) can deal with this as well because they're checking
the size when looking at that table entry, but our printk("%16s") does
not and will happily walk over the end until somewhere else in memory we
finally find the next NUL byte.
We should probably try to avoid strings of exactly 16 characters in this
field anyway, just in case -- but since GCC doesn't warn about them they
can easily slip back in. So solve this bug by also adding a precision
field to the printk, which will make it stop overrunning the string.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ifd7beef00d828f9dc2faa4747eace6ac4ca41899
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Hide the detail of allocation from cbmem from the FSP.
Loading of a BMP logo file from CBFS is not tied to FSP
version and we do not need two copies of the code, move
it under lib/.
Change-Id: I909f2771af534993cf8ba99ff0acd0bbd2c78f04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ide5673dc99688422c5078c8c28ca5935fd39c854
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The guard changes from (CHROMEOS && PC80_SYSTEM) to
VBOOT_VBNV_CMOS here.
Change-Id: I653285c04e864aa6a3494ba1400787fa184ba187
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50250
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: I0c42720fdcc3b05337af692ed93a424575defd36
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48786
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Could have been removed with commit 63b9700b2c already.
Change-Id: Ie1083bce1794613c7dc683ae533e42fb5af39adf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50249
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I2279e2d7e6255a88953b2485c1f1a3b51a72c65e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
lint-000-license-headers reports error.
The SPDX identifier contains GPL-2.0
Update the identifier to GPL-2.0-only.
BUG = N/A
TEST = Build Intel Elkhart Lake
Change-Id: If49fd014f14b481163bca6cd3131139b6d95c6d8
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Factor out the condition when an attempt to load
stage from cache can be tried.
Change-Id: I936f07bed6fc82f46118d217f1fd233e2e041405
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Link .init section near the end of bootblock program.
It contains _start16bit, gdtptr and gdt that must be
addressable from realmode, thus within top 64 KiB.
Change-Id: If7b9737650362ac7cd82685cfdfaf18bd2429238
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I9031dad52581e77aa56014b1fede884f2cdeb6de
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49882
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
With the common <soc/nvs.h> approach platform does not
need to implement the common accessors or sizeof() function.
Change-Id: I1050a252f765c763c1ae2d1610cbfb0d973ba026
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The Picasso VBIOS is not setting the reserved_mask_size correctly. This
change relaxes the constraint to allow bpp_mask <= bits_per_pixel. This
is how the code previously used to work before CB:39002.
BUG=b:177094598, b:177422379
TEST=boot zork and see depthcharge working
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2e67532fa949fbd673269d8d7f1c0d8af6124ac9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
We currently have a mixture of calls used to determine
global ACPI S3 state. Reduce the boilerplate, ultimately
acpi_wakeup_is_s3() should be the only to keep.
Change-Id: Iff950d2bcf7eacbbdd40865abf62c35a2e8c3c69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47694
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Id5279587231c539bd3ffc75b75b29d88ef30e56a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
|
|
For a long time, second parameter 'stop' has been
ignored. The tested range is within 1 MiB above 'start'.
Change-Id: Icbf94cd6a651fbf0cd9aab97eb11f9b03f0c3c31
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48561
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Having some symmetry with <soc/nvs.h> now allows to reduce
the amount of gluelogic to determine the size and cbmc field
of struct global_nvs.
Since GNVS creation is now controlled by ACPI_SOC_NVS,
drivers/amd/agesa/nvs.c becomes obsolete and soc/amd/cezanne
cannot have this selected until <soc/nvs.h> exists.
Change-Id: Ia9ec853ff7f5e7908f7e8fc179ac27d0da08e19d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49344
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lance Zhao
|
|
For arch/x86 the realmode part has to be located within the same 64
KiB as the reset vector. Some older intel platforms also require 4 KiB
alignment for _start16bit.
To enforce the above, and to separate required parts of .text without
matching *(.text.*) rules in linker scripts, tag the pre-C environment
assembly code with section .init directive.
Description of .init section for ELF:
This section holds executable instructions that contribute to the
process initialization code. When a program starts to run, the
system arranges to execute the code in this section before calling the
main program entry point (called main for C programs).
Change-Id: If32518b1c19d08935727330314904b52a246af3c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I1e63a419db92642df6b7956050c39540c2ae11d6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48781
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We need this to happen prior to SMM module loader. If
there is some debugging output it's better they do not
appear in the middle of CPU bringup.
Change-Id: I45b4b5c0c5bf8bee258a465d1e364bfe98190e44
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Files under sb/ or soc/ should not have includes that tie those
directly to external components like ChromeEC os ChromeOS
vendorcode.
Change-Id: Ib56eeedaa9d7422e221efa9c8480ed5e12024bca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48765
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
