There were previously two functions manipulating the
SPI controller state: open_up_spi() and spi_init().
Combine the contents of open_up_spi() with spi_init().
Add the appropriate defintions in the SPI header.
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Built and booted. BCR and SCS register the same, as expected.
Change-Id: I108a3d3f55fa63e52960b6d42adca122547cab47
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185140
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch overhauls the structure of the code that saves SDRAM
parameters to PMC registers for LP0 support, which had formerly been
very close to the U-Boot implementation. The new code keeps the
"translation table" entries as they are, but redefines the macros to
output hardcoded assignments instead of structure entries that need to
be parsed at runtime. It explicitly allows the compiler to merge and
reorder all accesses (under the assumption that PMC scratch registers
are essentially "like memory", without read or write side effects),
which generates much better and more importantly smaller code.
BUG=chrome-os-partner:25062
TEST=Nyan_big boots (on my Norrin, with the required board_id hacks) and
can suspend/resume fine to LP0. Measured (uncompressed) romstage size
for nyan_big at 25K without LP0 support, 43K with the old U-Boot style
implementation and 32K with this patch. Execution time of the function
drops from 1.2ms to .09ms.
Change-Id: Id52577c14d22ee67f167f10c3b976a037b1a321f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184388
This patch ports the code to save SDRAM parameters into PMC scratch
registers (for use by the BootROM on LP0 resume) from U-Boot. The
original "translation table" mechanism stays pretty much unchanged for
now, just simplified a few things and adapted it to our code flow. Gets
called unconditionally from the end of sdram_init() (which means we
won't support this for static BCT-style memory initialization).
BUG=chrome-os-partner:25062
TEST=Installed AVP LP0 handler blob that Dylan pulled out of U-Boot in
/lib/firmware/tegra12x/tegra_lp0_resume.fw. Confirmed that I can LP0
suspend/resume. Also compared PMC register dumps with a U-Boot system
and confirmed that there were no unexpected differences.
Change-Id: I9782967b43741c9ba19e24164a291dff7893ab1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182928
This just moves FB_SIZE_MB to a more suitable location. It was likely
placed in addressmap.h originally since it was together with some
other constants which relied on config variables. But now those are
determined via helper functions instead.
BUG=none
BRANCH=none
TEST=compiled and booted on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9b03839bbe8924c313c45a81af85b3db6f464add
Reviewed-on: https://chromium-review.googlesource.com/184930
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The MemoryType field name should be CamelCase so we can convert directly from
BCT *.cfg files. The enum names for MemoryType are also changed.
BRANCH=none
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: I03d881edcf22a86710e6fb1ff60659b4f999868f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185113
With all the stuff we have been cramming into our romstage lately, 36KB
isn't really going to cut it anymore. While we should think about other
measures to keep our image size down for the sake of boot time, this
patch provides some quick relief to allow us to move on for a while. It
rearranges the iRAM layout to make more use of the pre-0x4000e000 region
after the BootROM is gone and reduces the size of the CBFS cache a bit
in favor of bootblock and romstage.
BUG=None
TEST=nyan_big boots on my Norrin, even if I have 16 SDRAM param tables.
Change-Id: I3072077978b1f34d222f1844491c5c038d433b85
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184240
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This eliminates CONFIG_DRAM_SIZE_MB and uses helper functions to
determine DRAM size dynamically. It impacts MMU setup and BCT
selection in romstage, along with framebuffer setup in ramstage.
BUG=none
BRANCH=none
TEST=built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I41e6b24b853b856026fc26f3b1ee8edf2333ad3c
Reviewed-on: https://chromium-review.googlesource.com/184431
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This adds a method for obtaining DRAM size from memory controller
registers. It is intended as an SoC-specific helper function that
can be used from very early ramstage code.
BUG=none
BRANCH=none
TEST=built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ib8b30e464b1398b78c5ffd8eada88b60d25ebf2b
Reviewed-on: https://chromium-review.googlesource.com/184535
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Since Nyan Big board id pins may layout in tri-state, we need code
to support this change.
We use every two-bit to encode a gpio state as below:
b00: LOW
b01: HIGH
b10: TRI-STATE
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
coreboot log shows "Board TRISTATE ID: 0x41" for gpios 1001
Change-Id: I05d63f0bdafd533ef9d9e0da668837ecd2f4c8c0
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/183855
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Similarly to lynxpoint payload loading can be made faster
by taking advantage of the spi controller's caching and prefetching.
Provide the same mechanism as lynxpoint to provide a 30ms
payload loading savings. The speed up isn't as dramatic as lynxpoint
presumably because baytrail is an SoC without the DMI communication
overhead. Regardless, payload loading decreases from ~55ms to ~25ms.
BUG=chrome-os-partner:25385
BRANCH=baytrail
TEST=Built and did numerous reboots. Observe time savings.
Change-Id: I5726d41559a8b4facb4bfdb7e629d04819dc9d37
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184853
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The linux kernel designware i2c driver supports configuring
HCNT/LCNT and SDA Hold Time for both standard and fast mode.
These have hardcoded defaults when the controller is in PCI
mode but it uses zero if nothign is defined in ACPI.
This adds the same default values that are in the kernel for
the controllers in PCI mode in magic packages that are read
by the kernel.
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: I249b0a217170c7189d633ad97d91361578a1838f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184922
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Previously the GPIO_ACPI_SCI meant generate an SCI
and wake the system. However, when using this configuration
for a device which has its interrupt line going to both
an interrupt pin and the wake pin SCIs are generated in
addition to the normal interrupt. This is unnecessary
and a waste of cpu cycles. Therefore provide the granularity
of waking but not generating an SCI. The GPIO_ACPI_SCI
still implies wake.
BUG=none
BRANCH=baytrail
TEST=Manually. Reconfigured pins with GPIO_ACPI_WAKE. Trackpad
and keyboard still wake the system without causing SCIs.
Change-Id: I437cc4501726835aadc4abf9bbaea3daebf68775
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184718
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to play audio through a HDMI cable the
HDA device needs to be initialized and a the
verb table set up for the HDMI codec. Do this if
the HDA device is enabled.
BUG=chrome-os-partner:24908
BRANCH=baytrail
TEST=Built and booted with kernel changes to handle
baytrail hdmi codec. Benson confirmed sound
does come through hdmi.
Change-Id: I106fd20d8442a7ad7a47a144a1584eb311a0a583
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184710
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The C0 stepping wants the firmware ram information
in the MMIO space. However, the old method for informing
the driver of this location is maintained since there
is a dependency on the driver being updated.
Lastly, fix a bug for LPE in ACPI mode where the incorrect
base address value was being used for the firmware location.
BUG=chrome-os-partner:23791
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=Built and booted on B3. Sound still works.
Change-Id: I747c133c20a330fd59ab2c8b64ac1bdcebaa9cd5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184481
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The toggling of XHCIBAR+80E0h[24] appears to cause the XHCI
controller to be reset on resume. This causes the kernel to
have to reinitialize the controller and all devices.
It seems this bit should only be toggled on boot path, in
the resume path it should be left as 0.
Additionally after routing ports to XHCI don't issue a port
reset to the ports in the resume path.
BUG=chrome-os-partner:25428
BRANCH=baytrail
TEST=build and boot on rambi, suspend/resume and look for usb errors
Change-Id: Ie2f02e4eda502fb670265627ed2968e0d47f3530
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184500
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These can be used by DPTF with the CPU particpant and DTS
in addition to the external thermal sensors.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF application
Change-Id: I15df46183f4da4b2d7c8ee4687a71bff641d6b70
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184442
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This object is used by DPTF for power limiting in the CPU.
It is nominally set to the SdpProfile 2 values.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF application
Change-Id: I55f6a32cd61302dda6103745b22cb7233ad78b0b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184158
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch changes the ENTRY() macro in asm.h to create a new section
for every assembler function, thus providing dcache_clean/invalidate_all
and friends with the same --gc-sections goodness that our C functions
have. This requires a few minor changes of moving around data (to make
sure it ends up in the right section) and changing some libgcc functions
(which apparently need to have two names?), but nothing serious.
(You may note that some of our assembly functions have data, sometimes
even writable, within the same .text section. This has been this way
before and I'm not looking to change it for now, although it's not
totally clean. Since we don't enforce read-only sections through paging,
it doesn't really hurt.)
BUG=None
TEST=Nyan and Snow still boot. Confirm dcache_invalidate_all is not
output into any binary anymore since no one actually uses it.
Change-Id: I247b29d6173ba516c8dff59126c93b66f7dc4b8d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183891
This patch changes several cache-related pieces to be cleaner, faster or
more correct. The largest point is removing the old
arm_invalidate_caches() function and surrounding bootblock code to
initialize SCTLR and replace it with an all-assembly function that takes
care of cache and SCTLR initialization to bring the system to a known
state. It runs without stack and before coreboot makes any write
accesses to be as compatible as possible with whatever state the system
was left in by preceeding code. This also finally fixes the dreaded
icache bug that wasted hundreds of milliseconds during boot.
CQ-DEPEND=CL:183877
BUG=None
TEST=Snow and Nyan still boot. Time between entering romstage main() and
the configure_l2ctlr() call on Nyan drops from 390ms to 0.3ms. Even with
icache turned on the old implementation took 7.8ms since it cleared the
cache multiple times with a slow algorithm.
Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183890
The RAM_CODE on Tegra can be used to determine SDRAM configuration type.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Ica770ed6089f6ff8c38841f2cc8fd2778b6d786f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183781
Reviewed-by: Julius Werner <jwerner@chromium.org>
This adds an ACPI Device entry for the LPE Audio controller
and code to put the device in ACPI mode if set in devicetree.cb
The ACPI device attempts to append GPIOs that may be defined in
the mainboard-supplied ACPI code.
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=manual: Build and boot on rambi with LPE in ACPI mode.
Without kernel support this is not very useful but it did show
that the device was no longer visible as a PCI device.
Change-Id: I44d5423f5bbea77e156012c071df6cb335fe658b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184006
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
To support memory initialization without BootROM (which allows better
customization, updatable DRAM init procedure, and supporting more SDRAM
configurations that BootROM cannot handle), a new function "sdram_init(param)"
is introduced.
The input must be a "struct sdram_params", which has exactly the same layout as
the SDRAM fields in standard BCT file.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # Boots successfully
Change-Id: I36a26fb5236eee8f329e3f84cbdcc1ec6992fe6b
Reviewed-on: https://chromium-review.googlesource.com/182615
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
The new clock_sdram(...) initialized PLLM by given configuration (which needs to
be explicitly determined, usually from BCT or SDRAM parameters).
BUG=none
TEST=emerge-nyan chromeos-coreoot-nyan
# With other patches, the new function starts PLLM in correct clock.
Change-Id: I606d0506c734d312db9e1b72a910700ca766f2d3
Reviewed-on: https://chromium-review.googlesource.com/183621
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
The _PRW method needs to specifcy a bit number within
the GPE block to enable wake events associated with a
given device. Therefore, add ACPI_ENABLE_WAKE_SUS_GPIO()
macro for the mainboards' convenience.
BUG=chrome-os-partner:25251
BRANCH=baytrail
TEST=On rambi used macros for touch pad and screen. Noted
the appropriate bit was enabled for wake. Also was
able to wake with the track pad.
Change-Id: I98d7c005997bdcaa3646fabec5199fbe013ca52c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183597
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Provide an option for the mainboard to set in its devicetree
to disable slp_x stretching on SUS power well failure. This
will allow for fast G3->S0 transition instead of waiting for
1-4 seconds.
BUG=chrome-os-partner:25269
BRANCH=baytrail
TEST=Manual. Enabled option. Put board in G3. Pressed power button
and noted startup time on the EC console.
Change-Id: I213525b3ad44fe4c95bfd014b614bbc80623cbb8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183587
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The VNN and VCC regulator for baytrail can enter
into PS2 mode under low power conditions to save
regulator power. This is available for >C0 parts.
Add a device tree option to enable PS2 for the
VCC and VNN rails.
BUG=chrome-os-partner:24542
BRANCH=baytrail
TEST=Built and booted b3.
Change-Id: Iea952b17ca77ac42f34285b2d171e566b755e002
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183595
The C0 cpuid's were added as well as the microcode, but we
weren't making C0 a first class citizen in the pattrs.
BUG=chrome-os-partner:24542
BRANCH=baytrail
TEST=Built and booted b3.
Change-Id: Ie23f8ce867f339eab3b55b8c5f49ab822f23eebb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183594
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The EMC registers are required for memory initialization.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Ibfb35d5b3f44c97c2c36135110fa44996447734c
Reviewed-on: https://chromium-review.googlesource.com/183622
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The EMC address was wrong and may cause memory initialization to fail.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Iaa8f21a6ba2d3850495da9a85711cf7fb7b09ad4
Reviewed-on: https://chromium-review.googlesource.com/183602
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
The updated MRC wrapper allow the IO hole size to be
configured from the coreboot side of things.
BUG=None
BRANCH=baytrail
CQ-DEPEND=CL:*152595
TEST=Built and booted. Also changed io hole size from mainboard as test.
Change-Id: I7a626764aecce94bbaf35d884606480f22a9aa84
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183269
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This adds the very basic top-level support for determining the
system wake source from ACPI. It only implements the _SWS method
in the _SB scope which just returns a bit index into the PM1
status register for the first fixed functional block.
This can be used to determine wake source of RTC or Power Button
but does not help determine wake source for USB or GPIO.
The ACPI spec says to return -1 if no source can be determined
from PM1 status register.
BUG=chrome-os-partner:8127
BRANCH=baytrail
TEST=build and boot on rambi
1) Test resume from S3 by RTC:
ACPI System Wake Source is PM1 Index 10
(bit 10 is RTC_STS in ACPI spec, ACPI_EVENT_RTC in kernel)
2) Test resume from S3 by power button:
ACPI System Wake Source is PM1 Index 8
(bit 8 is PWRBTN_STS in ACPI spec, ACPI_EVENT_POWER_BUTTON in kernel)
3) Test resume from S3 by USB:
ACPI System Wake Source is PM1 Index -1
Change-Id: Ifc5c0867f82cf291af157537b8c13fe44923d8f5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183333
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are several things in GNVS being initialized in the
mainboard ACPI table creation step that are shared across all
boards using the chipset.
Move the init that is not board specific into a shared function
and call it from the table creation step.
BUG=chrome-os-partner:8127
BRANCH=baytrail
TEST=build and boot on rambi device
Change-Id: I178193d7fe298ec26247402370a1af9280bb09c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183332
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update the microcode for c0 parts to 809.
BUG=None
BRANCH=baytrail
TEST=Built and booted on B3.
Change-Id: I733ce8eeae0b0eafe4a3a2dbeb09feba051c496a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183256
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The sdram_param.h from cbootimage has different type and #ifdef names that
should be changed to comply with Coreboot.
Note we also changed field names so it will be easier to cope with translating
BCT config file (*.cfg) into simple C structure definition.
BUG=none
TEST=none
Change-Id: I41fbc628da920863b4ae3d8795cb6dfe4fd31dca
Reviewed-on: https://chromium-review.googlesource.com/182614
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
A raw copy from NVIDIA cbootimage:
http://nv-tegra.nvidia.com/gitweb/?p=tools/cbootimage.git;\
a=blob;f=src/t124/nvboot_sdram_param_t124.h
This file containts required structure for initializing SDRAM.
BUG=none
TEST=none # The file is not used yet.
Change-Id: I580f7a86af84bc0fd8d88c4b59606893e73ea01c
Reviewed-on: https://chromium-review.googlesource.com/182613
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
To initialize memory without BootROM, we need more details in the PMC registers,
including "io_dpd3_req", "por_dpd_ctrl", and various mask values.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # successfully.
Change-Id: I5444e64f49a66320319a5c59ce14635364b74f39
Reviewed-on: https://chromium-review.googlesource.com/183231
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
To implement memory initialization without BCT, we need more details of memory
controller registers (mc).
Note some register names have been changed, so Nyan mainboard VPR code is also
modified.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # successfully.
Change-Id: I179aa41c5a6419fc94cc3343ff23080d1db19ca2
Reviewed-on: https://chromium-review.googlesource.com/182992
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
This blob is loaded by the kernel and is what runs immediately after resuming
from lp0. It turns on the main CPUs and returns control to them and runs on
the AVP. The directory is totally independent from coreboot and has its own
Makefile. The only external dependency is on the stdint.h header file. The
openssl command line utility is used to sign the blob. Its header is defined
in C and built as part of the image.
BUG=None
TEST=With changes to coreboot which save the SDRAM parameters for use by the
boot ROM, used this blob to suspend and resume using LP0. USB had to be
disabled because those drivers don't work across suspend and resume.
BRANCH=None
Change-Id: I056a1f9ad3fa333f5b1ca140c8b7be819ffa11c7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/183152
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
I messed up in setting this register, it should be using Tj_max-Temp
which in the default case works out to be 90-90=0.
This was apparently heavly throttling the CPU at idle temps.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, run graphics_WebGLPerformance test
Change-Id: I4338280cf50db84dc44313d6fb6771ea5af21dad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
These values are for the 2 and 4 core B-step parts.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=boot on rambi and check for valid GPU power values from DPTF
Change-Id: I2772cb9dbf17560fc31f871a111f32131c7e5105
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 701273892c7bdaf898a94a337fae9f7373a9c748)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183102
Add support for initializing the rtc device. Also
add RTC well loss events to the eventlog and properly
clear the event so it doesn't get added again.
BUG=None
BRANCH=baytrail
TEST=Built and booted. Tested battery loss. Eventlog
has RTC event. In addition the rtc device can
be properly probed in the kernel resulting in
/sys/class/rtc/rtc0 being available.
Change-Id: I1ca608b069dc50db116d75963d5542a7f9b1811f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183051
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Apply the SOC thermal settings from DPTF reference code for
SdpProfile=4 and adjust graphics PUNIT setting to match.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=boot on rambi and check for valid GPU power values from DPTF
Change-Id: I59fc4b75b52084ebcc4c0556563afca0585ea6b8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182786
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Though the limited documentation indicates the default is
0 for the gfx_turbo_disable bit, in practice that isn't
true. Knock down the gfs_turbo_disable bit to enable
graphics turbo mode.
BUG=chrome-os-partner:25044
BRANCH=baytrail
TEST=Built and booted. Added debug code to output SB_BIOS_CONFIG.
Noted that bit 7 was set to 0.
Change-Id: I11210c6a0b29765cb709a54d6ebd94211538807b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182640
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On baytrail, it appears that the turbo disable setting is
actually building-block scoped. One can see this on quad
core parts where if enable_turbo() is called only on the
BSP then only cpus 0 and 1 have turbo enabled. Fix this
by calling enable_turbo() on all non-bsp cpus.
BUG=chrome-os-partner:25014
BRANCH=baytrail
TEST=Built and booted rambi. All cpus have bit 38 set to 0
in msr 0x1a0.
Change-Id: Id493e070c4a70bb236cdbd540d2321731a99aec2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182406
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This will allow USB devices to wake the system (if 5V is not turned off)
and the controller to enter D3 at runtime. (if autosuspend is enabled)
BUG=chrome-os-partner:23629
BRANCH=baytrail
TEST=build and boot on baytrail
1) with modified EC to leave 5V on in S3 ensure that waking from suspend
with USB keyboard works.
2) with laptop-mode-tools usb autosuepend config updated see that device
enters D3 at runtime when no external devices attached.
Change-Id: Ia396d42494e30105f06eb3bd65b4ba8b1372cf35
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182536
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182212
Reviewed-by: Gabe Black <gabeblack@chromium.org>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
BUG=None
TEST=Snow still boots.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The current byte value was being converted to an int
when checking against literal 0xff. As the type of
the current pointer was char (signed) it was sign
extending the value leading to 0xffffffff != 0xff.
Fix this by using an unsigned type and using a
constant type for expected erase value.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmwareupdate. Noted that MRC
cache doesn't think the erased region isn't erased.
Change-Id: If95425fe26da050acb25f52bea060e288ad3633c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182154
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
