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>
Disable VC setting for HDA so hdmi audio choppy issue will be eliminated.
Change HDA initialize steps to sync with UEFI reference code.
BUG=chrome-os-partner:25651
BRANCH=Baytrail
TEST=Does not have choppy noise during video playing
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Change-Id: I45d49123d369b7d075776215e709af5801ea696d
Reviewed-on: https://chromium-review.googlesource.com/186024
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
Without a prompt the config option will always stay 0
due to the way Kconfig works.
BUG=chrome-os-partner:25387
BRANCH=panther
TEST=Boot into dev mode with Mohammed's TV screen, see
the dev mode screen appear.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ib7d9ec82b4a4a29daddc29aa7702fc420279017d
Reviewed-on: https://chromium-review.googlesource.com/185970
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Repurpose config->pwm to mean the particular PWM device (we use PWM1 on
nyan), and add code to program the PWM device.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan, regenerate bootimage, and boot.
See that the backlight comes up in the bootloader, and brightness can be
adjusted via pwm_bl driver in the kernel.
Change-Id: I2db047e5ef23c0e8fb66dd05ad6339d60918d493
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185772
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Add some defines and structs that describe what the PWM registers look like.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Ie10589e4cbf5292e543d205ac8a1c6b09a0f76d0
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185771
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
The NVM routines weren't propagaing the error codes up
the stack properly. Additionally, padding at the end
wasn't being zero'd correctly as the size of the cache
metadata wasn't being taken into account. The mrc_slot_valid()
wasn't failing as one would expect because of a fence post
issue. These changes should make debugging in this area a lot
easier in the future.
BUG=chrome-os-partner:25577
BRANCH=baytrail
TEST=Was able to identify errors when erasing failed.
Change-Id: I6a93586237763facb0a672d579b9b97ec6968440
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185875
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ich_status_poll() routine was only waiting 60ms for
a command to complete. This is fine for writes, but when
needing to perform a sector erase it can take a lot longer
as the SPI parts for baytrail operate at 1.8V. Using the
W25Q64FW as a worst case scenario increment the timeout to
400ms.
Measuring on a specific device the sector erase command was
taking on the order of 120ms.
BUG=chrome-os-partner:25577
BRANCH=baytrail
TEST=Filled MRC cache contents. Then rebooted and noted the
ability to erase properly.
Change-Id: I3f2ed930eaff86d8bd32dfee7b5f018852c7adeb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185874
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Configure pin H1 for PWM1, and enable the PWM clock.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: I2f91ebd4666bd227686c08cedf3c1aa7abbe8215
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185770
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
It seems that someone just stuck the PM3 function for all of the potential
PWM pins. Fix this to be more specific to the particular PWM (of which
there are four).
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Ic61a7321fbe28953b22007a1d0b522c3ca8714ad
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185739
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
The Tegra PWM base address was missing, so add it.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Iebf687c6644290e05ee72794cde697658ab6d7cb
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185738
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
We'd been putting some data structures like the framebuffer and the cbmem at
the end of memory, but that may not actually be addressable as identity mapped
memory. This change clamps the addresses those structures are placed at so
they stay below 4GB.
BUG=None
TEST=Booted on nyan. Went into recovery mode and verified that there was a
recovery screen. Forced memory size to be 4GB and verified that the recovery
screen still shows up.
BRANCH=None
Change-Id: I9e6b28212c113107d4f480b3dd846dd2349b3a91
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185571
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
If an asm blob isn't marked as volatile, gcc is free to throw it out if it
doesn't think it produces any values that are actually used. To prevent that
from happening, add volatile to some asm blobs in the nyan romstage code.
BUG=None
TEST=Booted on nyan rev1.
BRANCH=None
Change-Id: I819e068e738e94ea749fcb72bba2eee080e1dfb1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185610
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Define a table detailing the charger performance states for
the rambi device and enable the charger participant in DPTF.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF and heat up
device to see the charger current limited as expected.
Change-Id: I35a46da7f53cb95cd3d06bec9d71ef721c61e387
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185760
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that the EC supports limiting charger current we can
fill out the placeholder charger participant.
The charger performance states table is moved to the
mainboard dptf configuration so it can be tuned for the
actual charger/battery in a device.
The method to retrieve the number of performance states
is implemented based on whether or not the device is
connected to AC power. There may need to be a hook that
issues a Notify to DPTF to have it re-execute this method
if the AC power state changes, but I have not found it yet.
The method to set charger current is implemented to find
the control value in the charger performance states table
and pass that value to the embedded controller.
An init function is defined which will disable the charger
current limit.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF and heat up
device to see the charger current limited as expected.
Change-Id: I531fa5903b9ef11573c31e96b7ecfe0a8a4d3c23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185759
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update the ec_commands header (direct from EC source) and
add support for the new charger current limit interface
which will be used by DPTF.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF and heat up
device to see the charger current limited as expected.
Change-Id: Ia9a2a84b612a2982dbe996f07a856be6cd53ebdb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185758
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On rambi there is an external 10K pull up while the hardware
resets GPIO_SUS[06]'s config to 20K pull down. These pulls
are fighting creating a voltage that when read as a digital
value is incorrect. Rectify this by disabling the intnernal
pull down.
BUG=chrome-os-partner:25641
BRANCH=baytrail
TEST=Built and booted. crossystem wpsw_boot is now correct.
Change-Id: I5f52c639e209ee75a41da8bd6ab4d1a9ae8fce16
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185741
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Currently gpios are set up in ramstage, but there
are cases where gpios need to be interrogated in
romstage and the reset state of the gpio config does
not allow reading the correct values. So far all
those cases can be resolved by disabling the internal
pull. Therefore, provide this functionality to all
users and convert rambi over to the common API.
BUG=chrome-os-partner:25641
BRANCH=baytrail
TEST=Built and booted.
Change-Id: I53ecf24e55b6d2efb1eaee3787734178d6961fcf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185740
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Rambi uses a W25Q64FW. Allow for the the following commands when
the SPI controller is locked down.
0x01 - Write Status Register
0x02 - Byte Program
0x03 - Read Data
0x05 - Read Status Register
0x20 - Sector Erase
0x9f - Read ID */
0xd8 - Block Erase
0x0b - Fast Read
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Built, booted. Confirmed registers were programmed correclty.
Events were still logged correctly.
Change-Id: Ie5a50d05e8f8e3fecf3145fa721e1fae71e070dc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185632
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
A mainboard_get_spi_config() is introduced to provide the
configuration details for locking down the SPI controller.
Honor those settings and lock down the SPI controller
in finalize_chipset().
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Built and booted with accompanying mainboard change.
Noted SPI controller was locked down. Also confirmed
event log entries were present for shutdowns and suspends.
Change-Id: Ie3f746ec1051bd46836992640f68dcc52753b1a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185631
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On the SMM APM_CNT_FINALIZE step re-initialize the SPI
controller so that it can still log events after the SPI
controller has been locked down.
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Built and booted. Events still logged after SPI controller
has been locked down.
Change-Id: I41a3e12c0398303e74f95eb6df82d5bc4303898b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185630
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The HDA device needs to be enabled so HDMI can
get audio on its interface.
BUG=chrome-os-partner:24908
BRANCH=baytrail
CQ-DEPEND=CL:176293
TEST=Built and booted with kernel changes to handle
baytrail hdmi codec. Benson confirmed sound
does come through hdmi.
Change-Id: I6dedbfbae1eff13f03285982f7adfbdffa0d27de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184574
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
This patch slightly revises the way the dynamic SDRAM parameter tables
are stored in the source tree for nyan and nyan_big. The parameter files
are named sdram-<vendor>-<size>-<freq>.inc (moving frequency last so
that files that belong to the same board/ram_code will be together in
directory listings). There is also an sdram-unused.inc file that
contains an empty "dummy" configuration for unused ram_codes. The
inclusion list in sdram_configs.c is annotated with comments to avoid
confusion about which line corresponds to which ram_code.
Also added another check for MemoryType to sdram_init(), just to be
sure.
BUG=None
TEST=Built and booted Nyan and Nyan_Big successfully.
Change-Id: If1406b8d36a37283701c5c272137b34f4324636f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185286
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The boot counter was always being incremented even
on S3 resume. Just increment the boot count on
non-S3 resume boots.
BUG=chrome-os-partner:25577
BRANCH=baytrail
TEST=Boot. Note boot count. Suspend Resume. Reboot. Note difference
in boot count of 1.
Change-Id: I76a846f6fbf20c4cee3e1f652ae43b4048ce4b3a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185381
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Rambi doesn't need to do anything in the finalization
step. Remove the case in the switch statement.
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Built and booted. Suspend/Resumed.
Change-Id: Idf493d3dc5d06a0277050152c2245efa9b92c32e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185203
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Instead of relying on the bootloader or each mainboard
to invoke SMM finalization have the chipset control
when it is done.
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Booted and resumed with SMI debug. Noted SMI.
Change-Id: Ifee071fe5704296b896188b26740094344ad756f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185201
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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
