- Update RAM_ID table.
- Add DEVSLP0 signal to NGFF SATA port.
Note: After this change, old Micron 2GB boards will no longer boot.
BUG=chrome-os-partner:20295, chrome-os-partner:20308.
TEST=None.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id68a1d6ace2702cca9c37305726cd55a0bde5005
Reviewed-on: https://gerrit.chromium.org/gerrit/60167
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
RAM_ID0 was used as the table MSB, and RAM_ID2 as the LSB. This is the
opposite of expected. Reverse these two GPIOS to make current boards
work. For future boards, we will change the signal names on the
schematic to be consistent.
TEST=Manual. Build image, verify Hynix board loads correct SPD.
BUG=chrome-os-partner:19636.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I044e7ee696f19fe6fd5911e17317190832f675c5
Reviewed-on: https://gerrit.chromium.org/gerrit/60162
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
The display port bridge on pit is different from the one on snow and needs to
be initialized differently. Instead of waiting for the chip to come up on its
own and assert the hotplug detect, we need to access it over i2c and get it up
and running ourselves.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit and saw that the video
initialization code in coreboot worked better, successfully training the link
but then failing elsewhere later on.
BRANCH=None
Change-Id: I926f9cce182308dc4a50abdb8ab684109ed95f17
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60604
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I0b7565bbfa5f9a4c7d0bd84f763c71032d12f379
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60603
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This driver is basically the same as the one in U-Boot but without the device
tree stuff. That driver is, in turn, a straightforward implementation of the
sequence of register writes described in the data sheet. Comments were added
in U-Boot which helpfully describe what the register writes are actually
doing and are kept.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit and verified that after the
bridge was initialized, the link was initialized successfully.
BRANCH=None
Change-Id: Id4714780c7707325a8dff1cf424d9feb1c367cda
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60602
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Built and booted into ChromeOS
on snow.
BRANCH=None
Change-Id: Ib01c0218b95d8660418fea2181f6f38bc0675159
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60601
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This was removed from ramstage a little while ago and should have been removed
from here as well.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I55bc0806597de51c411aadf55d7c8ea5e3175821
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60600
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
In some header shuffling stdint.h no longer included a definition
for NULL. Pull in string.h for the proper definition. Also, disable
the xHCI controller in libpayload as the firmware leaves control
of the USB 3.0 ports to the EHCI controller.
BUG=None
BRANCH=None
TEST=Was able to boot in in non-dev mode. In dev mode there were no
longer errors about the xHCI controller.
Change-Id: Iabf15b3b17d88784e0718dc9f0fd885e6551e0b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60874
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This appears to be needed, though we have no way to test yet.
BUG=None
TEST=it builds
BRANCH=None
Change-Id: I1fe20b35b0fc73ecfd7207c368a9ead89a097e70
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60159
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Newer mainboards that use haswell -- and, presumably, chipsets to come -- need
some support functions. Add them in the drivers/intel/gma directory.
Currently, this is one file: intel_ddi.c, but more may come.
Compilation of this file is controlled by INTEL_DDI, defined
in the Kconfig as default n and used in the Makefile.inc
BUG=None
TEST=builds and boots on the FUI tree that uses it.
BRANCH=None
Change-Id: I501ee291c0d4589925ed3e478f67106337fcad31
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60612
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
BUG=None
TEST=Build and boot slippy with these changes
BRANCH=None
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Limit power to 12W at 73C and remove limit at 68C.
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual:
To have the CPU consume maximum power it is necessary to stress
both the CPU and the GPU. Bastion (chrome.supergiantgames.com)
and/or webglsamples.googlecode.com can be useful for this.
Testing this properly requires a script to report the running
average power readings. The watch_power.sh script is attached
to this issue in the partner tracker.
1) Run watch_power.sh continuously:
localhost ~ # watch -n 0 bash -e /tmp/watch_power.sh
2) Start Bastion (or other stress apps). The power draw should
be close to 15W if under enough load.
3) Watch until temperature climbs above 73C and is caught by
the thermal zone 10 second poll, this can be sped up by blocking
or removing the fan.
4) The ACPI thermal zone states should change to reflect that
active[2] is now enabled and power consumption should drop to 12W.
5) Stop the stress apps and wait until the CPU cools off again,
enable the fan again if it was removed.
6) The ACPI thermal zone state should switch back to active[3].
Change-Id: Ie6714a8543d4f06edf8513086fc9c968273bdb23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60545
Add ACPI Methods to enable and disable power limiting with PL1.
This can be used in ACPI Thermal Zone or in EC ACPI _QXX events.
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
This commit adds new unused methods and is fully tested with the
subsequent commit that makes use of these methods.
Change-Id: I9d8d23bfe9cf7c756ff8ab0412e5a010826b12db
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60546
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual:
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
In resume path, if memory setup takes too long without setting PS_HOLD, EC watch
dog may power off or reboot the system. To prevent that, we should enable
PS_HOLD in same timing as cold boot - right before starting memory setup.
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow
BRANCH=none
Change-Id: I187b85d5ff17774dc83efe5c72d61caff1543113
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60335
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The functions which manipulated the tps65090 were removed a while ago because
it isn't accessible directly from the AP, it's on an I2C bus that has to be
accessed by the EC on our behalf. Now that that capability has been added, we
can rewrite the small portion of the the tps65090 we actually used but using
the EC passthrough commands.
Also, we should not be configuring the hardware display port hotplug detect
line since we're using it as a GPIO for other purposes. The GPIO we're using
instead defaults to being an input, but to be safe we should probably
explicitly configure it as one anyway.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Verified that the registers
read from the tps65090 were reasonable, and that the registers being set
should correspond to the FETs that are being turned on. The display isn't
working yet so these functions couldn't be completely verified.
BRANCH=None
Change-Id: Ie70a7f659d02ddba8ca416fbb571870080a84ea8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60517
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Used the function to read and
write i2c registers on the tps65090 and verified that they were consistent
with expected values and were affected by writes in a reasonable way.
BRANCH=None
Change-Id: I57ea6be8b81e31191399a7457ef5106c56f7f27d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60516
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
BUG=None
BRANCH=None
TEST=Built and ran a 8MiB image on a 16MiB flash part.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Intel GMA driver is in, this CL splices in the Makefile bits.
BUG=None
TEST=Build and boot falco
BRANCH=None
Change-Id: Icf42a537575b8cc90a679ec1fc15b09294630611
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60346
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
The ChromeOS EC for peach_pit is connected to SPI2 bus, not I2C.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: I4a14cf21e7564102090e0dc26ea16dede3fc42b2
Reviewed-on: https://gerrit.chromium.org/gerrit/60087
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The workaround of re-opening device in exynos_spi_read has been fixed by the new
correct open/close and xfer procedure. It's safe to be removed now.
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit; # Successfully boot on pit.
BRANCH=peach_pit
Change-Id: I85d80a5298bbec09b4b731e83dd7bd1d97b3e039
Reviewed-on: https://gerrit.chromium.org/gerrit/60086
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Switch spi_xfer and exynos_spi_read to use the new spi_rx_tx function.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit; # Successfully boots on pit.
BRANCH=peach_pit
Change-Id: I46dae4d604c8b78bec5aaeb8778dfad635e657b1
Reviewed-on: https://gerrit.chromium.org/gerrit/60085
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The SPI driver (exynos_spi_rx_tx) was implemented with only "read" ability and
only full-duplex mode. To communicate with devices like ChromeOS EC, we need
both output (tx) and half-duplex (searching frame header) features.
This commit adds a spi_rx_tx that can handle all cases we need.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: I4f216c42e2d9a1930e8c169e3cdd082ba7918357
Reviewed-on: https://gerrit.chromium.org/gerrit/60084
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The original Exynos SPI open/close procedure was copied from U-Boot SPL with
some assumptions that only works in SPL stage. For example, it tries to always
work in 4-byte transmission mode with only RX data is swapped, and claims a
packet for initial address command (and with incorrect size).
This commit revises open/close and reset so only the required SPI registers are
configured.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: I8c16d539f6aebd14182846ced5afa7a9457890e4
Reviewed-on: https://gerrit.chromium.org/gerrit/60083
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Fill the SPI device parameters for spi_setup_slave on Exynos 5420.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: I447e877332451a0172e2530f3f127343f8a730c3
Reviewed-on: https://gerrit.chromium.org/gerrit/60082
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The SPI module in Exynos 5420 didn't follow Coreboot's SPI API standard
(spi-generic.h) and will be a problem when we want to share SPI drivers.
This commit replaces exynos_spi_* by spi_* functions.
Note, exynos_spi_read is kept and changed to a static function because its usage
is different from the standard API "spi_xfer".
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: Iadd14bcedbe97aacecd490d97f6ca17c4097e4a5
Reviewed-on: https://gerrit.chromium.org/gerrit/60081
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Add SPI0 and SPI2 to Exynos 5 SPI list, and correct structure names.
Also removed the un-enumerated devices (SPI_BASE, base_spi()).
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: I059dbd778dc37633c59702050965632b7b22e685
Reviewed-on: https://gerrit.chromium.org/gerrit/60079
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
For devices with ChromeOS EC on SPI bus, use the standard SPI driver interface
(see spi-generic.h) to exchange data.
Note: Only EC protocol v3 is supported for SPI bus.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=peach_pit
Change-Id: Iefea401cad2163b429a548b35545c6bd2c5cacf3
Reviewed-on: https://gerrit.chromium.org/gerrit/60078
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Add the new Chrome EC protocol version 3 to Coreboot.
Note, protocol version 3 is not applied on any bus implementations yet.
LPC (x86) and I2C (arm/snow) are still using v2 protocol. The first one to use
v3 protocol will be SPI bus (arm/pit). LPC / I2C will be updated to v3 only
when they are ready to change.
BUG=chrome-os-partner:20257
TEST=emerge-daisy chromeos-coreboot-snow; emerge-link chromeos-coreboot-link
BRANCH=none
Change-Id: Ica48b56cb9c7ca0fccb1375de45cee16fbbc100e
Reviewed-on: https://gerrit.chromium.org/gerrit/59670
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
These functions are not all used yet, but do compile and are partially used
in the FUI testing.
They were extracted from the 3.4 kernel using coccinnelle filters. The .c files
are only compiled in if CONFIG_INTEL_DP is set.
BUG=None
TEST=Build and boot on falco and slippy with and without these compiled in and used
BRANCH=None
Change-Id: Id95622a75aa02b496c9ea4717cb143394a8332e3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60245
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Removed two unnecessary register sets, and did the power well a bit
more correctly. Also, added a register definition include file so we can
used constants instead of magic numbers.
We also set registers to common initialized values that are
needed for FUI, VBIOS, and kernel. This set of registers
appears to be an absolute bare minimum. Since we're hoping to use
FUI for all chipsets from this one forward, we unconditionally do the
setting here.
BUG=None
TEST=build and boot with FUI. Then build and boot with VBIOS and a
kernel. As before, remove the VBIOS image to fully test that the
kernel can work without the VBIOS at all.
BRANCH=None
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Change-Id: Ife3f661ba010214d92b646b336f2b06645119f17
Reviewed-on: https://gerrit.chromium.org/gerrit/59988
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
The new edid functions support converting the edid to an lb_framebuffer.
Use them. Also, since panels seem to set bits per color instead of bits
per pixel, just force the right value in the edid struct.
Add helpful comment because people don't always believe we need to set
the pallette.
While we're at it, fix a problem that caused it to not compile.
BUG=None
TEST=build and boot and get graphics.
BRANCH=All
Change-Id: I645edc4e442d9b96303d9e17f175458dc7ef28b6
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer
since it was defined in sandybridge. It is really
more of an x86 thing however.
I considered making this more general, since it technically
can apply to PTE-based systems like ARM, and maybe we should.
BUG=None
TEST=abuild
BRANCH=None
Change-Id: I93d2daa2eff06ddd8cd7cd2e9d5beb8208115506
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57219
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Since EC protocol v3, the packet format will be the same for all buses (inclding
I2C, SPI, and LPC). That will simplify the implementation in each individual bus
driver source file.
To prepare for that, we will move the protocol part into crosec_proto.c:
crosec_command_proto, with bus driver in callback "crosec_io".
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow # built successfully.
BRANCH=none
Change-Id: I5d59d5922cbe68f4e838d01de530d8a5e57eb2b2
Reviewed-on: https://gerrit.chromium.org/gerrit/59244
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
The Embedded Controller (EC) for Pit is connected via SPI2, and needs to be
configured before we can talk to it.
BUG=chrome-os-partner:20441
TEST=emerge-peach_pit chromeos-coreboot-peach_pit; boot successfully.
BRANCH=none
Change-Id: Ic260d89a4aad0633868800af9c331ce8cf7a518f
Reviewed-on: https://gerrit.chromium.org/gerrit/59751
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
- updates from 1.6.0 ref code
- remove the step comments as they are no longer even close
- add constants for LPT revisions
BUG=chrome-os-partner:20453
BRANCH=none
TEST=manual: build and boot on Falco
Check that RCBA+2300[1] is set:
> mmio_read32 0xfed1e300
0x00000002
Change-Id: I8b3c5fda3f3170455699a7834239cb991603e7a8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59821
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some initialization / shutdown commands should be paired correctly in a SPI I/O
session. For example, setting CS should be enabled and disabled in each read;
and the bus width (byte or word) should be configured only when opening /
closing the SPI device.
BUG=none
TEST=manually: emerge-daisy chromeos-coreboot-snow; boot on Snow.
BRANCH=none
Change-Id: I1e4532e71fb535453c9fd9151f89dd2aca52e7d0
Reviewed-on: https://gerrit.chromium.org/gerrit/59691
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
BUG=none
BRANCH=none
TEST=tested on pit
Change-Id: I61896f70f41eec12a1499307f695fa69f3d42d88
Reviewed-on: https://gerrit.chromium.org/gerrit/59692
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The functions which checked the status of a transfer would return success if
the bus was no longer occupied, even if it's no longer occupied because the
transfer failed. This change modifies those functions to return three possible
values, 0 if the transfer isn't done, -1 if there was a fault, and 1 if the
transaction completed successfully.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit and verified that the PMIC was
initialized successfully by coreboot. Similar changes were tested in
depthcharge when probing the tpm and when communicating with it and corrected
some problems there.
BRANCH=None
Change-Id: If20e0f29688542ba03f08c1da3ebe0429103d33d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59733
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The exynos manual suggests hooking the mmc ip blocks to the mpll. They had
been set to use a different pll. This changes them over and modifies the
divider so that the frequency stays the same.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I9b473b683c5806a49c9eba91807baa0b58c9c9dd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59732
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Saw that depthcharge could talk
to the TPM over i2c.
BRANCH=None
Change-Id: I08c483bf57b17ed923dee0715e1a244ff607bd64
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59731
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This allows us to set different speeds for each HSI2C bus.
BUG=none
BRANCH=none
TEST=using logic analyzer on pit, saw I2C4 run at 1MHz
and I2C9 run at 400KHz
Change-Id: I27bf54084644c4cbcdbed423197a1113d6f6c17b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59693
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This change adjusts some clock settings so that they match U-Boot. There are
three different changes.
1. Change the source for psgen from the oscillator clock to the pclk.
2. Change the pll feeding the SPI busses from epll to mpll, as suggested in
the manual.
3. Change the SPI prescaller.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I2896c099a91bdb78bfac03fbb804ef65c3233cd0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59730
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The clock divider was being read from registers incorrectly which meant that
the periph rate was wrong.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: Idb38374195a737fac2f096771929c8f1645d7247
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59729
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Wait for UART FIFO to be ready.
(Credit to dhendrix for finding the bits to test with.)
BUG=none
TEST=manually boot device and see no garbage on serial output.
BRANCH=none
Change-Id: Ic921cc39a27b137f1a7fd137e032ffb61489bdd1
Reviewed-on: https://gerrit.chromium.org/gerrit/57660
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
BUG=chrome-os-partner:16957
TEST=None
BRANCH=None
CQ-DEPEND=CL:59674
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
