summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* More low-level flash interface cleanupRandall Spangler2013-05-245-49/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting at-boot protection always used the same start/range (RO+PSTATE), so no point in passing that to the physical layer as params. flash_dataptr() should take a pointer to const data. No functional changes; just rearranging code. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit, link, spring - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now) - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - reboot ap-off - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot - flashwp disable - flashinfo -> (no flags) Change-Id: Ifd6553dc907fa6fafce81b56af0c648ac6d6bee1 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56628
* Move flash_get_protect() and flash_set_protect() to flash_common.cRandall Spangler2013-05-245-298/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Much more flash code is now common between platforms, for more consistent behavior and easier testing. Also change STM32L to use pstate, the same way LM4 and STM32F do. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit, link, spring; do - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now) - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - reboot ap-off - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot - flashwp disable - flashinfo -> (no flags) Change-Id: Iccd098786454ad9b72b4e5f9f312d86819a0c8eb Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56109
* Remove 64-byte workaround from STM32L flash writingRandall Spangler2013-05-242-54/+35
| | | | | | | | | | | | | | | | | | | | | This was left over from ancient code where host commands only had a 64-byte payload, and page writes need to happen in 128-byte increments. This is no longer an issue with SPI host interface. Also added capability for word writes, since that'll be necessary for writing pstate (in the next CL). BUG=chrome-os-partner:9526 BRANCH=none TEST=hack flashwrite command in flash_common.c to allow write size = 4 bytes flasherase 0x1fc00 0x400 flashwrite 0x1fc00 0x100 -> success; uses fast path flashwrite 0x1fd00 4 -> success; uses word-write path Change-Id: I61434d8f714ea46deb65cadd82c45a61ad0ce68b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56627 Reviewed-by: Simon Glass <sjg@chromium.org>
* Create board configuration for peppy bringupDave Parker2013-05-238-2/+395
| | | | | | | | | | | | | | | | | | | | | | | | This change copies the slippy board configuration as a starting point for peppy. This change is essentially the same as https://gerrit.chromium.org/gerrit/55820 BUG=chrome-os-partner:19640 BRANCH=none TEST=manual Tested on slippy as there are no peppy-specific changes yet. cros_workon --board peppy start chromeos-ec emerge-peppy chromeos-ec ~/trunk/src/platform/ec/util/flash_ec --board peppy Signed-off-by: Dave Parker <dparker@chromium.org> Change-Id: I4c5f7a77fa55a6364effe838f7a656d56bfad9fb Reviewed-on: https://gerrit.chromium.org/gerrit/56332 Reviewed-by: Olof Johansson <olofj@chromium.org> Commit-Queue: Dave Parker <dparker@chromium.org> Tested-by: Dave Parker <dparker@chromium.org>
* Move write protect GPIO handling to flash moduleRandall Spangler2013-05-2316-30/+51
| | | | | | | | | | | | | | | | | Write protect signal naming is now consistent across boards. New CONFIG_WP_ACTIVE_HIGH is present on systems where the write protect signal is active-high (e.g. Link). This will be used in the next CL, which moves flash_get_protect() to flash_common.c BUG=chrome-os-partner:15613 BRANCH=none TEST=flashinfo properly reports WP signal status Change-Id: I502ab033c3eb36661cc3ee97320874b3fbf6fc0d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56087 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Move flash persistent state to flash_commonRandall Spangler2013-05-237-264/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Persistent state is needed by all platforms to hold the protect-ro-at-boot flag. STM32F100 and LM4 implementations were near-identical, and are now common code (with one #ifdef to handle the single place where they weren't). STM32L doesn't use pstate yet, but it'll need to. I can't simply store the protect-ro-at-boot flag inside the WRP registers themselves because they're still writable in EC-RW. The change to STM32L to use pstate is coming next. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit, link, spring; on link and spring, do - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now) - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - reboot ap-off - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot - flashwp disable - flashinfo -> (no flags) (Note that on Spring you'll need to 'forceen on' before enabling WP, or the console will be disabled once you enable ro_at_boot and reboot.) Change-Id: I415388b98ec8bf1d149803aaaa7fe8c7f3076c36 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56064
* Clean up option byte register definitions for STM32LRandall Spangler2013-05-232-13/+13
| | | | | | | | | | | | No functional changes, just renaming and defining a few additional regs. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit Change-Id: I67b2a96608431ffc418e6d4c81009d497f34568b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55813
* Support flash write protect on STM32LRandall Spangler2013-05-225-101/+286
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for write protecting the RO code at boot, and the entire flash on demand. Implementation if WP# is not asserted is currently a little different than STM32F and LM4; RO is still protected at boot if ro_at_boot, but can be unprotected and the change will commit on the next reboot. This saves the bank of flash which we use for pstate on LM4 and STM32F. I think I can use one of the unused option bits (WRP2 bit 0) to hold the RO-at-boot flag, in which case I can more closely match the behavior of the other chips, but I'd like to do that (or give up and implement pstate) in a separate CL so it's clearer what I'm doing. BUG=chrome-os-partner:15613 BRANCH=none TEST=manual - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - flasherase 0x1fc00 0x400 -> fails - reboot - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - flasherase 0xfc00 0x400 -> fails - flasherase 0x1fc00 0x400 -> succeeds - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot ro_now - flashwp disable - flashinfo -> ro_now - reboot - flashinfo -> (no flags) - flasherase 0xfc00 0x400 -> succeeds - flasherase 0x1fc00 0x400 -> succeeds Change-Id: Id1b6b099a44a1985a5ab9387feb882a8f26e3aa1 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55594
* usb: Disable ports on entry to S5Duncan Laurie2013-05-221-1/+1
| | | | | | | | | | | | | | | | The "dumb" port power code was setting ports to enabled on S5 when it should be setting them to disabled. This changes it to match the behavior of the "smart" port power code and its own comment. BUG=chrome-os-partner:19398 BRANCH=none TEST=manual: poweroff slippy and watch USB ports get disabled Change-Id: Ibc68450a973477341d9ca096ac5a6ddd08cef273 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56262 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* haswell: fix RCIN# GPIO settingAaron Durbin2013-05-223-4/+9
| | | | | | | | | | | | | | | | | | The gpio pin used for RCIN# should be configured as open drain as the rail is pulled up by a non-EC rail. Driving it high would leak power. The current GPIO_HI_Z macro uses GPIO_HIGH as the default state. However, it has been found that this actually drives the pin to ground. It is still unclear how Link works or doesn't. BUG=chrome-os-partner:19355 BRANCH=none TEST=manual: boot on slippy without RCIN# causing reset and the 'apreset warm' EC command works as expected. Change-Id: I71425075f8d77b3d7e576a59fc24f823790e2655 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56269 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Create board configuration for falco bringupBill Richardson2013-05-2011-11/+402
| | | | | | | | | | | | | | | | | | | | | | | | This change just copies slippy and tweaks a few things that were slippy-specific instead of not-link-specific (there are still bugs open for those things). BUG=chrome-os-partner:18788 BRANCH=none TEST=manual Since there are no Falco-specific changes yet (just slippy with another name), I can try it on Slippy: cros_workon --board falco start chromeos-ec emerge-falco chromeos-ec ~/trunk/src/platform/ec/util/flash_ec --board falco I also built and tested Link EC, to make sure nothing broke there either. Change-Id: I9b3682032bd51adab4450520dfe52e3036750ef9 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55820 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Reset charge state machine on charge timeoutVic Yang2013-05-203-0/+31
| | | | | | | | | | | | | | | | For Spring, the charging time can be quite long and TPS65090 ends up in timeout state and stops charging. Let's put charge state machine back to re-init so that the device continues charging after checking charging condition is good. BUG=chrome-os-partner:19405 TEST=Pass charger test BRANCH=spring Change-Id: I838741e7283eb31ed76cf3979dbad7f070947aea Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55720 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Fix a bug in reading TSU6721 interrupt valueVic Yang2013-05-201-2/+2
| | | | | | | | | | | | | The order of high byte and low byte was incorrect. BUG=None TEST=Dump interrupt value and check manually. BRANCH=spring Change-Id: I08657ad42bdc747cff2dd7d0e8be76fa44fc9563 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55717 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Draw more current when lower than 500mAVic Yang2013-05-201-2/+16
| | | | | | | | | | | | | | | | | If the current value is lower than 500mA and voltage is higher than 4.55V, draw more current. Also to make PWM duty cycle more stable, disable fast mode once we hit low voltage condition. BUG=chrome-os-partner:19486 TEST=Plug in a low voltage USB host. Check we draw more current. BRANCH=spring Change-Id: I91ee97ca15247d49427d4db34d17a0d0c55b2684 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55722 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Show power number in 'ectool powerinfo' outputVic Yang2013-05-201-0/+2
| | | | | | | | | | | | | | This is just a simple V*I value so that we don't need to do the math all the time. BUG=None TEST=None BRANCH=None Change-Id: I6317720d196d4bc2392adefb540be14bc34b5978 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55641 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Revert "Monitor video detachment with ADC watchdog"Vic Yang2013-05-201-74/+43
| | | | | | | | | | | | | | | | This reverts commit 7de52688be2f1b06a2cbd61da0f86b5b0c489b7e. ADC watchdog is sourcing too much current onto ID_OUT net, and causes voltage to rise by 0.4V. Let's revert this and use the monitoring loop. BUG=chrome-os-partner:18397 TEST=Plug in the dongle and see kernel message about cable detect. BRANCH=spring Change-Id: If8f8e831d6184c3b3db582931ce8db6c064e2c0d Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55687 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Bus fault handler doesn't need to be nakedRandall Spangler2013-05-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | When it was a naked call, if it doesn't jump somewhere, it just falls through to whatever code happens to be next. Which happened to re-enable bus faults - meaning that only the first fault was being ignored. That's a problem for flash protection on STM32, where writes to potentially-locked key registers come in pairs. BUG=chrome-os-partner:19564 BRANCH=spring TEST=manual, on pit: 1. Hack in a igbusfault console command to call ignore_bus_fault() 2. igbusfault 1 3. ww 0x40023c0c 0xdeadbeef -> no fault 4. ww 0x40023c0c 0xdeadbeef -> still no fault 5. igbusfault 0 6. ww 0x40023c0c 0xdeadbeef -> exception and reboot Change-Id: I5cf74b06a76ebf0176a2905924be87b3d1c825ce Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55572 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Support write protect GPIO on pitRandall Spangler2013-05-173-8/+9
| | | | | | | | | | | | | | | | Daisy doesn't have a write protect signal, so emulate it as a fake signal which is always low; this maintains the current behavior on daisy. BUG=chrome-os-partner:15613 BRANCH=none TEST=flashinfo shows gpio not asserted then short across the WP screw and flashinfo shows it asserted Change-Id: I329424efe1c3b065976e17395e2bf9588cdce88c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51500 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Fix detecting inconsistent flash stateRandall Spangler2013-05-172-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the last bank of flash in a region was protected and the rest of the region was unprotected, flash_get_protect() shoud return the INCONSISTENT flag, but this wasn't being properly detected. Port the existing fix from STM32F. BUG=chrome-os-partner:19529 BRANCH=none (not likely worth porting to link) TEST=protect just the last bank of RW firmware, then flashinfo > flashinfo Physical: 128 KB Usable: 128 KB Write: 64 B Erase: 256 B Protect: 4096 B Flags: all_now INCONSISTENT Protected now: ........ ........ ........ .......Y Should have the inconsistent flag set. Change-Id: I407737cef42748da6b3ec40d84968c76ee07972c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51498 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Adjust hooks test timingVic Yang2013-05-171-11/+16
| | | | | | | | | | | | | | | | We unit test to be as less time sensitive as possible. This change adjusts the timing in the test to ensure we have enough time for context switching. Otherwise we get false negative sometimes. BUG=chrome-os-partner:19236 TEST=Repeatedly run the test and see it passes. BRANCH=None Change-Id: I90c1200641cb02f95bd7631bd2870ad21b21bffc Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51562 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Revert "Revert "Add thermal engine test""Vic Yang2013-05-178-9/+274
| | | | | | | | | | | | | | | This reverts commit 89e688a3325e91d3c59ac639f04f2c91019c9b10. Time-scaling is added back. We can run this test now. BUG=chrome-os-partner:19236 TEST=Pass the test. BRANCH=None Change-Id: Id3dcec6fc12489f5f0602de91c6560a8dfbef9af Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51551 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Revert "Revert "Scale timer for emulator""Vic Yang2013-05-172-2/+13
| | | | | | | | | | | | | | | | | This reverts commit c58c01b14cd45550991be1624146bc813092d202. Let's add time scaling back, but keep the default scale to 1. The emulator behavior should be entirely the same. If a test need to be speeded up, the scale can then be set for that test only. BUG=chrome-os-partner:19235 TEST=Pass all tests. BRANCH=None Change-Id: I648780577a1ae2f964c30c71077ccf9bf38b9735 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51550 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* haswell: bring down EC_EDP_VDD_EN with PP330_DXAaron Durbin2013-05-161-1/+7
| | | | | | | | | | | | | | | | | | The display rail is generated from the PP3300_DX rail, but it is enabled by the EC_EDP_VDD_EN signal. Therefore, bring down the EC_EDP_VDD_EN signal before bringing down the PP330_DX rail. Additionally, always set the EC_EDP_VDD_EN signal based on the PCH_EDP_VDD_EN in the x86 power interrupt. The reasoning is so the signal doesn't indavertently remained set. BUG=chrome-os-partner:19398 BRANCH=None TEST=booted and resumed Change-Id: I43c2306f05d144b7dea243bafb5922118be1fe39 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51524 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* haswell: bring up/down WLAN rail properlyAaron Durbin2013-05-161-0/+5
| | | | | | | | | | | | | | | | | The PP3300_WLAN rail was not being controlled. Fix this by bringing up the rail in S3->S0 transition and bring it down in S0->S3 transition. This current sequencing will not allow the WLAN to wake from suspend at the moment. To do that we'd need to move this sequencing to the S5<->S3 transitions. BUG=chrome-os-partner:19507 BRANCH=none TEST=Brought up board. Noted WLAN card in lsusb and lspci. Change-Id: I48e7610fa4f0471a2869933f2df5d2c7c525b155 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51483 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Set SPI lines to inputs when AP is offRandall Spangler2013-05-163-10/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When AP is off, turn off pullup on NSS, and set MISO to an input so the SPI module won't drive it high if the last sent bit was a 1. This reduces leakage when the AP is off. This patch also fixes a bug where gpio_set_alternate_function() set the wrong pins to normal-mode when func=-1; that didn't hit anything else because that functionality wasn't used on STM32 until now. BUG=chrome-os-partner:19304 BRANCH=none TEST=boot pit On EC console, with AP on, 'rw 0x40020000' returns read 0x40020000 = 0x6569aa20 <- must have 0x____aa__ Then 'apshutdown' and 'rw 0x40020000' returns read 0x40020000 = 0x65690020 <- must have 0x____00__ The 'power on' and AP turns back on. At u-boot prompt, 'sspi 2:0 256 9f00000000' returns FDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFEEC010001 (some number of 0xFD's followed by FEEC...) This shows SPI functionality is restored when AP is powered back on, and not just at init time. Change-Id: Ia3cd3e0bc222dc663d635509918fa3d383fd7971 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51182 Reviewed-by: Simon Glass <sjg@chromium.org>
* pit: Add more delay for proper power_on sequenceWonjoon Lee2013-05-161-3/+4
| | | | | | | | | | | | | | | It makes delay between 3.3V_EN and PMIC_ON So we are now 5V EN -> 2ms Delay -> 3.3V EN -> 2ms Delay -> PMC3_ACOK BUG=chrome-os-partner:19305 BRANCH=none TEST=Using osiloscope, See until PMC3_ACOK is far from P3.3V_AUX as 5ms Change-Id: I65bfece28f55edf4f5640fe411bd57caaaaa5e1d Reviewed-on: https://gerrit.chromium.org/gerrit/50449 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* lm4: break out board-specific fan/tach pin configAaron Durbin2013-05-164-10/+23
| | | | | | | | | | | | | | | | | The current lm4 pwm module was using board-specific pins during this configuration. Move the implementation of configure_fan_gpios() to the board-specific files so that the pin configuration policy isn't a part of the common infrastructure. BUG=chrome-os-partner:19504 BRANCH=none TEST=successfully booted slippy with backlight turning on in OS. Change-Id: I325f1ac4639b4a78d8b860df7a8b688ca385b71b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51471 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Revert "Add thermal engine test"Vic Yang2013-05-168-274/+9
| | | | | | | | | | | | | | | | Time-scale functionality is temporarily reverted and this test is now taking too long. Revert this test now. Will add it back when we solve the time-scale issue. This reverts commit d9cf88b35ad211d873f48b41fd985e22ff049b83 Change-Id: Id9ce1071eb2114dd6968d3df9f0bce395edaeef6 Reviewed-on: https://gerrit.chromium.org/gerrit/51482 Commit-Queue: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Tested-by: Stéphane Marchesin <marcheu@chromium.org>
* Revert "Scale timer for emulator"Vic Yang2013-05-162-13/+2
| | | | | | | | | | | | This is causing instability on buildbot. Let's revert until we can make it more stable. This reverts commit 3615ac4c0b6141f9d5a3fb008d09f6792155815c Change-Id: I0bd65832cc3706a24284ada80e2fb5102fa705cf Reviewed-on: https://gerrit.chromium.org/gerrit/51479 Commit-Queue: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Add console command to force enable consoleVic Yang2013-05-155-49/+48
| | | | | | | | | | | | | | | | | | | | | | When system is locked, the console is disabled. However, we need console for debugging and testing. This CL uses a bit from back-up register to indicate if the console should always be enabled. (This bit is currently used by fake WP, which is removed in this CL.) With this, we can set this bit with console command 'forceen 1' to ensure console is never disabled. To prevent device shipped in this state, the chip name is postfixed with '-unsafe' so that the device is not able to pass HWID check. BUG=chrome-os-partner:19293 TEST=Manual BRANCH=spring Change-Id: I88556e973ca542c1bdc27ba64988718291e01a26 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51086 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* haswell: move 5V rail enable/disable actionsAaron Durbin2013-05-151-8/+11
| | | | | | | | | | | | | | The 5V rail should be enabled on S5->S3 transitions and disabled on S3->S5 transitions. BUG=chrome-os-partner:19398 BRANCH=none TEST=successful state transitions: S0,S3,S5,G3 Change-Id: If9fd7ef16f015136238dd18f64602ecf33d9ec4a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51359 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* haswell: fix S3 resume pathAaron Durbin2013-05-153-4/+2
| | | | | | | | | | | | | | | | The PROCPWRGD signal is not well documented. It's not known if it is an input or an output. Emperically it was discovered that driving this pin during the resume path causes resume to fail. Therefore, ignore the pin by setting it to an input. BUG=chrome-os-partner:19398 BRANCH=none TEST=successful state transition from S0 to S3 and back to S0 Change-Id: I55dc16c75c286af06806e2513197f0bb2c7b9d04 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51358 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Relax timing constraints in hooks testVic Yang2013-05-151-2/+2
| | | | | | | | | | | | | | Current timing constraints are too tight that the test sometimes fails when it shouldn't. BUG=chrome-os-partner:19236 TEST=Pass the test BRANCH=None Change-Id: Ib94ff44691ba36f14dbf02319d0371770b5ece5d Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51250 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Add thermal engine testVic Yang2013-05-158-9/+274
| | | | | | | | | | | BUG=chrome-os-partner:19236 TEST=Pass the test. BRANCH=None Change-Id: I1c96437e1fb3492faa5352383f852dc1d2718ace Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51248 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* spring: Update PMU ADC constantVic Yang2013-05-151-3/+7
| | | | | | | | | | | | | | The current sense resistor has changed. Update constant here to reflect the new values for DVT1. BUG=None TEST=Build Spring BRANCH=Spring Change-Id: Ib27c45cef569fa758db2fbb428150c8c2b6732ef Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/49892 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Minor tweaks to haswell power sequencingDuncan Laurie2013-05-141-8/+20
| | | | | | | | | | | | | | | | | - pass through the eDP VDD enable from PCH - Bring up suspend rail after DPWROK and before RSMRST, as indicated for deep sleep sequencing - de-assert CPU_PGOOD on S0->S3 transition, it was getting left enabled BUG=chrome-os-partner:19398 BRANCH=none TEST=successful state transition from G3 to S0 and back to G3 Change-Id: Ie711275d6121edccff60b2de08b71575d2d035b7 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51154 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* do not store the keyboard state on the stackVincent Palatin2013-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | As our stack for the keyboard scanning task might be small (256 bytes on STM32), we store the full keyboard state in a global instead of the stack to avoid consuming 16 bytes there. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:19389 TEST=run on Spring with CONFIG_OVERFLOW_DETECT and see that the KEYSCAN task is now consuming 248 bytes of stack instead of 264. Change-Id: I2dd7815f36e6807e7b9e88d59f8fd8a14b1988ab Reviewed-on: https://gerrit.chromium.org/gerrit/51028 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>
* Add hook testVic Yang2013-05-145-2/+161
| | | | | | | | | | | | | Test of hook functionality. BUG=chrome-os-partner:19236 TEST=Pass the test BRANCH=None Change-Id: I4700f3061edd0707932e935a719fc73c3976892e Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50957 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Show run time of unit testsVic Yang2013-05-141-2/+7
| | | | | | | | | | | | | This is useful for finding out which test runs for too long. BUG=chrome-os-partner:19235 TEST=Run tests and see run time logged. BRANCH=None Change-Id: I5cb6727b2e1017fce1107e4892c1898e66598492 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51105 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Redirect emulator output to stderr if a test failsVic Yang2013-05-141-3/+25
| | | | | | | | | | | | | | If a test fails, redirect emulator output to stderr so that it shows up even when V=1 is not set. BUG=chrome-os-partner:19235 TEST=Manual BRANCH=None Change-Id: I6d8e05eaa222ebe043556bfcd3f63ca7e27c2721 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51097 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* slippy: Basic power sequencingDuncan Laurie2013-05-143-53/+564
| | | | | | | | | | | | | | | | | | Still some work to do here but this now works. NOTE: This makes the system behave like a normal cros device where the power is applied automatically. For some (other, unknown) reason the "reboot ap-off" is not passing flags correctly to keep it off. BUG=chrome-os-partner:19398 BRANCH=none TEST=successful state transition from G3 to S0 Change-Id: I694136b9611e18ac8fb7b1e960bd10caa258ce28 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51077 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Scale timer for emulatorVic Yang2013-05-142-2/+13
| | | | | | | | | | | | | | The timer is the only source of timing for the emulator. This means we can make it go faster without breaking the tests. This CL sets the default scale to be 3x faster than normal time. BUG=chrome-os-partner:19235 TEST=Pass all tests. Check the tests run faster. BRANCH=None Change-Id: Ib9035884b34f41c4e9aa2206284b5f1ec8fc0d1f Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50956
* spring: Fix a bug that ID_MUX is never switched backVic Yang2013-05-131-2/+9
| | | | | | | | | | | | | | | If the user unplug video dongle before it is detected and handled, we may be stuck with ID_MUX=1 and interrupt from TSU6721 disabled. This essentially breaks charging. BUG=chrome-os-partner:18997 TEST=Build and check charging port still works. BRANCH=spring Change-Id: I93e69287d07947fef743b4674857e52c26513835 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50969 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* spring: Pull more current from video dongleVic Yang2013-05-131-6/+10
| | | | | | | | | | | | | | | | | | We cannot know how much current we can pull from video dongle, so let's just try to pull as much as possible up to 2A. BUG=chrome-os-partner:19324 TEST=Plug in video dongle and see 3.3V output. TEST=Plug in video dongle with supplied charger, and see 50% PWM duty cycle. TEST=Plug in video dongle with normal charger, and see 70~80% PWM duty cycle. BRANCH=spring Change-Id: I8b503f886fcafaa11e6757a5059ce673a8ed53cc Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50963 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* slippy: Enable internal pullup for recovery pinDuncan Laurie2013-05-131-1/+1
| | | | | | | | | | | | | | | | The recovery pin input from servo is open drain and needs an internal pullup enabled so it is not always low. BUG=chrome-os-partner:19398 BRANCH=none TEST=manual: ensure rec_mode can be turned off $ dut-control rec_mode:off rec_mode rec_mode:off Change-Id: I387a53eb5b64bb0bf3a87fc47b5cca9b2063f6a9 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50993
* Clarify help text for dumb USB port power controlDuncan Laurie2013-05-131-5/+5
| | | | | | | | | | | | | | | | | | The help text says to pass 0 or 1 for the mode but the code only accepts "on" or "off". Fix up the help text to match and have the display output for the port status also use on/off so it is consistent with the input. BUG=chrome-os-partner:18825 BRANCH=none TEST=manual: verify "usbchargemode 0 on" works as it is explained in the help text. Change-Id: Ib32dc68af93989d277aa84a1cb53ae9b66a8b595 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50838
* LM4: Support configurable host UART interfaceDuncan Laurie2013-05-134-59/+71
| | | | | | | | | | | | | | | | | | | | | | | Slippy uses UART2 instead of UART1 and so the EC needs to be able to tolerate having the host use a different interface. There are of course many ways to accomplish that but this approach adds two config variables to specify the host uart and the host uart irq. The UART port setup is split out to allow them to be configured separately rather than needing to be adjacent in a for loop. The interrupt functions were renamed (to ec and host) in order to indicate which interface they are responsible for. BUG=chrome-os-partner:19356 BRANCH=none TEST=boot slippy and see host serial output Change-Id: I1913ff3d650f329224c9654eee7bb7412fae5402 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50837
* Clean up SPI GPIOsRandall Spangler2013-05-133-20/+2
| | | | | | | | | | | | | | | | | | | SPI is always enabled on pit, so remove #ifdefs SPI1_CLK was aliased to AC_STATUS, which is left over from snow and doesn't exist on pit. That caused it to be driven high briefly during EC boot. Also set SPI pins for 40MHz speed so we can try faster SPI clock. BUG=chrome-os-partner:19304 BRANCH=none TEST=boot system; sspi 2:0 256 9f prints a bunch of FDs then FEEC010001 Change-Id: I10352cff3669d6a087939d9d8e302d70708e9ee3 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51023 Reviewed-by: Doug Anderson <dianders@chromium.org>
* Tidy comments for I2C passthru messageRandall Spangler2013-05-131-3/+3
| | | | | | | | | | | | | No code changes; just fix a few comments. BUG=chrome-os-partner:18778 BRANCH=none TEST=build code Change-Id: I7ed32b5af01a6dbd401334175b5a1b5b4786cac7 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51017 Reviewed-by: Doug Anderson <dianders@chromium.org>
* slippy: Make EC_RCIN_L pin output and high by defaultDuncan Laurie2013-05-131-1/+1
| | | | | | | | | | | | | | This is causing the host to reset because this pin is going low when it is left as open drain, despite having a 3.3V pullup. BUG=chrome-os-partner:19355 BRANCH=none TEST=manual: boot on slippy without RCIN# causing reset Change-Id: I59e9316e85ce618edc84c7dd988d70ea4de1e71a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50836
View Lorry Controller Status