Fix the issue that return value "r" in line 534 will get overwritten
problem.
BUG=CID 1445995
TEST=Build sucessful and boot up in QEMU
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Change-Id: Icf760b142cfecfed7c929c15ad190ac74df027b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50352
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Francois Toguo Fotso <francois.toguo.fotso@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Fix compilation on GCC 10.2.1 and address the underlying issue. The
printf format specifier for a size_t type is z.
Change-Id: Ieb1db6c0c3eb4947bd3617e418bac238b70ec08f
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
smbios_type0_bios_version is only defined if HAVE_ACPI_TABLES is set.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I626ab954496833f46d6a785d92cc3b7e7d87e165
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now smbios type 4 max speed field will use the maximum speed of
processor itself if CPUID value can be accessed. However, this field
should be the maximum processor speed supported by the system. Here
we use smbios_cpu_get_max_speed_mhz only to get correct value.
Tested=Execute "dmidecode -t 4" to check max speed is correct.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Iae8e01a5e455709a57d60a840f279685c8aab80f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48636
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Crash Data are collected and sent to the OS via the ACPI BERT.
BUG=None
TEST=Built, and BERT successfully generated in the crashLog flow.
Signed-off-by: Francois Toguo <francois.toguo.fotso@intel.com>
Change-Id: I00e390d735d61beac2e89a726e39119d9b06b3df
Signed-off-by: Nikunj A. Dadhania <nikunj.dadhania@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
For SMBIOS type 3, add function to override number of power cords
Tested=Exectute dmidecode -t 3 to verify.
Signed-off-by: JingleHsuWiwynn <jingle_hsu@wiwynn.com>
Change-Id: I7dee3a944a49ffcfdc2f4408d92a17aa39761bb0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50015
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>
Update Extended Maximum Capacity field in SMBIOS type 16 so that
maximum dimm size can be over 2TB.
Tested=Execute "dmidecode -t 16" to check maximum capacity is over 2TB.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I61901c815f9d0daae102e5077a116c0de87240ef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49828
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
With top-aligned bootblock this is no longer globally needed.
The default maximum is now a generous 256 KiB with couple
platforms having lower limits of 32 KiB and 64 KiB.
Change-Id: Ib1aee44908c0dcbc17978d3ee53bd05a6200410c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Move .text section closer to .init. This reduces the size
of the flat bootblock binary and footprint in CBFS.
Change-Id: I64325bd633e1104853cfb928c7f801d94ff3045a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
Drop duplicated assignment that rewound `.` back, and broke platforms
using MRC.bin and DCACHE_RAM_MRC_VAR_SIZE.
Tested on out-of-tree Acer E5-573 (Broadwell), fixes booting.
Also tested on Asrock B85M Pro4 (Haswell), also fixes booting.
Change-Id: I3f0153f776c07acf7cf92808b677b118c60507c3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49909
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
The xeon_sp/cpx has a second 'rc' heap inside FSP-M that is statically
allocated at the start of CAR. This breaks FSP 2.0 specification. This
can be worked around in the linker scripts to make sure coreboot and
FSP-M don't fight over the same memory.
Tested
- on ocp/deltalake: boot and the "Smashed stack detected in
romstage!" message at the end of romstage is gone.
- qemu/i440fx: BUILD_TIMELESS=1 results in the same binary.
Change-Id: I6d02b8a46a2a8ef00f34d8f257595d43f5d3d590
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
On FSP1.1 platform cbmem_initiailze() is called in
chipset_teardown_car_main(). This causes double
call op cbmem_initialize().
Add call to cbmem_online() to avoid double CBMEM init.
BUG = N/A
TEST = Build and boot on Facebook FBG1701
Change-Id: I449ddfc94f1099d7c0e9005e6a5cf509e1433bb1
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Update SMBIOS type 17 type detail. Define this field by module type.
Tested=Execute "dmidecode -t 17" to check type detail is correct.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I6700056edad5db2b86f6da526329b1343b026385
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
At the moment neither verstage nor romstage has a generated assembly
stub. This was used when CAR was set up in romstage which is not the
case anymore.
Change-Id: Ia4a952f269cc2b3edf1290c80b7a63619c8c6c95
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
All platforms moved to initialise GNVS at the time
of SMM module loading.
Change-Id: I31b5652a946b0d9bd1909ff8bde53b43e06e2cd9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48699
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The (now removed) ID_SECTION_OFFSET=0x80 was actually the
secondary address flashrom and FILO are looking for. The
primary was 0x10, just below .reset.
If .id does not collide with .fit_pointer, use the higher
of the two locations.
Change-Id: I0d3a58c82efd3bbf94f4bc80ec5bbc97d5b1c109
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48499
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
The strings in .id are expected to match the build for
the purpose of identifying the binary image. There is
no identified use for the offsets.
The files id.ld and prologue.inc were unused.
Change-Id: Ida332671e0ace3f6afd11020474ffda04614bad5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The location is hardcoded inside flashrom and FILO.
Only two offsets are supported, 0x10 and 0x80.
Change-Id: I8348f2ac0cab969ab78ecb50a55de486eee0cf9b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47598
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Followup work forces gdtptr and gdt towards the top of
bootblock. They need to be realmode-addressable, i.e.
within top 64 KiB or same segment with .reset.
Change-Id: Ib6f23b2808d0a7e0d277d00a9b0f30c49fdefdd5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We have identical gdtptr16 and gdtptr. The reference in
gdtptr_offset calculation is not accounted for when
considering --gc-sections, so to support linking
gdt_init.S separately add dummy use of gdtptr symbol.
Realmode execution already accessed gdt that was located
outside [_start16bit,_estart16bit] region. Remove latter
symbol as the former was not really a start of region,
but entry point symbol.
With the romcc bootblock solution, entry32.inc may have
been linked into romstage before, but the !ENV_BOOTBLOCK
case seems obsolete now.
Change-Id: I0a3f6aeb217ca4e38b936b8c9ec8b0b69732cbb9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Packing bootblock sections is somewhat easier to understand
when these all appear in one .ld file.
Change-Id: Ie8629a89fa47a28db63ecc33c631b29ac5a77448
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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 change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a helper function for long mode to call some code in protected
mode and return back to long mode.
The primary use case is to run binaries that have been compiled for
protected mode, like the FSP or MRC binaries.
Tested on Intel Skylake. The FSP-M runs and returns without error while
coreboot runs in long mode.
Change-Id: I22af2d224b546c0be9e7295330b4b6602df106d6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48175
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The initial bootblock assembly code on x86 is just put into the .text
section, which just happens to come before all the individual .text.*
function sections in the program.ld script. So it tends to be at the
start of the image, but if you inserted another linker script section
with contents before .text, it would cause a problem. (I'm not sure if
it's an architectural requirement for _start16bit to come at the start
of the image, but at least its 4K alignment requirement would waste a
lot of space if it didn't.)
This patch moves the section to .text._start which is the name other
architectures use for the code they want in the very front of the image
and which is listed first in program.ld.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia84e6e33ec29584d356e226e8fdcb8c9334d49af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46834
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch flips the default of CONFIG_NO_CBFS_MCACHE so the feature is
enabled by default. Some older chipsets with insufficient SRAM/CAR space
still have it explicitly disabled. All others get the new section added
to their memlayout... 8K seems like a sane default to start with.
Change-Id: I0abd1c813aece6e78fb883f292ce6c9319545c44
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Check that stages running in CAR have their start and end in CAR.
Change-Id: I292aacce564c23d9ae21aa46c5e2f8784fa6a609
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add weak function for SMBIOS type 16 error correction type.
Tested=Execute "dmidecode -t 16" to check if error correction type
is correct.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I85b37e9cfd22a78544d03e5506ff92b1f2404f8e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47508
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a weak function to let the platform code provide the processor
voltage in 100mV units.
Implement the function on Intel platforms using the MSR_PERF_STATUS msr.
On other platforms the processor voltage still reads as unknown.
Tested on Intel CFL. The CPU voltage is correctly advertised.
Change-Id: I31a7efcbeede50d986a1c096a4a59a316e09f825
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It was supposed to return true for both S2 and S3, but
level S2 was never stored in acpi_slp_type or otherwise
implemented.
Change-Id: Ida0165e647545069c0d42d38b9f45a95e78dacbe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
