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>
Otherwise git status shows 3rdparty as an untracked file.
BUG=None
TEST=Ran git status and saw that 3rdparty was no longer mentioned.
BRANCH=None
Change-Id: Ia4cf88231cdb901ea11b52c88e6eac681f9300c0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185600
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@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
To support arbitrary numbers of memory configuration, we are now ready to remove
SDRAM configurations from BCT and do SDRAM initialization in ROM stage.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # Built successfully.
BRANCH=nyan
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Change-Id: I06387075813f4f179323e264c4c0077445944291
Reviewed-on: https://chromium-review.googlesource.com/185114
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Tom Warren <twarren@nvidia.com>
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>
With git submodules, you also have to `git rm` it after deleting the
.gitmodules file otherwise git remembers it.
Thanks to Gabe & Hung-Te Lin.
BUG=None
TEST=`git status` no longer complains about 3rdparty being modified
BRANCH=none
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Change-Id: I29d78517e774745648a4cef0d58f6235b384b8c4
Reviewed-on: https://chromium-review.googlesource.com/185133
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
To support arbitrary numbers of memory configuration, we are now ready to remove
SDRAM configurations from BCT and do SDRAM initialization in ROM stage.
BUG=none
TEST=emerge-nyan_big chromeos-coreboot-nyan # Built successfully.
BRANCH=nyan_big
Change-Id: Id8673b9ec8c59e450d195758492d8e3484e02edc
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183624
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>
These are cut from the hybrid 2/4GB BCT cfgs I
received, using just the 4GB section. Diffed against
the 2GB BCT cfgs already present and found logical
differences (mem size, etc). Untested as I have no
4GB system here.
These are named with the RAMCODE, speed and size
encoded in the filename. The CFG2INC script/tool
can use this info to place them at the proper
offset in the ramcode table as needed.
BUG=none
TEST=none, no code ready yet to receive these BCTs.
BRANCH=none
Change-Id: I5f8abc1e3b241064631cfa66c7f97c1804d9f9d4
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/184159
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@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>
GPIO_ACPI_SCI implies wake and generating an SCI. This
is unnecessary. Therefore, configure the intended wake
pins to only just wake by using GPIO_ACPI_WAKE.
BUG=none
BRANCH=baytrail
TEST=Manual. S3 resumes from keyboard and trackpad. No
excessive SCI's are generated.
Change-Id: I0b841e64909301e8d4789183ad53a016be7120f1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184719
Reviewed-by: Duncan Laurie <dlaurie@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>
This applies the same changes from 07a3592 that were applied to nyan.
BUG=none
BRANCH=none
TEST=it compiles.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Idcbe85436d7a2f65fcd751954012eb5f4bec0b6c
Reviewed-on: https://chromium-review.googlesource.com/184551
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@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 kernel drivers have all been updated to use ACPI ID probing
methods and we can now put the I2C controllers in ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=build and boot on rambi, test that trackpad, als, sound still work
Change-Id: I50603eb48a557a5e82fd6510e42940a1f5379b87
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184530
Reviewed-by: Aaron Durbin <adurbin@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>
The rest of the thermal configuration is in DPTF ACPI code so
move the CPU settings there as well.
Also remove the unused thermal.asl file.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF application
Change-Id: I9048e5d4504328603f34e5d0e14c110fdda01f67
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184443
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
This patch fixes the remaining few bugs in our shiny new cache iteration
by set/way/level algorithm to actually make it work: It makes it start
from cache level 0 (previously it would always start at LoC and be
"done" instantly), fixes up the two shifts that isolate the set bits at
the end (which didn't seem to account for the fact that the first shift
affects the second), and throws an S bit on that last shift so that it
actually affects the conditionals after it.
In addition, also moves the next_level block to the top so that we can
share (and thus eliminate) some code at initialization, and turns the
whole thing into a thrice-instantiated macro to create functions that
fit our existing interface.
BUG=None
TEST=Ran with cache_test code (see separate CL) and closely examined the
resulting output. Made sure results look as expected (iterating through
all sets (inner) and ways (outer) for L1 and then L2 cache, extracting
the right numbers from CLIDR and CCSIDR, not touching anything twice).
Time for a single dcache_clean_invalidate_all() on Nyan drops from 3.7ms
to 0.3ms.
Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183879
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch pulls in NetBSD's full cache flushing algorithm for ARM, to
replace our old, slow and slightly overzealous C-only implementation.
It's a beautiful piece of code that manages to run on only caller-saved
registers (meaning it doesn't need to write to memory) in a very tight
loop, and it's BSD-licensed to boot (which we need for libpayload).
Unfortunately it's also not quite correct, but I can fix that. Pulling
the original in a separate commit to make it more obvious what changes
are mine.
BUG=None
TEST=None
Change-Id: I7a71c9e570866a6e25f756cb09ae2b6445048d83
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183878
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Cherry-picking https://chromium-review.googlesource.com/183833 for nyan_big.
BootROM uses RAM_CODE[3:2] value as index to retrieve boot device
array in BCT to reconfigure device. Since there will be one kind
of boot device, we can reuse RAM_CODE[3:2] in conjunction with
RAM_CODE[1:0] to select up to 16 RAM parameters. To support this
change without leading BootROM to read wrong boot device parameters,
we need to fill up boot device array.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan # boots successfully.
Change-Id: I0eb37ecf65ca041fe2f10c426b8dfbaafee24b2d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184076
Reviewed-by: Julius Werner <jwerner@chromium.org>
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>
