summaryrefslogtreecommitdiff
path: root/chip
Commit message (Collapse)AuthorAgeFilesLines
* stm32: Re-enable spi transfers after a sysjumpRandall Spangler2014-05-091-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: add square brackets to make test parser easierLouis Yung-Chieh Lo2014-05-076-14/+16
| | | | | | | | | | | | | | | | 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
* i2c: stm32l: Increase timeout from 10ms to 30msstabilize-5828.0.BDoug Anderson2014-05-062-2/+10
| | | | | | | | | | | | | | | | | 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>
* pd: more robust receptionVincent Palatin2014-05-021-0/+6
| | | | | | | | | | | | | | | | | | 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>
* Increase some task stack sizes to handle more FP regs.Bill Richardson2014-05-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With change b610695b61db3b3784e2a516c91f429139616100, 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>
* baytrail: Workaround for stuck boot processRandall Spangler2014-04-301-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Keyborg: implement matrix scanningVic (Chun-Ju) Yang2014-04-301-0/+23
| | | | | | | | | | | | | | 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>
* pd: handle plug polarityVincent Palatin2014-04-302-10/+16
| | | | | | | | | | | | | | | | | | | | 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>
* pd: update policy, timeout and board callbacksVincent Palatin2014-04-301-10/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: pd: add config option to use SPI master for USB PD trasmitAlec Berg2014-04-293-16/+96
| | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: fix GPIO EXTINT maskingVincent Palatin2014-04-263-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Keyborg: chip-to-chip SPI communicationVic (Chun-Ju) Yang2014-04-241-0/+6
| | | | | | | | | | | | | | | | | | 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>
* Add STM32TS60 supportVic (Chun-Ju) Yang2014-04-205-0/+90
| | | | | | | | | | | | | | | | 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>
* lpc: ACPI query-next-event drops masked eventsRandall Spangler2014-04-172-6/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: USB Power Delivery physical layerVincent Palatin2014-04-123-0/+497
| | | | | | | | | | | | | | | | | Implementation of the physical layer for USB Power Delivery communication using the STM32 chip. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=none Change-Id: I2a4adeef572b97a284bf52ab9d14d23246c56d18 Reviewed-on: https://chromium-review.googlesource.com/189867 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* lm4: Ensure falling edges on outputs to edge-sensitive host inputsRandall Spangler2014-04-041-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 pwm support while in low-power idlestabilize-5712.8.BHenry Hsu2014-03-291-1/+9
| | | | | | | | | | | | | | | BUG=None BRANCH=None TEST=Enable this with pwm led board, the pwm led works even EC low-power idle. Change-Id: Ic808104d8e38b1f9074682ced41412c6af050efe Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com> Reviewed-on: https://chromium-review.googlesource.com/186951 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/192181 Commit-Queue: Dave Parker <dparker@chromium.org> Tested-by: Dave Parker <dparker@chromium.org>
* stm32: add support for stateful CRC-32Vincent Palatin2014-03-293-0/+145
| | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: new I2C driver for STM32F0xx familyVincent Palatin2014-03-273-3/+289
| | | | | | | | | | | | | | | | | | The STM32F0xx family has a new I2C peripheral, let's add a new driver for it. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=On FruitPie, read TSU6721 registers and read the smart battery information. Change-Id: Ic49832205957559b4b6b647948b03f650a27ab04 Reviewed-on: https://chromium-review.googlesource.com/191210 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* lm4: Use a special task event for ADC conversionsChromeOS Developer2014-03-261-5/+16
| | | | | | | | | | | | | | | | | 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>
* lm4: Update i2c handler to use task_wait_event_maskChromeOS Developer2014-03-261-25/+1
| | | | | | | | | | | BUG=chrome-os-partner:27180 BRANCH=rambi TEST=Verify i2c devices are still working (battery, charger) Change-Id: I9dc70454df35be9c9be3d9020c8dc3b760de5e07 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/191301 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: add more register definitionsVincent Palatin2014-03-231-4/+220
| | | | | | | | | | | | | | | | add detailed registers for DAC, COMP, RI and CRC. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=none Change-Id: Ib456d1fbc72c2f6c658ea96e5a3ab72035b33ed2 Reviewed-on: https://chromium-review.googlesource.com/189864 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: add STM32F03x configurationVincent Palatin2014-03-222-0/+45
| | | | | | | | | | | | | | | | | | 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>
* make the common runtime optionalVincent Palatin2014-03-221-2/+5
| | | | | | | | | | | | | | | | | | | | | 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>
* stm32: implement ADC support for STM32F0xxVincent Palatin2014-03-202-5/+266
| | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: add analog GPIO configurationVincent Palatin2014-03-203-1/+12
| | | | | | | | | | | | | | | | | Allow to setup a GPIO pin in analog mode on STM32 chips. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=run comparators with GPIOs in analog mode on STM32L151 and STM32F072. Change-Id: Ie11dd8711e39ab191c96478c6d8c7b7e0dfa7ea4 Reviewed-on: https://chromium-review.googlesource.com/189863 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* it8380dev: fix firmware can't startup (re-generate)Dino Li2014-03-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: add 32-bit timer supportstabilize-5656.BVincent Palatin2014-03-143-1/+172
| | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: remove the conflict I2C2/GPIO config in nyan/big.Louis Yung-Chieh Lo2014-03-131-3/+0
| | | | | | | | | | | | | | 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>
* stm32: flush write buffer before start DMA transfer.Louis Yung-Chieh Lo2014-03-111-0/+3
| | | | | | | | | | | BUG=chrome-os-partner:22849 TEST=Tested on peach-pit FAFT. No "checksum invalid" from cpu_uart.txt BRANCH=pit,nyan Change-Id: I64f4b636943158fab48892020980f784ca551e4f Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178087 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: add support for STM32F0xx familyVincent Palatin2014-03-1113-17/+607
| | | | | | | | | | | | | | | | | | 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>
* force the compiler to use a valid register allocation for irq handlersVincent Palatin2014-03-1122-44/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32l: supports fake-hibernateLouis Yung-Chieh Lo2014-03-062-0/+122
| | | | | | | | | | | | | | | | | | 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>
* cleanup: Combined i2c unwedge code into one common functionAlec Berg2014-03-064-260/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* lm4: Remove 500k clock delay in clock_init()Randall Spangler2014-02-071-10/+0
| | | | | | | | | | | | | | | | | 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>
* mec1322: hibernation supportstabilize-5339.BVic (Chun-Ju) Yang2014-01-282-4/+160
| | | | | | | | | | | | | | | 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>
* mec1322: Use EMI module for port 80Vic (Chun-Ju) Yang2014-01-171-6/+13
| | | | | | | | | | | | | | | 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>
* mec1322: disable host write to mapped memoryVic (Chun-Ju) Yang2014-01-171-1/+1
| | | | | | | | | | | | | | 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>
* lm4: move I2C transfer state machine to interrupt handlerRandall Spangler2014-01-161-184/+183
| | | | | | | | | | | | | | | | | | | | | | 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>
* ite: Watchdog module addedAlec Berg2014-01-152-0/+101
| | | | | | | | | | | | | | | | | 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>
* ite: Added system reset and reset causesAlec Berg2014-01-142-1/+70
| | | | | | | | | | | | | | | 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>
* mec1322: Refine reset cause detectionVic (Chun-Ju) Yang2014-01-112-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* mec1322: Use internal SCI pin controlVic (Chun-Ju) Yang2014-01-092-3/+22
| | | | | | | | | | | | | | | 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>
* Convert vboot hash calculation from task to deferred functionRandall Spangler2014-01-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove old TODO comment in emulator UART moduleVic (Chun-Ju) Yang2014-01-091-4/+1
| | | | | | | | | | | | | | | | 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>
* ite: WORKAROUND reduce data SRAM to 8kBVincent Palatin2014-01-081-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* emulator: Fix a bug that jump tag is overwrittenVic (Chun-Ju) Yang2014-01-081-5/+0
| | | | | | | | | | | | | | | | | 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>
* ite: Add initial support for ITE IT8380 chipVincent Palatin2014-01-0810-0/+1684
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add squawks boardRandall Spangler2014-01-081-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove duplicate KBD_IRQ_L signalsRandall Spangler2014-01-081-12/+0
| | | | | | | | | | | | | 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
View Lorry Controller Status