The new function "cros_vpd_gets(key, buf, size)" provides an easy and quick way
to retrieve values in ChromeOS VPD section.
BRANCH=none
BUG=none
TEST=Manually added CONFIG_FLASHMAP_OFFSET=0x00100000 in Nayn config,
added a cros_vpd_gets("test", buf, sizeof(buf)) in romstage.c,
emerge-nyan chromeos-coreboot-nyan # builds successfully,
and then get correct VPD values in console output.
Also tried x86 ("emerge-lumpy chromeos-coreboot-lumpy")
Change-Id: I38e50615e515707ffaecdc4c4fae65043541b687
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187430
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
When using LPAE, the address space is split to 2MB blocks. This change makes
the space reserved for DMA consistent with the block size.
TEST=Booted nyan with and without LPAE. Built nyan_big.
BUG=None
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I75c77484f6ca9f23b583ef651956d0265a9b4474
Reviewed-on: https://chromium-review.googlesource.com/188571
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Add a missing "~" so that we mask off just OSC_XOFS field and not the
rest of the register.
BUG=chrome-os-partner:26326
TEST=XHCI sometimes works after LP0.
BRANCH=none
Change-Id: I2df2387dbad6920d36aa2ae5e6cd91e9ec42fa08
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188897
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a port of coreboot changes from SageBIOS
to support the GizmoSphere Gizmo board target.
A defconfig is avaliable and is similar to other
targets but CONSOLE_CBMEM is not yet functional.
BUG=None
BRANCH=none
TEST=Build with SeaBIOS payload; boot chromeos development image
Change-Id: Ib1ff87d92f0e7cd6c3dbefd6237fef33f185ba86
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188275
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Creates a new CONFIG_DDR3_SOLDERED_DOWN variable to enable
handling proper DDR3 SPD initialization. This patch is from
SageBIOS (forked coreboot) sources and is required for platforms
such as the GizmoSphere Gizmo board.
BUG=None
BRANCH=none
TEST=Run on Gizmo board and check SPD dump being same as SageBIOS
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Change-Id: I28e69d649252f542eb3d20d51ff8af69ae6e394a
Reviewed-on: https://chromium-review.googlesource.com/188273
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Marcelo Póvoa <marcelogp@chromium.org>
Commit-Queue: Marcelo Póvoa <marcelogp@chromium.org>
The baytrail option rom was not correctly mirroring to the eDP
panel and the HDMI-connected monitor. Therefore, don't suggest
the HDMI monitor in the 0x5f35 video BIOS callback.
BUG=chrome-os-partner:26365
BRANCH=baytrail
TEST=Booted with and without HDMI connected monitor. DEV screen
always showed on eDP panel.
Change-Id: Icd388a9158700e0a9f9f38530297ee13397e7f76
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188731
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186393
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The display driver will not work in the kernel without the
presence of the VBT configuration. This configuration is contained
in the video option rom. Therefore, always load it.
BUG=chrome-os-partner:25885
BRANCH=baytrail
TEST=Built and tested dev as well as normal mode with upstream
patches. eDP panel correctly works still.
Change-Id: Ifd6ff9c7b1e8c18eb5b6683c642a5f0439479074
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188721
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Certain kernel drivers require the presence of option rom
contents because the board's static configuration information
is located within the blob. Therefore, allow a chipset/board to
instruct the pci device handling code to always load but not
necessarily run the option rom.
BUG=chrome-os-partner:25885
BRANCH=baytrail
TEST=Both enabling and not enabling this option shows expected behavior.
Change-Id: Ib0f65ffaf1a861b543573a062c291f4ba491ffe0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188720
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix the PLLU parameters to match the recommended values from the TRM,
and the values used by the kernel and LP0 blob. This includes adding
support for setting an LFCON value. It appears that changing the PLLU
parameters across suspend/resume causes XHCI stability issues after
resume.
BUG=chrome-os-partner:26326
TEST=XHCI works after LP0 suspend/resume on Nyan.
BRANCH=none
Change-Id: Ia4af12fefeebe607803e7f2f03ee4802367b82c3
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188752
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
This indirectly selects an appropriate PLLX frequency so the main CPUs run as
fast as they can but not faster.
BUG=chrome-os-partner:25467
TEST=Booted on nyan rev1.
BRANCH=None
Change-Id: Ibe61f5e35246b272771debf4fdf90c79b21eb5d0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/188603
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The PLLX provides the clock for the main cores which can run at different max
frequencies depending on the specific model of Tegra124. This change makes it
possible to select a model which will, in turn, select a frequency for PLLX.
The default is 2GHz which is the lowest maximum frequency.
BUG=chrome-os-partner:25467
TEST=Booted on nyan rev1. Verified that the selected PLLX frequency was 2GHz.
With a change that selects the right model for nyan, verified that the
corresponding frequency was selected.
BRANCH=None
Change-Id: Iee3a615083dee97ad659ff41cbf867af2a0c325d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/188602
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=none
BRANCH=nyan
TEST=built and booted coreboot on my Nyan-rev1, browsed, ran Youtube vids,
WebGL experiments, etc. Everything seemed OK.
Change-Id: I877680c9329ed96a0b602f0690acaa12079786d7
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/188550
Reviewed-by: Julius Werner <jwerner@chromium.org>
The SRAM is very likely faster than going all the way out to DRAM for data,
but I don't think it's part of the cores themselves and won't be as fast as
the L1 caches. Enabling caching for this region reduces the time it takes to
get to the payload by about 75% when serial output is disabled and the main
part of display init is commented out.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan.
BRANCH=None
Change-Id: I7ff26dea9d50e7d9a76e598e5654488481286b35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/188459
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
On baytrail there are leakage on TDO and TMS. Code changed to
pulling up the pads but that means XDP doesn't work.
Provided devicetree option "enable_xdp_tap" to keep XDP work.
BUG=chrome-os-partner:25430
BRANCH=baytrail
TEST=build and boot on rambi, hardware engineer verified
no power loss on TDO and TMS.
Change-Id: Icf6fdbc829c8fece9df828b42d3b88ae1ee237c1
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/188260
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
This change introduces LPAE for virtual address translation. To enable it, set
ARM_LPAE. Boot slows down about 4ms on Tegra124 with LPAE enabled.
TEST=Booted nyan with and without LPAE. Built nyan_big and daisy.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Change-Id: I74aa729b6fe6d243f57123dc792302359c661cad
Reviewed-on: https://chromium-review.googlesource.com/187862
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
The BUNIT controls the policy for read/write access to physical
memory. For the SMRAM range the policy was not allowing dirty
evictions to the SMRAM when the core causing the eviction was not
in SMM mode. This could happen when the SMM handler dirtied a line
and then RSM'd back into non-SMM mode. The cache line was dirtied
while in SMM mode, but when that particular cache line was evicted
it would be silently dropped. Fix this by allowing the BUNIT to honor
writes to the SMRAM range while the evicting core is not in SMM mode.
The core SMRR msr provides the mechanism for disallowing general access
to the SMRAM region while it is not in SMM mode.
BUG=chrome-os-partner:26243
BRANCH=baytrail
TEST=Was able to wake from USB devices from S3 successfully.
Change-Id: I26ed844dc657a50e60f568d9a39e78e89857a163
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188015
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Typically assert.h should provide assert().
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # pass.
Change-Id: I465f4a616b212f7b00d445c575866b13eecfa6fb
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187410
Reviewed-by: Julius Werner <jwerner@chromium.org>
The code in src/cpu/x86/mtrr/mtrr.c disables caching in a few places when
changing mtrr settings. While I can't find anything that says that's actually
required, I can believe it's necessary. With that said, other code around the
wrmsr instructions which actually modify the settings should be able to run
with caching enabled with no ill effects.
This is particularly true for two calls to printk, one in the fixed mtrr code
and one in the variable, which could result in an arbitrary amount of work
being done without caching. When changing the implementation of the cbmem
console, these two printks caused a significant regression in boot performance
on link of about 70ms which is about 10% of total firmware boot time. When the
window where the cache is disabled is minimized, both this and the new
implementation were about 30ms faster than the original boot time.
For the variable MTRRs, we now store what we want to set the MSRs to and then
write them all at once at the end of commit_var_mtrrs(). This way we don't
have some set and some not, but we still minimize the time we spend with the
caches disabled.
BUG=None
TEST=Booted on link. Measured boot timing before and after this change, and
with and without the new cbmem implementation.
BRANCH=None
Change-Id: I5139b262bd2d13f79afd88e2e2c0f514fb3e27c9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187811
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The UART hardware loses power while the system is suspended. However,
the kernel currently doesn't handle the notion of the serial port losing
its settings through a suspend. Because of this using a serial console
in the kernel can cause hangs. Work around this by always initializing
the serial port (if enabled) to 115200 8n1. Though the configuration
may differ it should at least keep hangs and crashes from occuring
with uninitialized serial port.
BUG=chrome-os-partner:25353
BRANCH=baytrail
TEST=Suspend/resume cycles successfully completed with and without
'echo N > /sys/module/printk/parameters/console_suspend'. With
a serial console enabled in the kernel. Also confirmed that
there are not any hiccups when coreboot has its console enabled.
Change-Id: I6fd8a0ae261318769d8f677ef04320a0d6ff1b6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188011
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=chrome-os-partner:21535
BUG=chrome-os-partner:25990
BRANCH=panther
TEST=manual: Boot on Panther and look in /sys/firmware/log for
the string "PCIe Root Port 4 ASPM is enabled"
Change-Id: I294571c113a8909adb2e97afca92aef9a1af917c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Change all pull down and pull up resistors from 10K to 20K,
it will save more power on various rails.
BUG=chrome-os-partner:24583
BRANCH=baytrail
TEST=build and boot on rambi, use modified kernel driver to execute
Change-Id: Id588bd9ac4dc71d0783ab933c15ecda0abdadad0
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/187570
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
On SECURITY_MODE (also known ODM Production mode), JTAG is disabled by
BootROM. We need this setting to reenable JTAG on lp0 exit.
BUG=None
TEST=Burn SECURITY_MODE fuse, build chip specific BCT.
wait for Penny to verify.
Change-Id: I81c6e3bc7c74d7915110f7bdd115c323b3a6b96c
Reviewed-on: https://chromium-review.googlesource.com/186677
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Penny Chiu <pchiu@nvidia.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Tom Warren <twarren@nvidia.com>
Replace sdram entry 1 with valid configurations since nyan 4GB board uses
RAM_CODE 1.
BUG=none
TEST=Flash and boot new image.bin. Console shows "RAMCODE=1" and
"Total SDRAM (MB): 4096"
BRANCH=none
Change-Id: Ia872bd7849f1b58075e1f97bf300e081293cb0d4
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187450
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:26085,chrome-os-partner:26051
TEST=With this change applied, check the clock in question
using a scope. Check that it shows up as 19.2Mhz.
Change-Id: I4f9d9132dce9e8a9314852de23838f8c8563021c
Reviewed-on: https://chromium-review.googlesource.com/187594
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
This is the first round of DPTF tuning for Rambi platform.
- Set TSR0 _PSV to 48C
- Set TSR2 _PSV to 55C
- Set TCPU _PSV to 80 and _CRT to 90
- Set mainboard _PDL to 8 (1ghz)
- Set _TRT sampling period to 60 seconds for all but CPU2CPU
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: Ifcb078580fe674a5ad66559293508dcc6cf136f5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187577
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable the ability for the mainboard to override the _PDL
value exported by DPTF. This will limit the P-state depth
when passive throttling is enabled.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: I700ef696ff7248997bfd8eb24785eca17d2d7f29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187576
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The 4-core SKU needs to use SW_ALL for P-state coordination.
There are related bits in MSR_POWER_MISC that need to be set
based on whether or not hardware coordination is disabled.
2-core systems:
- MSR_PMG_CST_CONFIG_CONTROL clear bit 11
- MSR_POWER_MISC set bit 2,3
- \_PR.CPUx._PSD coordination set to 0xFE (HW_ALL)
4-core systems:
- MSR_PMG_CST_CONFIG_CONTROL set bit 11
- MSR_POWER_MISC clear bit 2,3
- \_PR.CPUx._PSD coordination set to 0xFC (SW_ALL)
BUG=chrome-os-partner:26125
BRANCH=baytrail
TEST=build and boot on (2-core) rambi. Check MSR and ACPI _PSD.
Change-Id: I17e84dc50b4bcbffa599498b2bfeac43c135e5b4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code was passing a reference to ^GBUF to ConcatenateResTemplate
when it needed to pass the buffer itself. This was resulting in parsing
errors from the kernel when trying to evaluate \_SB.LPEA._CRS().
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=build and boot on rambi, use modified kernel driver to execute
\_SB.LPEA._CRS() and check for parsing problems.
Change-Id: Ifcefe9fcb43ffb7a62b4c9dff58934aa286e368b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186928
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The original power consumption number for C6FS is equal to
power consumption number for C6NS, which is wrong. The number
should be close to 0 but let's set as 1.
BUG=chrome-os-partner:23628
BRANCH=baytrail
TEST=Build and boot to OS on Rambi.
Change-Id: Iab6b9fa06896796f2c6061d754a321e9a6964092
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/186934
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These values are from the reference code but do not appear
to be documented elsewhere.
BUG=chrome-os-partner:23505
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: Id9eaa50a4fd5f729f4e1b20baec9390b0e717bf6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186933
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to support multiple trackpads with ACPI identification it is
necessary to declare devices that may not exist. If they happen to
share a wakeup resource then that can end up with duplicate _PRW
declarations and unexpected behavior with /proc/acpi/wakeup
BUG=chrome-os-partner:25883
BRANCH=baytrail
TEST=enable and disable TPAD in /proc/acpi/wakeup and test wake
Change-Id: Id45c6f01de8e06c689509458a5ad893277228bad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186932
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When setting up caching on nyan and big, we would set the region after DRAM to
the end of the address space as uncachable. DRAM may actually extend beyond
the end of the address space, so that may result in address aliasing or other
problems. This change adds a check to make sure there's actually space there.
BUG=None
TEST=Built for big.
BRANCH=None
Change-Id: Ic0a98550222f9dfc0aeafd67a2dd1c0c8f4ece44
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/186769
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The generic tegra124 code will use one of the PWMs to drive the backlight of
the display, but the PWM clock was enabled only for nyan. This change enables
it for big as well.
BUG=none
TEST=Built for Big
BRANCH=None
Change-Id: I5171da7c41f4b4db931563ada3e8e4ebf74ec3d9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/186767
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
FLVL is used to keep track of which thermal zones are active, but it is
not initialized upon boot / resume. An initial value of zero corresponds
to all zones being active, which causes the fan to spin at max speed
until the OS changes zones. Fix this annoyance by initializing FLVL to
the lowest temperature zone.
Also, fix a related bug where FLVL may jump to an undesired value. For
example, if FLVL=3 (zones 3 + 4 active), and zone 0 is set to off (it's
already off!), FLVL would previously become 1 (zones 1 + 2 + 3 + 4
active!). Fix this by not taking zone ON / OFF actions if our zone is
already ON / OFF.
BUG=chrome-os-partner:25766, chrome-os-partner:24775
TEST=Suspend / resume on Panther 20 times, verify that thermal zone after
resume matches expectation based upon temperature. Also, stress system
and verify thermal zones become active according to temperature
increase.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic60686aa5a67bf40c17497832b086ba09d56111a
Reviewed-on: https://chromium-review.googlesource.com/186455
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186669
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Without this patch coreboot will always use the read-only version
of ramstage, even if there is a read-write version available.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=panther
BUG=chrome-os-partner:25870
TEST=Install different RO and RW version, check in cbmem log that
coreboot's romstage and ramstage have different timestamps
in their banners.
Change-Id: I723a3d4479d59534660728d891a9f40a077b4ef0
Reviewed-on: https://chromium-review.googlesource.com/186664
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ARM configuration files have been changed that we need more settings to run
Coreboot on qemu-v7.
Also fixed the incorrect Makefile settings that caused armv7 to try building
with armv8 cache.
BRANCH=none
BUG=none
TEST=make menuconfig # select qemu-armv7
make # pass
qemu... # successfully boots to ramstage.
Change-Id: I4040e86ad1ff6e8ebd07cfe387c3f5a0e8941800
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186080
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Hung-Te Lin <hungte@google.com>
Once SECURITY_MODE fuse is burned, JTAG is disabled by default.
To reenable JTAG, besides chip unique id and SecureJtagControl need
to be built into BCT, Jtag enable flag is also needed to be set.
BUG=None
TEST=Burn SECURITY_MODE fuse, build chip specific BCT, coreboot
comes up and jtag hooks up fine.
Change-Id: Ic6b61be2c09b15541400f9766d486a4fcef192a8
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186031
Reviewed-by: Julius Werner <jwerner@chromium.org>
Rambi has been validated to use weaker memory ODT settings.
Enable the weaker settings.
BUG=chrome-os-partner:25420
BRANCH=baytrail
TEST=Built and booted. Suspended and resumed.
Change-Id: I71f50a69821fb292a7914d4fc1db0e903f1fe6fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186420
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Based on latest thermal report
BUG=chrome-os-partner:24532
TEST=boot tested on panther
BRANCH=panther
Change-Id: I4b8639f926fc3cf57eb5329818b9b912bfbe222d
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186113
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
