Set correct value for SDRAM in Foundation model, map
romstage to run in SRAM and enlarge stack space (in DRAM).
BUG=None
BRANCH=none
TEST=Ran image in foundation model
Change-Id: Id2f7d185fd09f8990c1756ac7ad4569498885ba7
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185754
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This adds simple bootblock initialization procedures with console
ouput support for the Foundation ARMv8 model. Includes stack
setup, basic caches/tlb/mmu control routines, SCTLR register access
for different exception levels and memset.S code from ARM.
It runs on the Foundation_v8 fast model from arm (see command line
in src/mainboard/emulation/foundation-armv8/Kconfig) until loading
romstage at cbfs_load_stage(), where it currently halts. Code is
debugable using printk only (after console_init) because the
Foundation model does not provide bare metal debugging support (so
adding exception handling and stack/register dump might be useful).
BUG=None
BRANCH=none
TEST=Ran image in foundation model
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Change-Id: I81b12416424a02f24a80924791fc39d9411fa4b4
Reviewed-on: https://chromium-review.googlesource.com/185275
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Marcelo Póvoa <marcelogp@chromium.org>
Commit-Queue: Marcelo Póvoa <marcelogp@chromium.org>
The PMIC setup code was unconditionally waiting for 10ms after each register
write. It might be possible for there to be an excess of current from lots of
rails switching around at the same time, but we can avoid that with a much
shorter delay in a few strategic places.
This change also moves the write to LDO3 to just under SD1 because LDO3 should
track SD1.
The duration and position for the delays and moving LDO3 were provided by Dan
Coggin at nvidia.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan rev1. Measured a 230 ms decrease in boot time.
BRANCH=None
Change-Id: I14805bf1b6242bdd0b286f37ae7d635c03909677
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/189016
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Daniel Coggin <dcoggin@nvidia.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These had been set to something fairly random which results in a very slow
clock on the bus itself. The new settings take into consideration the speed
the devices on the bus can run at. The TPM can't seem to handle speeds above
40KHz, but some documentation suggests that it should be able to handle up to
at least 100KHz.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan rev1. Built for big.
BRANCH=None
Change-Id: Iee98957c7e492c7dd08b071aeef3cce75c4a9e56
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/189015
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The divider for the I2C clocks works differently than for other IP blocks and
needs to be set up to reflect that. There's also a large internal divider which
means you have to do extra calculations to determine what the frequency of the
bus itself will be based on the I2C controller clock. The new macro takes the
desired frequency of the bus itself and figures everything else out.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan rev1 using this function to set up the i2c
busses.
BRANCH=None
Change-Id: Ib62a5659bcc0d0e15de41887514ae8efb8c8129a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/189014
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>
This allows limiting the CBFS size which is necessary
for building chromeos-bootimage.
BUG=none
BRANCH=none
TEST=emerge-gizmo chromeos-bootimage and run depthcharge
Change-Id: Idc1af152651973864704160ba1076ffa3b0ad749
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188919
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The default SMM region was previously being reserved.
Stop doing that in order to not antagonize certain kernel
loaders and payloads when there are low e820 ram
reservations. Since the default SMM region is not marked
as reserved the region needs backed up and restored on
resume.
BUG=chrome-os-partner:26563
BRANCH=baytrail
TEST=Built and booted. Suspended and resumed. Confirmed no more
e820 reservations at default SMM region. Also noted resume
times are still at ~200ms.
Change-Id: Icf21d40a790b0c1b0b8c2111f779abb996adce56
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189084
TEST=Booted nyan in normal and recovery mode. Created a map, filled it with some
chars, then verified they can be read from the pointer returned.
BUG=chrome-os-partner:25587
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Id1f1be4f6d2d5734d87bf3452d4806d0fe3fda88
Reviewed-on: https://chromium-review.googlesource.com/188894
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
There were some missing parenthesis and some extra semicolons which this
change adds and removes, respectively.
BUG=chrome-os-partner:25467
TEST=Built and booted on nyan rev1. Verified that the same frequency calculated
differently results in the same settings. Before operator precedence would
pull apart the frequency calculation and use the pieces in the wrong order.
BRANCH=None
Change-Id: I843d4ae9f7a2ae362926d94b6b77ef31d350a329
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/189013
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Instead of using a hard-coded memory reservation address, allocate
the RAM dynamically for the ram oops buffer.
BUG=chrome-os-partner:26563
BRANCH=baytrail
TEST=Built, booted, crashed. Confirmed pstore had crash. Also, confirmed
ramoops buffer in high memory.
Change-Id: Ic16987e9e54720d807616baf5e40e858fe1604e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188718
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
BUG=chrome-os-partner:26563
BRANCH=baytrail
TEST=Confirmed SMM backup region in cbmem. Suspend and Resumed.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188716
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Previously the SPI mirroring was using the SMM default
region. If the payload exceeds the SMM default region size
the mirroring won't happen. This causes a slow down. Instead
find a region to mirror into below 4GiB that is marked as
available ram.
Prior to this change 60ms payload times were observed with
current depthcharge builds. With this change the load time is
24ms - 32ms depending on boot type.
BUG=chrome-os-partner:25385
BRANCH=baytrail
TEST=Booted and noted timing.
Change-Id: I201f0fd6cf82f4521e5cb7fafac6ece27951995d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188715
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
PLLP is configured to 408MHz by hardware on T124. Init PLLP is needed only when
to configure it other than 408MHz.
BUG=none
TEST=build nyan and boot kernel.
Change-Id: I8b1abf510ab886e7fddea8864a6d36f12529880e
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/188849
Reviewed-by: Julius Werner <jwerner@chromium.org>
A PLL (Phase-Locked Loop) clock must be locked before it is assigned
as clock source. Otherwise, this clock is unreliable.
Before:
c base(60006080): 48003201, misc(6000608c): 03000000
x base(600060e0): 40009e01, misc(600060e4): 00000000
p base(600060a0): 40002201, misc(600060ac): 00000200
u base(600060c0): 40005001, misc(600060cc): 00000300
d base(600060d0): 48011b0c, misc(600060dc): 40400800
dp base(60006590): 58305a01, misc(60006594): 40000000
After:
c base(60006080): 48003201, misc(6000608c): 03000000
x base(600060e0): 48009e01, misc(600060e4): 00040000
p base(600060a0): 5801980c, misc(600060ac): 00040800
u base(600060c0): 48005001, misc(600060cc): 00400300
d base(600060d0): 48011b0c, misc(600060dc): 40400800
dp base(60006590): 58305a01, misc(60006594): 40000000
BUG=None
TEST=build nyan and boot
Change-Id: I7e5a2eeb5b17f761e0c462ec68a8b221f327fedc
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/188447
Reviewed-by: Julius Werner <jwerner@chromium.org>
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>
The LZMA compression algorithm, currently the only one available, will fail
if you ask it to write more data to the output than you've given it space for.
The code that calls into LZMA allocates an output buffer the same size as the
input, so if compression increases the size of the output the call will fail.
The caller(s) were written to assume that the call succeeded and check the
returned length to see if the size would have increased, but that will never
happen with LZMA.
Rather than try to rework the LZMA library to dynamically resize the output
buffer or try to guess what the maximal size the data could expand to is, this
change makes the caller simply print a warning and disable compression if the
call failed for some reason.
This may lead to images that are larger than necessary if compression fails
for some other reason and the user doesn't notice, but since compression
errors were ignored entirely until very recently that will hopefully not be
a problem in practice, and we should be guarnateed to at least produce a
correct image.
BUG=chrome-os-partner:26060
TEST=Built for link and saw that a segment whos size had been set to 0 now has
the correct size and is loaded correctly. Booted into RW depthcharge which had
been broken before this change.
BRANCH=None
Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187365
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@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>
