Age | Commit message (Collapse) | Author |
|
Change-Id: I7e8de35dcdad52bb311b34bfa9b272d17ed3186b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29243
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I6a9d71e69ed9230b92f0f330875515a5df29fc06
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29312
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
8M was set in the assumption that at least 4M was needed for IED
(Intel Enhanced Debug) , but this is not true.
The SMRR MTRR's need to have TSEG aligned to its size which is easier when TSEG
is only 2M. Also at most 6M of RAM more becomes available for use.
Change-Id: I4b114c8dc13699b3c034f0a7060181d9d590737b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27873
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Having cbmem floating between two ram regions is a bad idea and some
payloads (e.g. tianocore) even bail out on this. To overcome this issue mark the
region between tom and cbmem as uma.
Change-Id: Ifab37b0003f09a680024d5b155ab0bb157920952
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fixed resources have to be registered early during
read_resources() phase, such that device allocator
will avoid them.
Change-Id: Iff5f1426015a908e988ff757055034c87085c0f5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27119
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I81985bd2836bdeb369587f170504a8a048ee496b
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/29196
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Implement board_reset() as "system reset".
Change-Id: I2d277b0845b4e8977b68892c2e5e00d8918e063f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29056
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Implement board_reset() as "system reset".
Change-Id: I2b68a23cdf244884104d4ed54e19d3ab347c3a3e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29055
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add SOUTHBRIDGE_INTEL_COMMON_RESET for all Intel platforms that used to
perform a "system reset" in their hard_reset() implementation. Replace
all duplicate CF9 reset implementations for these platforms.
Change-Id: I8e359b0c4d5a1060edd0940d24c2f78dfed8a590
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I942a054144e05a3722c3743e445a879e86021dd4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Phase 1. Due to the size of the effort, this CL is broken into several
phases.
Change-Id: I0236e0960cd1e79558ea50c814e1de2830aa0550
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
|
|
It looks like on the ASUS P5QC has 0 in this CAPID field while still supporting
TCK_666MHZ.
Change-Id: Id1a94d91434dbe782fcc56dad56fcaee4e78463b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/29101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
While during the read training itself only the settings for rank 0 are used for
all ranks, the controller does use the separate settings for each rank later on.
It is unknown which register is responsible for this.
The signals are probably not generated separately and therefore need to have the
same settings for all ranks. Therefore program the results for all ranks instead
of for all populated ranks.
TESTED: Fixes DG43GT not booting with only the second DIMM slot of a channel
populated.
Change-Id: I7965a068ef4779847e62e966154764370c91302a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/28577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Use "cpu/x86/msr.h" for common IA-32 MSRs and correct IA-32 MSRs names.
Change-Id: Ida7f2d608c55796abf9452f190a58802e498302d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28752
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I849dd406f5ccc733d4957eaf1c774745782f531a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.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>
|
|
Change-Id: I6b40aaf5af5d114bbb0cd227dfd50b0ee19eebba
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28934
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I233e835180fd445961b6deb74ea7afc2821c236e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
As per internal discussion, there's no "ChromiumOS Authors" that's
meaningful outside the Chromium OS project, so change everything to the
contemporary "Google LLC."
While at it, also ensure consistency in the LLC variants (exactly one
trailing period).
"Google Inc" does not need to be touched, so leave them alone.
Change-Id: Ia0780e31cdab879d2aaef62a2f0403e3db0a4ac8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/28756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
Change-Id: Ib70eb33fac654a773ea39a5fd4206435dffdabb7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28702
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Use of device_t is deprecated.
Change-Id: I70dcefd5bc9864931f66bece1f044f806f5d7ae0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch contain minimal set of changes to initial IVRS implementation
to make it work reliably. Code in this patch was tested with Xen 4.8 and
Debian 4.14.y - this software stack survived 100x reboots without any
hang on PC Engines apu2c4. Previously using IVRS provided by AGESA lead
to 29/100 hangs.
MMIO base shall not be hard coded since this value depends on platform
design.
Performance counters were selected experimentally, since lack of
them cause 4.14.y panic:
[ 1.064229] AMD-Vi: IOMMU performance counters supported
[ 1.069579] BUG: unable to handle kernel paging request at ffffaffc4065c000
[ 1.073554] IP: iommu_go_to_state+0xf8a/0x1260
[ 1.073554] PGD 12a11f067 P4D 12a11f067 PUD 12a120067 PMD 129b69067 PTE 0
[ 1.073554] Oops: 0000 [#1] SMP NOPTI
[ 1.073554] Modules linked in:
[ 1.073554] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.14.50 #13
[ 1.073554] Hardware name: PC Engines apu2/apu2, BIOS 4.8-1174-gf12b3046f0-d2
[ 1.073554] task: ffff8d5d69b9f040 task.stack: ffffaffc40648000
[ 1.073554] RIP: 0010:iommu_go_to_state+0xf8a/0x1260
[ 1.073554] RSP: 0018:ffffaffc4064be28 EFLAGS: 00010282
[ 1.073554] RAX: ffffaffc40658000 RBX: ffff8d5d69bae000 RCX: ffffffff99e57b88
[ 1.073554] RDX: 0000000000000000 RSI: 0000000000000092 RDI: 0000000000000246
[ 1.073554] RBP: 0000000000000040 R08: 0000000000000001 R09: 0000000000000170
[ 1.073554] R10: 0000000000000000 R11: ffffffff9a435e2d R12: 0000000000000000
[ 1.073554] R13: ffffffff9a29a830 R14: 0000000000000000 R15: 0000000000000000
[ 1.073554] FS: 0000000000000000(0000) GS:ffff8d5d6ec80000(0000) knlGS:00000
[ 1.073554] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.073554] CR2: ffffaffc4065c000 CR3: 000000010fa0a000 CR4: 00000000000406e0
[ 1.073554] Call Trace:
[ 1.073554] ? set_debug_rodata+0x11/0x11
[ 1.073554] amd_iommu_init+0x11/0x89
[ 1.073554] pci_iommu_init+0x16/0x3f
[ 1.073554] ? e820__memblock_setup+0x60/0x60
[ 1.073554] do_one_initcall+0x51/0x190
[ 1.073554] ? set_debug_rodata+0x11/0x11
[ 1.073554] kernel_init_freeable+0x16b/0x1ec
[ 1.073554] ? rest_init+0xb0/0xb0
[ 1.073554] kernel_init+0xa/0xf7
[ 1.073554] ret_from_fork+0x22/0x40
[ 1.073554] Code: d2 31 f6 48 89 df e8 d8 15 02 ff 85 c0 75 d1 48 8b 44 24 2
[ 1.073554] RIP: iommu_go_to_state+0xf8a/0x1260 RSP: ffffaffc4064be28
[ 1.073554] CR2: ffffaffc4065c000
[ 1.073554] ---[ end trace 44588f98aa7c7c0b ]---
[ 1.255973] Kernel panic - not syncing: Attempted to kill init! exitcode=0x09
[ 1.255973]
[ 1.259934] ---[ end Kernel panic - not syncing: Attempted to kill init! exi9
Possible future improvements:
- compare device entries with values returned by AGESA
- enable EFRSup (this is enabled in AGESA)
- try various IVHD flags (there is difference between initial
implementation and AGESA)
Change-Id: I7e3a3d21f295ae96962d7718b9568fc4b67eb23d
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Reviewed-on: https://review.coreboot.org/27602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
Use of device_t has been abandoned in ramstage
Change-Id: Ifc32b0f6964a8c3e3a100c787ac2a889b39322a6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Using the cached CPU FSB setting can simply be wrong, in which case it won't
boot. Since the selected timings also depend on the CPU FSB, it is also best to
not use cached timings at all when a change is detected.
Tested on P5QC, swapped a 1333MHz FSB to a 800MHz FSB and it uses !fast_boot
boot path.
Change-Id: I12d91d0e892c15778409d7c00b27652ee52ca80c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/28506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
- Iteration over devices in add_ivrs_device_entries were simplified to
decrease complexity.
- Code was structured to satisfy checkpatch
Change-Id: I1ae789f75363435accd14a1b556e1570f43f94c4
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Reviewed-on: https://review.coreboot.org/15164
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I12d3ed35770ee06626f884db23004652084c88c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15186
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Icac6e696efa1721933a1963b45d608d9ae735149
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/28589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nathaniel Roach <nroach44@gmail.com>
Reviewed-by: Evgeny Zinoviev <me@ch1p.com>
|
|
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>
|
|
Add a __noreturn macro that wraps __attribute__((noreturn)) and replace
current users with the macro.
Change-Id: Iddd0728cf79678c3d1c1f7e7946c27375a644a7d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/28505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
CB:27984 (e6c8f7e) is supposed to skip over NGI if bit #1 in
register GCC is set. However the check for x4x was wrongly
checking if any bit of the whole register is set.
Change-Id: I5000f5e771abb98f046e2ad19c1bee7dbc0743fc
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/28447
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Writes to VGA MEM and IO by NGI are invalid if the IGD is not decoding
them.
Change-Id: I4b9329d14105eb563a0d4aea6ef75ff11febf6df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
There's nothing Sandy Bridge specific in this code.
Make it available on all platforms to reduce code duplication.
Tested on Lenovo T430: SMBIOS entry 17 is still valid.
Change-Id: I051c3e07a999d8dad082c24f65b43dce180349fd
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/28213
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This should not be board specific.
Change-Id: Ifa617e84af767f33a94f1ddfa7d4883c1a45198f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/28224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When doing the receive enable training, the final mapping of the ranks is
already done, so we can be sure that that address 0x00000000 there will always
be a rank.
Change-Id: I7ac017a8816fc9a47cef0695826a1c32f699f6f8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/28230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
With this the time spend during the raminit decreases from ~480ms to ~126ms.
Change-Id: Ic23f39f1017010c89795e626f6a6f918f8bda17a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/28229
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: Ic6e7341b53bcabc415089ccfab121d3694ccb071
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/28212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The DIMM type read from SPD needs to be converted to make sure SMBIOS fills
in the correct formfactor.
Tested on Lenovo T430: The Form Factor no longer reads as unknown.
Change-Id: Ia0211fa133f4ba9d60dfbd5f0dd45a43df68c030
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/28192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Fill in SMBIOS type 17 DIMM serial number, read from SPD.
Fixes FWTS SMBIOS type 17 test.
Change-Id: Id6e818bfdf4af0fd34af56dc23df052a3f8c348d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/28191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: Iddea8cc71dc1fb33d46b22dd19e39bf1c1257555
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/28117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Fix the IASL build warnings:
Object is not referenced (Name [CDW2] is within a method [_OSC])
Object is not referenced (Name [CDW3] is within a method [_OSC])
Remove the not referenced objects. They are not needed.
BUG=b:112476331
TEST=IASL doesn't give the warning.
Change-Id: I5b38d4de3f9875c5b013a49eb5146bf5916b96a6
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/28121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This binary needs to be at a specific offset and will therefore always
be located in the COREBOOT fmap region.
This is needed when VBOOT_SEPARATE_VERSTAGE is selected.
Change-Id: Ia73d468ab23932f92331ef40b8e8066cef55af2c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/26883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I689c5663ef59861f79b68220abd146144f7618de
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I00094028036f33892362b935899e1bceef1da625
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Use the value discovered in the MCG_CAP[Count] for the number of MCA
status registers to clear. The generations should have the following
number of banks:
* Family 10h: 6 banks
* Family 12h: 6
* Family 14h: 6
* Family 15h: 7
* Family 16h: 6
Change-Id: I0fc6d127a200b10fd484e051d84353cc61b27a41
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/27923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This patch contains the parts that changed the hash of the generated binary;
probably due to the compiler optimizing things slightly different.
Change-Id: I3233ba1747dcf5ad05b2ad771a86e3936f655d1c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/27718
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I7935cc166aa39f4053f45eef925d92ce50fd98ba
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/27709
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This part of the cleanup patches changes the hash of the output binary; likely
due to the compiler optimizing things differently.
Change-Id: I1a22f6216a75e2b463d4e169e97ad6e0bbaafae8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/27708
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I62e4a8610689e72944e1a9c020f13a47d402c136
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/27732
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|