Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Reviewed-on: https://chromium-review.googlesource.com/384964
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Hardcoding the microcode filenames into the makefiles is great when
the microcode is in the blobs directory. When the microcode isn't
posted to the blobs directory, we need some method of supplying the
microcode binary into the build. This can of course be done manually
after the build has completed, as can be done with everything that
we're including in the ROM image. Instead of making life hard for
everyone though, let's just add a way to specify where the microcode
rom comes from.
BUG=chrome-os-partner:53013
BRANCH=None
TEST=None
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/16386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7c5127234809e8515906efa56c04af6005eecf0b
Reviewed-on: https://chromium-review.googlesource.com/382718
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide a default value of 0 in drivers/spi as there weren't
default values aside from specific mainboards and arch/x86.
Remove any default 0 values while noting to keep the option's
default to 0.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Reviewed-on: https://chromium-review.googlesource.com/373029
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Almost all boards and chipsets within the codebase assume or
use SPI flash as the boot device. Therefore, provide an option
for the boards/chipsets which don't currently support SPI flash
as the boot device. The default is to assume SPI flash is the
boot device unless otherwise instructed. This falls in line
with the current assumptions, but it also allows one to
differentiate a platform desiring SPI flash support while it not
being the actual boot device.
One thing to note is that while google/daisy does boot with SPI
flash part no SPI API interfaces were ever implemented. Therefore,
mark that board as not having a SPI boot device.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16191
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id4e0b4ec5e440e41421fbb6d0ca2be4185b62a6e
Reviewed-on: https://chromium-review.googlesource.com/373024
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
> Overrunning array "am335x_gpio_banks" of 4 4-byte elements at element
> index 4 (byte offset 16) using index "bank" (which evaluates to 4).
As the first index is 0, also error out if the index is equal the array
size.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/16165
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I6b6b6e010348a58931bd546dfc54f08460e8dbbc
Reviewed-on: https://chromium-review.googlesource.com/370702
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Quark does not support the rdmsr and wrmsr instructions. In this case
use a SOC specific routine to support the setting of the MTRRs. Migrate
the code from FSP 1.1 to be x86 CPU common.
Since all rdmsr/wrmsr accesses are being converted, fix the build
failure for quark in lib/reg_script.c. Move the soc_msr_x routines and
their depencies from romstage/mtrr.c to reg_access.c.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15839
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea
Reviewed-on: https://chromium-review.googlesource.com/363935
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
XIP cachelines contain the executable to run, we never want
that to get modified. With the change such erronous writes
are ignored and next cacheline miss will fetch from boot
media (SPI / FWH flash).
Change-Id: I52b62866b5658e103281ffa1a91e1c64262f3175
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15778
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363385
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Match the definition and use of these variable with haswell, such that
DCACHE_RAM_MRC_VAR_SIZE is not included in DCACHE_RAM_SIZE.
Change-Id: I5af20f63cd0cb631d39f7c7fe0e2a99ebd3ce986
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15761
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363384
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The fixed MTRRs cover the range [0:1MiB). While calculating the
variable MTRR usage the 1MiB boundary is checked such that
an excessive number of MTRRs aren't used because of unnatural
alignment at the low end of the physical address space. Howevever,
those checks weren't inclusive of the 1MiB boundary. As such a
variable MTRR could be used for a range which is actually covered
by the fixed MTRRs when the end address is equal to 1MiB. Likewise,
if the starting address of the range lands on the 1MiB boundary
then more variable MTRRs are calculated in order to meet natural
alignment requirements.
Before:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0
0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6
0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0
0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1
0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0
0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6
CPU physical address size: 39 bits
MTRR: default type WB/UC MTRR counts: 7/17.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007ffff00000 type 0
MTRR: 1 base 0x000000007b800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0
MTRR: 3 base 0x0000000080000000 mask 0x0000007fe0000000 type 0
MTRR: 4 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0
MTRR: 5 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1
MTRR: 6 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
After:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0
0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6
0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0
0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1
0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0
0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6
CPU physical address size: 39 bits
MTRR: default type WB/UC MTRR counts: 6/8.
MTRR: WB selected as default type.
MTRR: 0 base 0x000000007b800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x000000007c000000 mask 0x0000007ffc000000 type 0
MTRR: 2 base 0x0000000080000000 mask 0x0000007fe0000000 type 0
MTRR: 3 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
BUG=chrome-os-partner:55504
Change-Id: I7feab38dfe135f5e596c9e67520378a406aa6866
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15780
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362845
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Not all are matched, but this makes it easier to backport
MTRR changes from haswell.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ida5943b1469fc0089a31ff3b18131fb82b0941c6
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15760
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362686
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Since the socket layer is implemented with this CPU model, there
could potentially be multiple CPU models included. There can be
only one cache_as_ram include, so select it directly within
the socket directory.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia52bb152276eddfd1fb33ddb7f5d153ab8e8163c
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15757
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362683
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Zero-filling memory below 1 MiB resets car_migrated variable so
any CAR GLOBALs are not addressed correctly for the remaining
time in romstage. Also there is no actual need to do this as
ramstage loader handles BSS.
This fixes regression with commit 70cd54310 that broke fam10 boards
with romstage spinlocks enabled.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15754
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Change-Id: I7418821997a980ae5b818bd57e8a1b6507a543af
Reviewed-on: https://chromium-review.googlesource.com/362342
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
It is not possible for cbmem_add() to complete succesfully before
cbmem_recovery() is called. Adding more tables on S3 resume path
is also not possible.
Change-Id: Ic14857eeef2932562acee4a36f59c22ff4ca1a84
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15472
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359541
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
No need to make low memory backup unless we are on
S3 resume path.
Hide those details from ACPI.
Change-Id: Ic08b6d70c7895b094afdb3c77e020ff37ad632a1
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15241
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355007
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355006
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
CPU_MICROCODE_MULTIPLE_FILES relies on SUPPORT_CPU_MICROCODE_CBFS,
which is not set if CPU_MICROCODE_CBFS_NONE is set.
This makes selecting CPU_MICROCODE_MULTIPLE_FILES conditional.
Change-Id: I0c28f99a1b868bbf90a6f048cce3bea4ff849f76
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/15259
Original-Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
(cherry-picked from commit 4089a17cb9)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354193
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
It would not be possible to set MTRR for range 1MiB to 4MiB.
Our RAMTOP is power of 2 and enabling cache for bottom
1MiB should cause no problems.
Change-Id: I3619bc25be60f42b68615bfcdf36f02d66796e02
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15238
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit d71cfd2041)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354191
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reference to CACHE_AS_RAM was from the days we had
romcc boards using socket_mPGA605.
Change-Id: If397db83a01adeda4dd18d8b4c6e89bf0984264a
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15224
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
(cherry-picked from commit 831a7ef541)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354185
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
