If we sysjump to EC-RW, that sets enabled=0. enabled is only set back
to 1 when the chipset resumes. But on an AP-requested sysjump, the
chipset is already on, and so the resume hook never gets called.
So, in spi init, check if the AP is already on. If it is, enable spi
transfers right away.
This probably also affects Pit/Pi. That may need an additional fix in
power/gaia.c, if it returns an incorrect chipset state after a sysjump
(I didn't test that.)
BUG=chrome-os-partner:28249
BRANCH=nyan,pit
TEST=Power+Refresh boot system with RONormal disabled, so that the AP
tells the EC to jump to EC-RW. Confirm EC communication still works
after that.
Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198869
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
We found some cases where the battery can flip out and get confused
and hold the i2c lines. Since the battery is actually smbus it will
give up after 25ms. Increase our timeout to 30ms so that the next
trasaction will work OK.
BRANCH=ToT
BUG=chrome-os-partner:28425
TEST=Revert (1cd618e Wait for battery boot-up) and use a problematic
battery; see boot works OK.
Change-Id: Ife051220cbbbd49d7bc9c8607ba177cd9582fe58
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198212
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Ensure that we finish reception if and only if we started it
whatever other events happened.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28332
TEST=Connect Zinger to Firefly, request higher voltage and ensure that
Firefly was still getting the Pings after several hours.
Change-Id: Ie99984aeb4c565be39d349457dbd2813203b3f5b
Reviewed-on: https://chromium-review.googlesource.com/197946
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
With change b610695b61, we fixed a problem
with the number of FP regs that were being saved on the stack. That change
decreased the required stack size for non-FP tasks by 64 bytes, but
increased the size needed for FP tasks (such as the lightbar).
The lightbar task was previously using within 64 bytes of its alloted stack,
so handling the task switching correctly meant that it now overflowed.
The hooks task had the same problem, but was hidden by the lightbar task.
This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar
task to use it instead of the default size.
BUG=chrome-os-partner:27971, chrome-os-partner:28407
BRANCH=ToT
TEST=Try it on both Link and Samus.
Before this change, the Samus lightbar was overflowing its stack every time
the AP booted (causing the lightbar to do things). With this change, it
doesn't. Here are typical stack sizes after this CL:
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 28.394913 328/512
1 HOOKS 00000000 0.534085 640/768
2 R LIGHTBAR 10000000 5.359356 520/768
3 CHARGER 00000000 0.094674 384/512
4 CHIPSET 00000000 0.003353 320/512
5 KEYPROTO 00000000 0.002814 312/512
6 HOSTCMD 00000000 0.002942 244/512
7 R CONSOLE 00000000 0.193776 340/768
8 POWERBTN 00000000 0.000392 248/512
9 KEYSCAN 00000000 0.409337 332/512
Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197733
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In some cases, the system will boot to S0 from the point of view of
the EC, but PLTRST# will never deassert. Work around this by waiting
50 ms for PLTRST# to deassert. If it doesn't, force the chipset all
the way down by deasserting RSMRST#, then pulse the power button to
turn it back on.
Also add a powerfail debug command to simulate this failure event, so
that the recovery process can be tested.
Add API to the LPC module to get the state of PLTRST#, and to the
power button state machine to force it released when we shut down the
chipset and and force another power button pulse as we reset the
chipset.
BUG=chrome-os-partner:28422
BRANCH=baytrail
TEST=1. Boot system. Should boot normally. Shut system down.
2. powerfail
3. Boot system. On the EC console, should see the system come up,
go back down through G3S5, then come back up. From the user's
point of view, it just boots.
1. Boot system. Should boot normally. (That is, powerfail is not sticky)
Change-Id: Ia57f196606f79b9f2fce7d9cd109ab932c3571aa
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197523
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This implements dual chip matrix scanning. Now the scan result is only
dumped to debug output.
BUG=None
TEST=Put a finger on the panel and see its shape.
BRANCH=None
Change-Id: I015c901b42e24fe4a6249c12c37bc5bfcb308c9f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196468
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Use the plug polarity detected by the ADCs to do the PD communication on
the right CCx line.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28339
TEST=make buildall
on Firefly, plug Zinger connector in both direction and see it can
control it either way.
on Fruitpie, use CC1 or CC2 and see it can communicate on both.
Change-Id: I81cb00f164cb8194fba73b383014e81c37d975e2
Reviewed-on: https://chromium-review.googlesource.com/197520
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Slightly modify interfaces for better sink-only devices implementation
(eg Firefly)
update the host mode management and the voltage selection
and add a hook for board checks.
Simplify the reception timeout and fix other timeout detections.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
and use with the follow-up firefly board configuration CL.
Change-Id: I0240295764c8605793dc80a2fc21357af1740744
Reviewed-on: https://chromium-review.googlesource.com/195585
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Added config option CONFIG_USB_PD_TX_USES_SPI_MASTER which switches
to use SPI master for PD transmit. The advantage of SPI master mode
is at the end of the tranmission, we don't have to send any dummy 0
bits. When the option is set, the CPU_CLOCK must be set to 38.4MHz,
so that the SPI master can generate the correct clock frequency.
BUG=chrome-os-partner:28309
BRANCH=none
TEST=Tested by connecting two fruitpies together across CC1. One
fruitpie has been modified such that the MISO and MOSI lines are
swapped and is running PD TX in SPI master mode with 38.4MHz clock,
while the other is running PD TX in SPI slave mode. On EC console
ran pd charger on one board and pd dev on other board. Verified
that communication works with no errors. Ran for 10 minutes in each
configuration.
Change-Id: Ib24030d34d95d59f4ac6c2dae98bf7adda1ada01
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197215
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The external interrupts above 15 are not used for GPIO IRQ handling, but
for special purpose interrupts from internal peripherals (e.g. RTC,
comparator, wake-up ...). When processing the GPIO interrupts, we should
explicitly skip those interrupts, else if a GPIO interrupt happens
first followed by another EXTINT, the loop in gpio_interrupt() will try
to process it and do an out-of-bound read of the exti_events array.
This will retrieve a garbage handler triggering a memory fault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28296
TEST=on Firefly, press the buttons to trigger GPIO interrupts while
there are a bunch of comparator interrupt on EXTIN21 (due to on-going
USB PD communication). I no longer see HardFaults.
Change-Id: Id90fab30215b0f7f8060c19de63a7ca8418b7b3c
Reviewed-on: https://chromium-review.googlesource.com/197019
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
This implements a simple SPI driver for the two chips to exchange
packets.
There are both sync interface and async interface. Sync interface is
easier to use, and async interface frees the CPU while the DMA takes
care of the communication.
BUG=None
TEST=Hello test passed
BRANCH=None
Change-Id: I9823bad5cae6d1fa8f3658d17af4b998d3735a3e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195533
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This chip got small flash and RAM, so the common runtime is disabled.
Now the code only boots and print something every second to check debug
console and timer are good.
BUG=None
TEST=Boot and see console output
TEST=make buildall
BRANCH=None
Change-Id: I01150e8250a404628d1a3b81e677ac4c29782d7f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195382
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously, you could use EC_CMD_ACPI_QUERY_EVENT to read events that
were masked off (that is, events which would not generate SCI/SMI/wake
signals). The handlers for those signals on the host would still act
on the masked-off events - for example, causing unwanted power button
keypresses/releases.
Now, EC_CMD_ACPI_QUERY_EVENT will only return events which are unmasked.
This does not affect storing of events at event generation time.
Events are still queued; they won't be dropped until the host attempts
to read the next event. This gives the host a chance to set a mask
later in boot (but before querying any events) to capture events which
happened early in the boot process.
BUG=chrome-os-partner:26574
BRANCH=rambi
TEST=At EC console, type 'hostevent set 0x80' but don't press enter.
Hold down the power button; UI starts fading to white.
Press enter at the EC console to issue the hostevent command.
System should continue shutting down, not fade back as if the
power button were released.
Change-Id: Id2cb14b0979f49cdd42424b9a61b310a2bb506f5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194935
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The KBD_IRQ#, SMI#, and SCI# lines on the host are sensitive to
falling edges. When generating an interrupt, wait long enough to make
sure the lines are high before pulling them low, so that it reliably
generates a falling edge. This solves a problem where calling the
IRQ-generation function twice in rapid succession could cause two low
pulses without an intervening logic-high as seen by the host (and thus
not a falling edge as seen by the host).
This is most visible on the keyboard line, because it can generate
back-to-back events on multi-byte scan codes. Once the keyboard
mailbox is full, the EC will never attempt to fill it, and thus it
also won't attempt to generate another keyboard IRQ. And since the
host missed the IRQ, it doesn't know it needs to empty the mailbox.
It could theoretically happen for the other lines, so fix them now
just to be safe.
This change should be low-impact and free from side effects. 4 usec
is a very small additional delay. Even 65 usec added delay for
SCI/SMI is small, given that SCI/SMI events are typically much less
frequent (if they're happening very frequently, something else is
tragically wrong with the system...)
BUG=chrome-os-partner:27222
BRANCH=rambi
TEST=Bang on the keyboard like a monkey. Keyboard shouldn't get stuck.
Orig-Change-Id: Id4e6de793b1f007f713bac8aa195ddd78feeea3e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193173
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
(cherry picked from commit 569651b82e309ddd86b9c165d131e34cb7f7b2b5)
Change-Id: I62a9ad0fa85121b3345c057f0e3fc6b3cc29e97e
Reviewed-on: https://chromium-review.googlesource.com/193174
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
add support for CRC-32, it's using the USB variant for the constants and
bit ordering (same polynom as Ethernet).
This code is using an (evil) "stateful" design to be compatible with the
hardware CRC controller : you should NOT do concurrent accesses without
external locking (but it's good enough and ligthweight for current
usage)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run interoperability testing against other 3rd parties USB
implementations.
Change-Id: I1a07b2c4e2e71e15f9d257611652061bcfb0de9c
Reviewed-on: https://chromium-review.googlesource.com/189865
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This prevents other task events from continuing the ADC
conversion prematurely; potentially leading to a panic
if the conversion interrupt occurs after the ADC has
been powered down.
BUG=chrome-os-partner:26919
BRANCH=rambi
TEST=Perform ADC conversions while running a deferred function
calling itself on a 10mSec delay. Verify no panics after ~6 hours.
Change-Id: Ic3894849c154b3f058e812b2da816e7cffb12cbf
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add STM32F03x as part of the STM32F0 family.
STM32F031 will be used for devices requiring low-end parts.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=along with the following CLs, run on STM32F051 Discovery with
limited RAM and Flash to mimic STM32F031.
Change-Id: Ie95303eaf00ce53fe7c8d2ac84c19a983aadbf0d
Reviewed-on: https://chromium-review.googlesource.com/189404
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
In order to achieve really tiny firmwares, make our runtime (tasks,
hooks, muxed timers, GPIO abstraction ...) optional.
Add 2 new build options for it : CONFIG_COMMON_RUNTIME and
CONFIG_COMMON_GPIO which are enabled by default, and ensure all the
source files are built according to the right configuration variable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
build a minimal board with no runtime.
Change-Id: Icb621cbe0a75b3a320cb53c3267d6e578cd3c32f
Reviewed-on: https://chromium-review.googlesource.com/189403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Replace the stubs by an actual implementation for ADC and Analog
watchdog support on STM32F0xx chips.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=manually read ADC values on STM32F072B discovery.
TEST=read all ADC values at once.
TEST=Enable watchdog and check it fires when the voltage goes out of
range.
TEST=read ADC value(s) while watchdog is enabled.
TEST=Disable watchdog and check it's actually disabled.
Change-Id: Ie6fbd1aa95a3d76394fa47803e8cfc24bf5e4562
Reviewed-on: https://chromium-review.googlesource.com/190710
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Some section(entry point, interrupt vector, e-flash signature
and so on) of linker script file are not linked.
The start address of e-flash signature should always at 00000080h.
Default firmware treats VCC logic high to prevent pin 11 logic low
but use following functions.
(EC2I, KBC, SWUC, PMC, CIR, SSPI, UART, BRAM, and PECI)
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=Firmware can startup on IT8380 emulation board.
Change-Id: I9860ac5b99dcc6e9e00dbc9d1e79a141237b7789
Reviewed-on: https://chromium-review.googlesource.com/190008
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Dino Li <dino.li@ite.com.tw>
Commit-Queue: Dino Li <dino.li@ite.com.tw>
Some STM32 variants have a 32-bit timer in addition the bunch of 16-bit
timers.
Add the option to use the 32-bit timer as the system clock source to
lower the overhead of the timer code compared to a pair of 16-bit
timers.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run the EC on STM32F072 Discovery board with 32-bit TIM2 as the
clock source.
Change-Id: If55c4e23a3f68dd8f6ca32e93f3a27c1743c767b
Reviewed-on: https://chromium-review.googlesource.com/189861
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
After Alex's CL 8a9817a, the i2c driver no longer hardcodes the
I2C port pin (Ya!). Remove the conflict pin setting in board files.
BRANCH=nyan,big
BUG=chrome-os-partner:26620
TEST=build and run on nyan board. Everything looks good.
Change-Id: Iee2c5f10f642da7ad00f503b6e615cb6aa472459
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189245
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add support for the STM32F0xx family of devices using a Cortex-M0 core
and slightly newer peripherals than F1xx family.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run EC console on STM32F072B Discovery board.
and pass all available unit-tests on target.
Change-Id: Idaa3fcbf1c0da8a8f448c0e88e58bfd976b0a735
Reviewed-on: https://chromium-review.googlesource.com/188983
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).
This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.
Note: now on, the IRQ handling routines should no longer be "static".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.
Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
We don't have available GPIO pin for power button as the hibernate
(stand-by) wake-up source. Also, we don't want to do board change.
So, put the EC in a decent infinite loop to pretend the hibernate mode
and wait for particular wake-up event. This should be fine because
the AP is already down before EC hibernates.
BUG=chrome-os-partner:25435
BRANCH=Nyan
TEST=see comment #6 of issue for detailed test steps.
Change-Id: I2cae131789f9ca5808b60d5f2495222ca9016e7c
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186061
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Refactored the i2c unwedge code to place it in the common directory
so that any EC chip can use it.
Added to the STM32F and LM4 boards, code to automatically detect and
unwedge the i2c bus at the start of an i2c transaction. Note that STM32L
already had this ability.
To enable unwedging of the i2c port though, the gpio pins for SDA and
SCL must be defined in the i2c_ports[] array in the board.c file. This
allows the i2c module to bit bang the unwedging for the given port. If
SDA and SCL are not defined for the port, then the unwedge code will
not run.
BUG=chrome-os-partner:26315, chrome-os-partner:23802
BRANCH=none
TEST=Manual testing on machines with different EC chips.
Testing made extensive use of https://chromium-review.googlesource.com/66389
in order to force wedging of the i2c bus so that we can attempt to unwedge
it. Note that you can easily test if the bus is wedged by running i2cscan.
On pit and spring:
On pit, after each of the following, I verified that the bus was automatically
unwedged.
On spring, the unwedge only runs at reboot, so, for the non-reboot wedge
commands, I manually ran console command unwedge, and verified that the bus
became unwedged.
(1) Bit bang a transaction but only read part of the response.
Command to wedge: i2cwedge 0x90 0 2 2
(2) Bit bang a transaction to do a "write" and stop while the other side is
acking. Command to wedge: i2cwedge 0x90 0 1
(3) Same as (1) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
Command to wedge: i2cwedge 0x90 0 6 2
(4) Same as (2) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
Command to wedge: i2cwedge 0x90 0 5
On glimmer:
Added code to call i2c_unwedge in accel_init(). Then tested unwedging the
accelerometer with the following. One extra difficulty testing this with
the accelerometer is that sometimes the bit you stop on is high, which
means it won't be wedged at all, the next start transaction will reset
the bus. So, sometimes running i2cwedge won't wedge the bus and sometimes
it will depending on the acceleration data.
(1) Big bang transaction to do a "read" of accelerometer and stop partway:
i2cwedge 0x1c 0x0f 2 2
i2cscan to make sure bus is actually wedged
i2cunwedge
i2cscan to make sure bus is now unwedged.
(2) Bit bang transaction to do a "read" and stop partway, then reboot:
i2cwedge 0x1c 0x0f 6 2.
i2cscan to verify that the bus is working after the reboot.
Change-Id: Ie3328e843ffb40f5001c96626fea131c0f9ad9b1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188422
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We copied that delay because it seemed to be necessary on early LM4
chips to avoid glitching the UART. But on current boards (e.g. rambi)
this does not seem to be necessary, and delays boot by 31ms. So,
remove the delay.
BUG=chrome-os-partner:23794
BRANCH=rambi
TEST=boot system; see little to no glitching on EC uart, and system boots ok
hibernate 1; see little to no glitching on EC uart, and system boots ok
Change-Id: I9d4b5927da4282e47e1b09be838104c64f25268c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185232
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds hibernation support. The chip can be waken by either GPIO or a
timer. The maximum delay allowed is ~2 hours.
BUG=chrome-os-partner:24107
TEST=hibernate and wake by GPIO
TEST=hibernate and wake by timer
BRANCH=None
Change-Id: I1e064638a5008894a002a06a738bf6104f18636d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181202
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EMI module is the only LPC module suitable for port 80 implementation,
and thus let's move it to 0x80. Consequently the EMI mapped memory is
moved to 0x82-0x87.
BUG=chrome-os-partner:24107
TEST=Write to port 80 and see the data printed to console
BRANCH=None
Change-Id: I7d749650d6d109af2941a1db6e6c4a32e7482f61
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182796
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EMI module has the ability to set different read and write ranges. Let's
disable write on mapped memory.
BUG=chrome-os-partner:24107
TEST=Write to mapped memory has no effect
BRANCH=None
Change-Id: I88654bde9208376103d3c084ee54991d886ea4cc
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182795
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This significantly decreases the task swapping overhead when doing
many transfers.
Also fix a bug where on error, i2c_xfer() would issue a stop
condition, but not actually wait for it to complete before returning;
this could interfere with the next transfer in a back-to-back
scenario.
BUG=chrome-os-partner:25015
BRANCH=lm4 (more specifically, rambi and derivatives)
TEST=battery command should show the same info as before
i2cscan should show devices at bus 0 0x12, 0x16, bus 5 0x98
no charger errors on boot
Change-Id: I2195f0f9800b03a54fa33170dbae6705382578c7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182503
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Watchdog module added. Off by default because of following limitations:
- When programming, the WD fires, and programming fails. For now, you
have to program twice.
BRANCH=none
BUG=chrome-os-partner:23575
TEST=Manually wrote in a while(1); and made sure watchdog warning
triggers first, prints IPC register, and then soon after the watchdog
timer resets the chip.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Ia83f58f3ae108f755d2f139ada22a22e2fbdc2fa
Reviewed-on: https://chromium-review.googlesource.com/177397
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added system reset and reset causes for ITE chip. The only reset
causes available on this chip are watchdog reset or power on reset.
BRANCH=none
BUG=none
TEST=Used reboot console command with various args and verified reset
cause was recorded correctly on next boot.
Change-Id: Ie65f1e8f2b98c1e614b5c1d8bcbe9b3000ed9590
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179539
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The VBAT POR indication is unreliable for detecting a power-on reset,
and thus we often see "unknown" reset cause when we should see
"power-on". A better indication is to check for VCC1 POR, which
manifests by clearing watchdog count. The catch is that we still cannot
tell power-on reset from reset-pin reset.
Also, to distinguish soft/hard reset from actual watchdog reset, we need
to explicitly save soft/hard reset flag before triggering watchdog
reset.
BUG=chrome-os-partner:24107
TEST=Power cycle EVB and see 'power-on' reset cause.
TEST='reboot' and see 'soft' reset cause.
TEST='reboot hard' and see 'hard' reset cause.
TEST='waitms 2000' and see 'watchdog' reset cause.
BRANCH=None
Change-Id: I0075f5bf5cdb032d206c4a53c586b75b69093235
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182120
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of requiring a GPIO definition, default to using the internal
SCI pin control.
BUG=chrome-os-partner:24550
TEST=Trigger SCI and verify with logic analyzer
BRANCH=None
Change-Id: I13ac3b8f1031d3c56ea0b8f6a6ed0c1aa4e77bb1
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182010
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vboot hash calculation takes ~350 ms during EC boot. Since the hash
task is higher priority than the hook task, this starves all the hooks
during boot.
We could, in theory, fix that simply by swapping the priority of the
hook and hash tasks. But then watchdog detection (in the hook task)
wouldn't detect hangs in the hash task.
A better fix (implemented here) is to convert the hashing operation to
a series of deferred function calls. This gets rid of the hash task
entirely, and allows all pending hooks and other deferred function
calls to take place between each chunk of hashing.
On STM32-based boards, we need to bump up the hook task stack size,
since hashing is called from several layers deep in the hook task
instead of at the top of its own task, but this is still a net win of
several hundred bytes of SRAM.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Boot EC; look for "hash start" and "hash done" debug output.
'taskinfo' shows at least 32 bytes of unused stack for HOOKS task.
'hash ro' runs properly from EC console.
Change-Id: I9e580dc10fc0bc8e44896d84451218ef67578bbe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181954
Now that we handle all UART input from interrupt context, we shouldn't
need to guard input buffer with mutex lock. Removing the stale TODO
comment and adding an assertion to ensure this argument is correct.
BUG=chrome-os-partner:23804
TEST=make buildall
BRANCH=None
Change-Id: If61eed4329a782b80fe8b16667bddaae8464620d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181722
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On the IT8380, we should be able to map 16kB of SRAM to use as data
memory (aka DLM), but sometimes the 2 top 4k pages seem to be
mapped differently (ie not to SRAM, they do not retain writes ...).
As we have no documentation on that topic, for now use 8kB of DLM for now.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23575
TEST=build and run IT8380 dev board.
Change-Id: I4ed452f27e9c457e7ac717b82580781ca506b0d8
Reviewed-on: https://chromium-review.googlesource.com/179322
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The mock system_usable_ram_end() always returns the same address.
However, this causes the second jump tag to overwrite the first one.
Also, now that the jump data is properly placed, we can actually remove
the mock implementation.
BUG=chrome-os-partner:19235
TEST=Add two jump tag and check the first one is not overwritten.
BRANCH=None
Change-Id: If868895a7c028dd25399adb69e9708de45c84f10
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181745
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Initial support for the ITE IT8380 chip with the following peripherals :
- 8250-like UART module.
- HW timer (with a 128-us tick period).
- GPIO with pins initialization and edge interrupt support.
other functions are stubbed.
- Clock : basic fixed frequency setup only.
It also add the dev board configuration as a test vehicle.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23575
TEST=make BOARD=it8380dev
on IT8380 dev board, use the EC serial console, use gettime from
console.
Change-Id: Id4bf37d1beb21d1a4bee404c9a0bc500025fe787
Reviewed-on: https://chromium-review.googlesource.com/175481
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Implement LED color policy (crosbug.com/p/23957)
Update battery vendor information (crosbug.com/p/24684)
BUG=chrome-os-partner:24885
BRANCH=rambi
TEST=manual
system on, lidclose -> power LED off
system on, lidopen -> power LED on
system suspended -> power LED blinks green every 2 sec
system suspended, lid closed -> power LED off
system off -> power LED off
plug AC in, battfake 95 -> charging LED green
plug AC in, battfake 94 -> charging LED orange
unplug AC, battfake 10 -> charging LED off
unplug AC, battfake 9 -> charging LED blinks orange
battcutoff -> after a few sec, system powered down
plug back in AC -> system comes back on
charger -> I_in < 1700
Change-Id: I89161e2c024d85197b8612a40a61dd50c106549e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181755
The SERIRQ signal will now be high-Z on the EC, which removes a
leakage path. This requires the BIOS to use PM3 for its keyboard IRQ.
BUG=chrome-os-partner:24424
BRANCH=rambi
TEST=boot system; keyboard still works
Change-Id: I0acf425125ced11a9ef6da58ee49979b83c92d5c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181718
