As currently many systems would be barely functional without ACPI,
always generate ACPI tables if supported.
Change-Id: I372dbd03101030c904dab153552a1291f3b63518
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
If power_limit_1_time > 129 is false then power_limit_1_time can have a
value of up to 129 leading to an out-of-bounds illegal read indexing the
power_limit_time_sec_to_msr[] array. Thankfully all call sites have been
doing the right thing up until now so the issue has not been visible.
Change-Id: Ic029d1af7fe43ca7da271043c2b08fe3088714af
Found-by: Coverity Scan
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6478
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
patch based on VMX support in intel/fsp_model_206ax and intel/model_6fx
tested/verified working on google/panther
Change-Id: I61232fdc2a29c53aa3bea5ea78b2fdc41fd7396a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/6223
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The monotonic time now needs to be a first class citizen in Coreboot as
it is a hard dependency of the drivers/spi flash command polling
function.
Change-Id: I4e43d2680bf84bc525138f71c2b813b0f6be5265
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6135
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Lines with 'select SERIAL_CPU_INIT' where redundant with the
default being yes. Since there is no 'unselect SERIAL_CPU_INIT'
possibility, invert the default and rename option.
This squelches Kconfig warnings about unmet dependencies.
Change-Id: Iae546c56006278489ebae10f2daa627af48abe94
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5700
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
The mp_init library was based off of haswell code, but baytrail
was the first chipset to take advantage of it. Move haswell over
to using it so that the code duplication can be removed.
Change-Id: Id6e9464df028aa6ec138051f925817c85b4c13e5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5413
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5570
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
With the recent improvement 3d6ffe76f8,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Haswell CPUs need to use the default SMM region for
relocating to the desired SMM location. Back up that
memory on resume instead of reserving the default
region. This makes the haswell support more forgiving
to software which expects PC-compatible memory layouts.
Change-Id: I9ae74f1f14fe07ba9a0027260d6e65faa6ea2aed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The files affected do not make any PCI configuration calls.
If they did, the more correct includes would be pci_ops.h,
pci_defs.h and pci_ids.h.
Change-Id: I3e7f009371be6ea50318eaabf0c15500cb3f1210
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5200
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being
selected allow for calling vboot_verify_firmware()
with an empty implementation. This allows for one not to
clutter the source with ifdefs.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded
call to vboot_verify_firmware().
Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172711
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4879
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Not used anymore since microcode was moved.
Change-Id: Id666c80cb20e90e3664c4dcfcc0c41a4aeb4864c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4788
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Now that CBFS microcode no longer requires a NULL termination, remove the
dummy terminators from all microcode blobs. This also enables microcode
blobs from different CPU models to be linked in the same
cpu_microcode_blob.bin without the terminators getting in the way.
Change-Id: I25a6454780fd5d56ae7660b0733ac4f8c4d90096
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4506
Tested-by: build bot (Jenkins)
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be
set with values that are not power of 2. The region programmed
as WB cacheable will include all of ROM_SIZE.
Side-effects to consider:
Memory region below flash may be tagged WRPROT cacheable. As an
example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB.
Since this can overlap CAR, we add an explicit test and fail
on compile should this happen. To work around this problem, one
needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and
define a smaller region for WB cache.
With this change flash regions outside CBFS are also tagged WRPROT
cacheable. This covers IFD and ME and sections ChromeOS may use.
Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4625
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
CPU_MICROCODE_IN_CBFS was designed to mean that loading microcode updates
from a CBFS file is supported, however, the name implies that microcode is
present in CBFS. This has recently caused confusion both with contributions
from Google, as well as SAGE. Rename this option to
SUPPORT_CPU_UCODE_IN_CBFS in order to make it clearer that what is meant is
"hey, the code we have for this CPU supports loading microcode updates from
CBFS", and prevent further confusion.
Change-Id: I394555f690b5ab4cac6fbd3ddbcb740ab1138339
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4482
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
Reviewed-on: http://review.coreboot.org/4333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
SPD GPIOs were being read prior to initialization in romstage_common. To
fix, pass the copy_spd function to romstage_common, to be called at the
appropriate time (after PCH init, before DRAM init).
Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58608
Reviewed-on: http://review.coreboot.org/4237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When an INIT# is delivered to the CPU the CPU starts
executing from the reset vector. However, the internal state
is maintained. Therefore, check for such a condition and
reset the system.
Issues 'apreset warm' on the EC console. INIT# is sent and
CPU notices it's not a clean reset and forces one. No hangs.
Change-Id: I71229e0e5015ba8c60f5989c533268604ecc1ecc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57111
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On haswell ULT systems there is a 24MHz clock that continuously runs
when deep package c-states are entered. The 100MHz BCLK is shut down
in the lower c-states. When the package wakes back up a conversion
formula needs to be applied. The 24MHz calibration is done using the
internal PCODE unit.
Change-Id: I6be7702fb1de1429273724536f5af9125b98da64
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48292
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4136
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The c-states are configured according to the BWG, however the
package c-states are disabled as they currently cause platform
instability. The exposed ACPI c-state to processor c-state mapping
are as follows for ULT boards:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C7S long latency)
ACPI(C3) = MWAIT(C10)
The non-ULT boards have an expoed c-state mapping:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C3)
ACPI(C3) = MWAIT(C7S)
Included in this patch is removing the updating of current limit
registers as some of the MSRs are different and the proper values
are currently unknown. Lastly, some of the MSRs were renamed to
match the BWG.
Booted 3.8 kernel and used powertop to note package, core, and acpi
c-state residency.
Change-Id: Ia428d4a4979ba3cba44eb9faa96f74b7d3f22dfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48291
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4133
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The recommendation from Intel is to report each core as a
separate logical domain in the _PSD table.
This goes against the recommendation in the ACPI specification
because all of these cores are on the same package and share a
VR so they will do voltage transitions together.
The reasoning is that with a larger number of logical processors
the P-state often ramps too quickly resulting in higher power
consumption. By exposing each core as a separate domain the OS
can manage them individually allowing the socket to select the
optimum frequency.
$ cat /sys/firmware/acpi/tables/SSDT > /tmp/SSDT
$ iasl -d /tmp/SSDT
Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000000,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000001,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU2, 0x02, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000002,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU3, 0x03, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000003,
0x000000FE,
0x00000001
}
})
}
Change-Id: I5ef41b6ead4d88e9ba117003293dbc629c376803
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4130
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If romstage does not make cbmem_initialize() call, linker should
optimize the code for CAR migration away.
This simplifies design of CBMEM console by a considerable amount.
As console buffer is now migrated within cbmem_initialize() call there
is no longer need for cbmemc_reinit() call made at end of romstage.
Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3916
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This retrieves back the value stored with store_initial_timestamp()
in the bootblock for southbridge.
Change-Id: I377c823706c33ed65af023d20d2e4323edd31199
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3908
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Store EHCI Debug Port runtime variables in CAR_GLOBAL.
For platforms without CAR_MIGRATION, logging on EHCI Debug Port is
temporarily lost when CAR is torn down at end of romstage.
On model_2065x and model_206ax ehci_debug_info was overlapping the MRC
variable region and additionally migration used incorrect size for
the structure.
Change-Id: I5e6c613b8a4b1dda43d5b69bd437753108760fca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3475
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
Change-Id: I30d2a0c7131b8e4ec30c63eea36944ec111a8fba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With this patch, output on usbdebug also includes the section of
MTRR setups for every CPU. This makes usbdebug output almost identical
with that of serial port and CBMEM console.
Tested with model_206ax. Also tested previously on model_f2x which does
not have these disable/enable calls in model_f2x_init() without detected issues.
Change-Id: Idfd0e93439907b17255633658195d698feab3895
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3423
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
There were assumptions being made in the haswell
MP and SMM code which assumed the APIC id space
was 1:1 w.r.t. cpu number. When hyperthreading is
disabled the APIC ids of the logical processors
are all even. That means the APIC id space is sparse.
Handle this situation.
Change-Id: Ibe79ab156c0a171208a77db8a252aa5b73205d6c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3353
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit »haswell: 24MHz monotonic time implementation« (c46cc6f1) [1]
added the Kconfig variable `MONOTONIC_TIMER_MSR` with a help text,
but only used one space instead of the suggested two spaces for
indentation. So add one space.
»Lines under a "config" definition are indented with one tab, while
help text is indented an additional two spaces.« [2]
[1] http://review.coreboot.org/3153
[2] https://www.kernel.org/doc/Documentation/CodingStyle
(Chapter 10: Kconfig configuration files)
Change-Id: I39cf356bfd54c66a2f1b837c6667dcc915e41f29
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3262
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
