summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Clear OWNERS for factory/firmware branchfirmware-snow-2695.90.BBrian Norris2021-09-101-0/+1
| | | | | | | | | | | | BUG=none TEST=none Change-Id: I0f03f432ada1064ffba9595be78ca7ab4d25ecd1 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3155249 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* fix signedness issue in deep sleep delayVincent Palatin2012-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | From time to time, the next timer deadline might have just expired aftering entering the idle loop, so the delay might be negative, it's a bad idea to use an unsigned variable... Now, in the uncommon case where the timer is expired, the next_delay is negative, so we use the "normal" wfi path and as the timer interrupt is pending in that case, we return directly. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=chrome-os-partner:13364 TEST=On Snow, plug a servo on EC serial console, shutdown the machine, unplug AC and wait for several hours. Observe we no longer have spurious watchdog reboots. BRANCH=snow Original-Change-Id: I40c7aa0fc7c1d6f9a5efaa1e7fc6615ed457196b Reviewed-on: https://gerrit.chromium.org/gerrit/33149 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit b4d73d3c72d5773e39812ba069dfff12d6da71c1) Change-Id: I36fba48783bc8b9e4687c4194d16aea7af989ca8 Reviewed-on: https://gerrit.chromium.org/gerrit/33185 Reviewed-by: Vic Yang <victoryang@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org>
* Add capability to auto-hash correct size for EC-RO or EC-RWRandall Spangler2012-09-123-49/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the host needs to tell the EC how big this image is (which it knows, but it's inconvenient for it to provide). BUG=chrome-os-partner:13511 BRANCH=all TEST=manual 1. ectool echash recalc ro -> prints hash of RO code (offset 0) 2. ectool echash recalc rw -> prints hash of RW code (offset non-zero) In each case, size should be an exact number and not the size of the whole RO or RW section. So for link, output should be something similar to: localhost ~ # ectool echash recalc ro Hashing EC-RO... status: done type: SHA-256 offset: 0x00000000 size: 0x00012a64 hash: 03a66c076d6dd4b4aa9ed6386713f45291f5143f9af2093003e632485899daf1 localhost ~ # ectool echash recalc rw Hashing EC-RW... status: done type: SHA-256 offset: 0x00014000 size: 0x000123d1 hash: 0d6225e70f0b1e0419e987370371e00783f945827ef25915a8fb8549159dd2a4 Signed-off-by: Randall Spangler <rspangler@chromium.org> 3. At ec console, 'hash ro' or 'hash rw' should regenerate the same hash values printed above. Change-Id: I3f6085d29927b8cdf9dabc6930f0fdc7222bd8b5 Reviewed-on: https://gerrit.chromium.org/gerrit/33123 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Ready: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 88ff608ae261ceca193e7d5689dc67b1536ce3eb) Reviewed-on: https://gerrit.chromium.org/gerrit/33144 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Fix not setting in_progress flag when starting hash computationRandall Spangler2012-09-121-1/+1
| | | | | | | | | | | | | | | | | | | This allows recomputing hash after EC boots. BUG=chrome-os-partner:13988 BRANCH=all TEST=manual 1. hash 2048 2048 2. hash 0 2048 3. hash -> hash value should be different than in step 1 Change-Id: Id66d0655a143b5190b5d8949b0fa9a18dbbc05f4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/33118 Reviewed-by: Simon Glass <sjg@chromium.org> (cherry picked from commit e212b100cc6473984c0f1a2f2fe7cc9012ddd66b) Reviewed-on: https://gerrit.chromium.org/gerrit/33129
* gaia_power: Report power on reasonSimon Glass2012-09-101-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Report the reason for a power on, to assist with debugging. BUG=chrome-os-partner:11307 BRANCH=snow TEST=manual Build and boot on snow See that power on reason is now reported > 0.003508 power on 2 [0.028674 AP running ...] ... 12.163780 ending loop 2 Shutdown complete. [batt] state discharging -> idle 17.801167 power on 4 Overriding CHARGER_INT with CHARGER_INT on EXTI4 [17.825873 AP running ...] 17.826071 XPSHOLD seen [batt] state idle -> discharg Change-Id: I2044419b330a74d19d8c4e63fa8853aa477b4df1 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32301 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit e6d9ea96f3914dd3de08ba3bcea24acd4097e7cd) Reviewed-on: https://gerrit.chromium.org/gerrit/32894 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org> Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
* snow: Clear state of charge calculation window on state changeRong Chang2012-09-101-4/+19
| | | | | | | | | | | | | | | | | | | The moving average window contains previous discharging state of charge values after state change. This change resets the index to make it calculate only new battery readings. Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:13846 TEST=none Original-Change-Id: Ifc6c6208dea8edf262e7294972d7321501b709e2 (cherry picked from https://gerrit.chromium.org/gerrit/32865) Change-Id: Ic7fcac9dfdd499fd0d5a3d1598defb44278509df Reviewed-on: https://gerrit.chromium.org/gerrit/32897 Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* snow: Check state of charge using moving averageRong Chang2012-09-101-1/+38
| | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:13846 TEST=manual Connect EC UART console and discharge snow device. The system should be turned off when average state of charge is lower than 2.5%. Original-Change-Id: Iab9797d0aa6b159bedd8ce0d2fa72c6458cd14ac Reviewed-on: https://gerrit.chromium.org/gerrit/32693 Commit-Ready: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org> Reviewed-by: Sameer Nanda <snanda@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit e21db5e488259d5bcab1a8429367b5c8b35cfc27) Change-Id: Ic8d47f3ec43f6bda4a97637f451b8ba2ff675bd0 Reviewed-on: https://gerrit.chromium.org/gerrit/32852 Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* Switch to variable-size stacksRandall Spangler2012-09-1025-188/+260
| | | | | | | | | | | | | | | | | | | | | | | | | | | Increase stack size slightly for vboot hash task since the vboot SHA256 function allocates ~300 bytes of stack data. Reduce stack size for watchdog, power LED, and a few other tasks with simple call trees where we can be sure an error path isn't going to blow past the reduced stack. This frees up ~1KB of RAM on STM32. BUG=chrome-os-partner:13814 BRANCH=all TEST=boot system; shmem should show more unused RAM; taskinfo should show tasks still have unused stack Origina-Change-Id: I47d6b77564a0180d15d86667cc0566a8919b776e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32608 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit a3d62a3700206b9cd34e129f6a04967bed5e46e4) Change-Id: Id5a62ba4d0c1985a79b0979e28029b5969270945 Reviewed-on: https://gerrit.chromium.org/gerrit/32784 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Allocate stacks separately from task context structsRandall Spangler2012-09-101-42/+63
| | | | | | | | | | | | | | | | | | | | This is a precursor to supporting task-specific stack sizes. BUG=chrome-os-partner:13814 TEST=boot; taskinfo shouldn't print garbage BRANCH=all Original-Change-Id: Iff6cee8b5f292dd026244239c99ba2252e75cf12 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32592 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 22d13781dcd006f9305956d33bf1ce1581454d2e) Change-Id: I383f09df913e609f5f15edfbc80296c67d46ae54 Reviewed-on: https://gerrit.chromium.org/gerrit/32781 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Track current task directly instead of computing from stack pointerRandall Spangler2012-09-103-53/+15
| | | | | | | | | | | | | | | | | | | | | | This is a precursor to supporting task-specific task sizes. I've benchmarked this vs. the current stack pointer method; no measurable performance difference. BUG=chrome-os-partner:13814 TEST=boot EC; taskinfo; if it boots and doesn't print garbage, it worked BRANCH=all Original-Change-Id: Ia326c3ab499ac03cce78dbacaa52f735601a171e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32603 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit d66ef1213dc1fa015ffc7458ab9d67a669a326bc) Change-Id: I878787192c432e0c78a29c99aecb4077adba80b8 Reviewed-on: https://gerrit.chromium.org/gerrit/32779 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Track amount of stack used for each EC taskRandall Spangler2012-09-102-5/+31
| | | | | | | | | | | | | | | | | BUG=chrome-os-partner:13814 TEST=taskinfo; should show stack used per task BRANCH=all Original-Change-Id: Ie40a70a8647c767ea6ec3d164f81c63b62b5008e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32590 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit a8a3c6d9be83e260279ad4da469fc60a5a05d0fd) Change-Id: I22cef89198be0fff18fa80b91f03cefe3f3a8acc Reviewed-on: https://gerrit.chromium.org/gerrit/32777 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* snow: Stop discharging when temperature lower than 0CRong Chang2012-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:13844 TEST=manual When run on battery, system will poweroff on battery temperature < 0C. Original-Change-Id: Ib7f3a5f5149f038e83c67c7ca86f8eb22c4b1a7b Reviewed-on: https://gerrit.chromium.org/gerrit/32686 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Ready: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org> (cherry picked from commit e0f9dc74d9d105ecdad992a79b4d49dcce128b68) Change-Id: I76c32b0d0921d4fb0312453deed44e6f0bab0e98 Reviewed-on: https://gerrit.chromium.org/gerrit/32694 Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* snow: make pmu charge ranges inclusiveDavid Hendricks2012-09-081-2/+2
| | | | | | | | | | | | | | | | Since we work with integral values for battery temperature, lower limits need to be inclusive when determining when to enable/disable charging. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=none TEST=none (yet...) Change-Id: Icfc52066ca469b56ebc411bad864111848eab197 Reviewed-on: https://gerrit.chromium.org/gerrit/32656 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* snow: re-configure I2C arbitration pins at AP off/on to fix leakageDavid Hendricks2012-09-071-15/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This (re-)configures the I2C arbitration lines as floating inputs when the AP powers off, and restores them strictly before the AP powers on. This is intended to prevent leakage when the AP is off and arbitration is not needed. This CL does not impact the AP on/suspend case. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:12573,chrome-os-partner:12381 TEST=manual (see notes below) - PA4: SPI1_NSS / AP_CLAIM, input w/ pull-up when AP on - PA6: SPI1_MISO / EC_CLAIM, output when AP is on - Both floating when AP off 8 = input with pull up/down, 4 = floating input, 1 = output AP off (before this CL): > rw 0x40010800 read 0x40010800 = 0x41484144 > gpioget SPI1_NSS 0* SPI1_NSS > gpioget SPI1_MISO 1 SPI1_MISO AP off (after this CL): > rw 0x40010800 read 0x40010800 = 0x44444144 > gpioget SPI1_NSS 0* SPI1_NSS > gpioget SPI1_MISO 0* SPI1_MISO AP on or suspended (before and after this CL): > rw 0x40010800 read 0x40010800 = 0x81484144 > gpioget SPI1_NSS 1* SPI1_NSS > gpioget SPI1_MISO 1* SPI1_MISO Additional testing: - "pmu 10000" and "cros_test i2c" in u-boot only showed the FET2 control changing (as expected). - "pmu 10000" and "while [ 1 ] ; do i2cdump -f -y -r 0-24 4 0x48 b ; done" and ran "suspend_stress_test" for a couple dozen iterations. The registers only changed as expected (FET1 and FET6 turned off when suspending). Change-Id: Ibd0dc50492683f26eec17f8c14da1d7367e3f869 Reviewed-on: https://gerrit.chromium.org/gerrit/32638 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Snow: Always reset i2c when it's initiallizedCharlie Mooney2012-09-061-63/+25
| | | | | | | | | | | | | | | | | | | | | | | | Previously, the i2c init code would only preform a software reset of the i2c peripheral it is initializing when it was already BUSY. It turns out it's always BUSY and the init functions are now used in two other places where they always want the software reset as well, so this pulls out the conditional, and makes it always do it. BUG=chrome-os-partner:13388 TEST=Standard i2c stress tests. Running a loop of i2cdumps from the AP while looping i2c transactions on the EC run without any errors. Even across multiple reboots, and jumping back and forth from RO to RW on the EC via sysjump while the AP is still stressing the bus. BRANCH=snow Original-Change-Id: I6b3aaae0042844033bb04cf5cb4171c8be041ad9 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> (cherry picked from commit d9d31cbbdc7b110912f91fff959cde4dfad6ef9d) Change-Id: Ic3c51672819b96405a1190fbba35a78c7892c982 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32471 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
* make build_info fixed-lengthDavid Hendricks2012-09-061-2/+5
| | | | | | | | | | | | | | | | | | This makes build_info fixed-length so that it can be properly transmitted via I2C. The host buffer size will be used, which may in fact be quite a bit longer than necessary. Build info will be truncated if it's longer than the max response size. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:11608 TEST=Tested on Snow, logic analyzer confirmed NAK and STOP condition set properly after final byte transmitted via I2C (see BUG) Change-Id: Iccae0f3c2905d442c8eebff42aa19bf940e5f71f Reviewed-on: https://gerrit.chromium.org/gerrit/32399 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Revert "Save panic data across reboots, and add panicinfo command"David Hendricks2012-09-063-94/+42
| | | | | | | | | | | This reverts commit 5f92fdc0b6ec36beeb5c1d447f052e5f77d29e39 Reverting based on Vincent's comment. Tested locally that this doesn't break compilation for Snow. Change-Id: I9d05ff300156448096af41b5cb2af972425dccf8 Reviewed-on: https://gerrit.chromium.org/gerrit/32396 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* snow: i2c: Reset i2c busses at bootup to unwedge themDavid Hendricks2012-09-051-4/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the EC got reset while some device on the bus was midway through a transaction, the bus may we wedged and all of our i2c transactions will fail. Try our best to unwedge the bus at bootup. Do this even if the bus doens't look wedeged because some device on the bus may be in a quiescent state at the moment but be waiting to pounce on the bus when it sees the clock start running. BUG=chrome-os-partner:13378 TEST=Capture scope trace in normal bootup TEST=Capture scope trace in failure bootup with an extra print statement in the code when scl/sda were not high at bootup. Forced this case by looping i2c transactions to tpschrome and rebooting midway through. BRANCH=snow Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> (Note: Credit for this patch goes to Doug, I just uploaded the initial work-in-progress version to gerrit --dhendrix) Change-Id: I8da69b5294160048f91461159c039f8f2093e971 Reviewed-on: https://gerrit.chromium.org/gerrit/32168 Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32361 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* stm32l: Add stub for gpio_set_flags()David Hendricks2012-09-051-0/+9
| | | | | | | | | | | | | | | | | | This is just to get around compilation failures caused in shared stm32f/l code. BRANCH=snow BUG=none TEST=compiled ec-utils for daisy Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I0f6e984ce22ae6f71d47053d801f1c62af54a45b Reviewed-on: https://gerrit.chromium.org/gerrit/32262 Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32360 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* daisy: add GPIO_I2C_* pins to board header and GPIO tableDavid Hendricks2012-09-052-1/+12
| | | | | | | | | | | | | | | | | | This adds the I2C pins to the listing of Daisy GPIOs. This allows us to use GPIO_I2C_* for shared Daisy/Snow code. BRANCH=snow BUG=none TEST=compile tested for Daisy and Snow Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I7413921b2dbe3f8cd79c88ab4bfc8ace0d72bd56 Reviewed-on: https://gerrit.chromium.org/gerrit/32261 Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32359 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Change UART interrupt to priority 2Simon Glass2012-09-051-1/+1
| | | | | | | | | | | | | | | | | | The UART probably shouldn't have such a high priority. Reduce it to below that of comms driver interrupts. BUG=none BRANCH=none TEST=manual Boot and see that UART console still functions Change-Id: If906c9c4c37617d076ad8415d126b50f52d8b09e Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32077 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32358 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* comm-i2c.c upgrades to protocol v2.Louis Yung-Chieh Lo2012-09-052-51/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | Old i2c code uses protocol v1, which cannot handle veriable-length response (unknown lenght to calculate checksum). So, upgrade to procotol v2 anyway since command v1 needs protocol v2. BUG=chrome-os-partner:11608, Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> BRANCH=None TEST=on snow, and both command v0/v1 are working on protocol v2. ectool version ectool hello ectool echash ectool flashinfo ectool flashprotect ectool flashwp Change-Id: Id8532fe51359dce18839d37de8a8c8669754041c Reviewed-on: https://gerrit.chromium.org/gerrit/31838 Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org> Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Tested-by: Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32357 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* make pmu register dump more verboseDavid Hendricks2012-09-051-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a row that displays register offset and increases highest register offset to 18. The new output is 79 columns wide. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=none TEST=see below Before: pmu PMU: 0c 00 3e 00 12 20 4b bf ff ff 00 12 pmu events b00001100 ac gpio 0 After: > pmu 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 PMU: 0c 00 fe ff 12 20 4b bf ff ff 00 12 1e 1e 1e 1f 1f 1f 02 1f 1f 02 20 00 00 pmu events b00001100 ac gpio 0 Change-Id: I5058e5aee1affadaa00f20de785c1ea70eaea82e Reviewed-on: https://gerrit.chromium.org/gerrit/32082 Reviewed-by: Rong Chang <rongchang@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32356 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Save panic data across reboots, and add panicinfo commandRandall Spangler2012-09-053-42/+94
| | | | | | | | | | | | | | | | | | | | | | | | Jump data now precedes the panic data, if any, in memory. BUG=chrome-os-partner:7466 BRANCH=all TEST=manual 1. boot system 2. sysjump rw --> display should stay on and keyboard should still work (this verifies jump data is properly read across sysjump still) 3. crash unaligned --> system should reboot 4. panicinfo --> should print the same crash dump as before, with (NEW) 5. panicinfo --> ditto, without (NEW) 6. sysjump rw 7. panicinfo --> ditto, without (NEW) Change-Id: I88285724e82a15553ab25877e3d8ec4c74a4dd5a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32051 Reviewed-on: https://gerrit.chromium.org/gerrit/32355 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Use new panic stack on all platformsRandall Spangler2012-09-056-28/+11
| | | | | | | | | | | | | | | | | | | Now that the panic stack goes at the end of RAM, there's no overhead to using it on all platforms. When it was a dedicated block of memory, we needed to turn it off on some low-RAM platforms (e.g. Snow). BUG=chrome-os-partner:7466 TEST='crash divzero' or 'crash unaligned'; should print dump and reboot BRANCH=all Change-Id: Iddfeb134e237538215df51abe4e16ee831b3ae2d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32037 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32354 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Place panic data and stack at end of RAMRandall Spangler2012-09-052-65/+154
| | | | | | | | | | | | | | | | | This is in preparation for saving panic data across reboots for later retrieval. BUG=chrome-os-partner:7466 TEST='crash divzero' or 'crash unaligned'; should print dump and reboot BRANCH=all Change-Id: I997d160b00d03759eb9c69b53ab0f7a5ae144183 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31951 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32353 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Minor fix for gcc 4.7 build problem for chromeos-base/ec-utils.Han Shen2012-09-051-1/+1
| | | | | | | | | | | | | | | | | BRANCH=snow TEST=Built using gcc 4.7. BUG=None Signed-off-by: Han Shen <shenhan@google.com> Change-Id: I425aec5a1e99bf64aab3acf7dbecdf1038195419 Reviewed-on: https://gerrit.chromium.org/gerrit/32025 Reviewed-by: Rong Chang <rongchang@chromium.org> Commit-Ready: Han Shen <shenhan@chromium.org> Tested-by: Han Shen <shenhan@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32352 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* snow: Don't turn on SPI clockDoug Anderson2012-09-051-3/+0
| | | | | | | | | | | | | | | | We're not using SPI on snow so no reason to clock it on. BUG=None TEST=Things still boot BRANCH=snow Change-Id: I14fe227ba75501dea28f6a91645c14ae433aac2d Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31957 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32351 Tested-by: David Hendricks <dhendrix@chromium.org>
* Snow:Recover from stray pulses on i2c battery lineCharlie Mooney2012-09-051-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The I2C peripheral on the EC can get confused if there is a very specific kind of noise introduced to the line. This can be manifested by jiggling the battery jack. It gets the I2C into a state where everything seems fine outwardly, but the device refuses to even transmit START bits on the line. It appears that one of the stray pulses on the i2c bus gets the device off set from the actual bytes, leaving it misinterpreting everything and waiting forever. In this case, there is only one way to recover (as you can't directly access these aspects of the internal state) and that is to do a software reset of the i2c peripheral. Here I add some code to check for the condition where the EC was unable to even send a START bit, and do a software reset of the i2c to recover. BUG=chrome-os-partner:13161 TEST=With a faulty-battery-jack-board: Boot board, test that i2c works by running "pmu" on the EC console. Jiggle battery jack repeatedly until errors are displayed on console. Try to run pmu again. Make sure that it recovers gracefully, and do this many times. BRANCH=snow Original-Change-Id: I91b8ef0c6f6079bc63f4a6a1bc91f67d19db9fc0 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> (cherry picked from commit 063ea689b976506b2371b14d4a96822838b4a781) Change-Id: I309ac545d0c3a86792eea6962a3ca46cad10b2a6 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32319 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
* stm32: Store VbNvContext in backup registersChe-Liang Chiou2012-09-055-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This would improve boot speed when compared to storing in eMMC because initialing eMMC is slow. So far other platforms do not have this need because CMOS is quite efficient; thus it is left unimplemented in lm4. Signed-off-by: Che-Liang Chiou <clchiou@chromium.org> BRANCH=snow BUG=chrome-os-partner:10660,13094 TEST=On Snow, see VbNvContext is preserved across power cycles (you have to patch U-Boot to test this) Original-Change-Id: If5072c678b87bc47a3a82a1dff2afa3896304f36 Reviewed-on: https://gerrit.chromium.org/gerrit/31832 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Che-Liang Chiou <clchiou@chromium.org> (cherry picked from commit 8a9471e5ef305a2aea81e6cb62a17d6966865b6b) Change-Id: Ia09a8977f7053a20c97a3832bf60f81f2e11e271 Reviewed-on: https://gerrit.chromium.org/gerrit/32341 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
* stm32: Squeeze fakewp backup register for VbNvContextChe-Liang Chiou2012-09-051-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We squeeze 2 bytes out of fakewp backup register so that we would have full 16 bytes for VbNvContext. As fakewp will go away real soon and it needs just 1 bits, we move it to saved reset flags register's most significant bit, which is currently unused. Signed-off-by: Che-Liang Chiou <clchiou@chromium.org> BRANCH=snow BUG=chrome-os-partner:10660,13094 TEST=manual Make sure reset flags are still preserved: 1. reset with keyboard. flags -> reset-pin 2. trigger watchdog reset. flags -> reset-pin watchdog 3. 'reboot soft preserve' flags -> reset-pin watchdog soft 4. trigger watchdog reset. flags -> reset-pin watchdog 5. 'reboot soft' flags -> reset-pin soft Make sure fakewp is still preserved: 1. 'flashinfo' -> no flags 2. 'fakewp 1' -> 'wp_gpio_asserted' 3. 'flashwp enable' -> 'wp_gpio_asserted ro_at_boot' 4. 'reboot' -> 'wp_gpio_asserted ro_at_boot ro_now' 5. 'fakewp 0' -> 'ro_at_boot ro_now' 6. 'reboot' -> 'ro_at_boot' 7. 'fakewp 1' -> 'wp_gpio_asserted ro_at_boot' 8. 'flashwp rw' -> 'wp_gpio_asserted ro_at_boot rw_at_boot' 9. 'reboot' -> 'wp_gpio_asserted ro_at_boot ro_now rw_at_boot rw_now' 10.'flashwp disable'-> error 7 11.'flashwp norw' -> 'wp_gpio_asserted ro_at_boot ro_now rw_now' 12.'reboot' -> 'wp_gpio_asserted ro_at_boot ro_now' Original-Change-Id: Ibb7dc8aa224d3226bbaac217e494565e448b5858 Reviewed-on: https://gerrit.chromium.org/gerrit/32041 Commit-Ready: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit f7291a50b8055f9ec0c69d79c2d5f2a881b53df8) Change-Id: If26a5301fd34d6e57e7a228b315f2225531b3f42 Reviewed-on: https://gerrit.chromium.org/gerrit/32340 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
* Snow: Add checking for more i2c error casesCharlie Mooney2012-09-051-9/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a number of ways for the i2c to fail, and some are quite rare and have thus been overlooked. It's easy enough to handle these rationally, but we have to check for them. This checks that the i2c peripheral is actually in slave mode when it gets a slave event firing (stopping it from accidentally sending garbage on the tail end of another request) and makes sure a STOP bit is sent in the event that the BUSY signal isn't set at the moment we check it (if we check it at the moment that it is sending a 1, it may not be set). Finally, if the i2c can't send a STOP bit, the peripheral is reset to get it back to a sane state, specifically it needs to not be stuck in master mode forever. BUG=chrome-os-partner:13380 TEST=Boot machine normally, from AP run "while true; do ectool version; done" to start a loop of the long transaction that sends lots of spurious reads too. Then on the EC, run "pmu 10000" and then "battery 1000" to stress the bus from all sides. Once the EC is done, stop the AP's side of the stress test, and make sure the bus is still functioning. Tested the resetting, by making it reset the peripheral every 150 times, and confirmed that the following transfers work just fine. BRANCH=snow Original-Change-Id: I265b3cddd25e1fd6ab4e8cf9c7290c875fad89f8 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> (cherry picked from commit f3bb25cd8ccb22e7aa33e5cdd600912ea5fe1c96) Change-Id: Ifdd76a255d963744c62a4995743a4abf4b9dfc0a Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32241 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
* Fix stack overflow in hostcmd commandRandall Spangler2012-09-051-5/+21
| | | | | | | | | | | | | | | | | It was putting the entire parameter buffer for a host command on the stack. Now it uses shared memory. BUG=chrome-os-partner:13613 TEST='hostcmd 4' should not cause a crash several seconds later BRANCH=link (snow is also affected, but doesn't have enough shared memory to put the command buffer there either) Change-Id: I8405d88857ee92a5cee429e156df5e645d5d864d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32181 Reviewed-by: Vic Yang <victoryang@chromium.org> (cherry picked from commit e2de50ee7645b07eb70149748b51f5fc8b32b12d) Reviewed-on: https://gerrit.chromium.org/gerrit/32191 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
* Snow: WP_RO should be 0x10000 (including pstate).Louis Yung-Chieh Lo2012-09-055-5/+12
| | | | | | | | | | | | | | | | | To reflect the CL 00799d5 that moves the pstate to 0xf000. BUG=chrome-os-partner:12799 TEST=Build in chroot. snow: WP_RO is changed from 0:0xf000 --> 0:0x10000. daisy: WP_RO is unchanged. link: WP_RO is unchanged. Change-Id: I572bae3f624744e60d13a762875211beffc6c516 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/30670 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31448 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Snow: Dont hang when trying to pmic-reset boardCharlie Mooney2012-09-042-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Old Snow board (non-MP) don't have the capability to hard-reset their pmics unless they've been manually fixed to do so. This means that if you have an old board, with a new copy of the EC on it and it tries to hard-reset the system, it will hang forever and trigger the watchdog. Since there's no way for the EC to check if the hardware fix exists on its board, this adds a timeout after trying to reset. If the board has the fix, it will reset before the timeout expires. Otherwise, it will print a warning message before returning, to prevent it hanging. Additionally, it also fixes the places board_hard_reset() is called to deal with the new possibility of it returning. BUG=chrome-os-partner:13508 TEST=On a machine with the hardware rework and one without it, go to the EC console and run "pmu reset" to try and force a reset. The one with the fix should reset immediately, and the one without should warn you that it tried (and failed) to reset. BRANCH=snow Original-Change-Id: I493122ee4da539f363a31f624ab9dd7db8068ec8 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> (cherry picked from commit 3400e5df201ddf1d69acb86075fe334c26579a2b) Change-Id: Iac9aff9240cf9c1ae85cc92397bea94699bf3bcd Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32068 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
* snow: Change charging temperature rangeRong Chang2012-08-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:13491 TEST=manual Charging can start in temperature range 5C ~ 45C Charging stops when temperature >= 60C System can be powered on when temperature < 100C Original-Change-Id: Ic4d66f7d1877f819892328e298b7442a763ced7a Reviewed-on: https://gerrit.chromium.org/gerrit/32019 Commit-Ready: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> (cherry picked from commit 1276132c33795f9188b429e73d1402589280b04e) Change-Id: I9ccac53afb7c8d6be0baa311ea0997761ac87241 Reviewed-on: https://gerrit.chromium.org/gerrit/32021 Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* Snow must assert ENTERING_RW GPIO when jumping between imagesRandall Spangler2012-08-305-4/+4
| | | | | | | | | | | | | | | | | BUG=chrome-os-partner:13439 BRANCH=snow TEST=manual 1. Ctrl+Refresh+Esc; should go to INSERT screen 2. Ctrl+D; should show TODEV (this confirms it's still possible to get into dev mode the right way) 3. From EC console, 'sysjump rw' 4. Ctrl+D; should NOT show TODEV (this confirms the bug is fixed) Change-Id: Ic4879cb0a7fc47527eac1a5a727f3225744ff880 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31979 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
* snow: re-factor i2c initDavid Hendricks2012-08-303-15/+43
| | | | | | | | | | | | | | | | | | | | | | | | This re-factors i2c initialization to simplify it and make it follow the correct order. This is intended to fix a bug where the I2C lines could be driven low for no good reason on EC startup, potentially causing issues with other devices. The ordering should be: 1. Setup pins as inputs on EC startup. 2. Initialize I2C module(s) 3. Re-configure pins as alternate function. (Thanks to dianders for pointing out this bug) Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:13443 TEST=Tested by examining scope traces during EC reboot Change-Id: Ibb845f3fd538da387132b1c822929f8613de077d Reviewed-on: https://gerrit.chromium.org/gerrit/31966 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Minimum write size for Snow is 2 bytes, not 64 bytes.Bill Richardson2012-08-301-1/+1
| | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:12412 BRANCH=snow TEST=none The current constant is wrong. It was broken before, now it still may be broken but hopefully less so. Change-Id: Ia425bc45c4ccb0b4623fa802d4e5913389cb9d22 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31190 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit c12777fef3ac872731041fc07230ea0de240c355) Reviewed-on: https://gerrit.chromium.org/gerrit/31911 Reviewed-by: Puneet Kumar <puneetster@chromium.org> Tested-by: Puneet Kumar <puneetster@chromium.org>
* i2c: Enable arbitration GPIOs only when activeSimon Glass2012-08-292-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Only setup the arbitration GPIOs when CONFIG_ARBITRATE_I2C is set. BUG=chrome-os-partner:13064 BRANCH=snow TEST=manual build and boot on snow On the EC: > pmu 1000 In U-Boot: cros_test i2c See that there are no failures. Change-Id: I8a7724700ff79406527c3db8708833728eb9a978 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31305 (cherry picked from commit 581dd6a531aee42eade6774721117b110b40aeb8) Reviewed-on: https://gerrit.chromium.org/gerrit/31824 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Make AC status feature optional at compile timeSimon Glass2012-08-294-3/+25
| | | | | | | | | | | | | | | | | | This feature is not actually used on current platforms. Avoid setting up the GPIO unless it is specifically enabled. BUG=chrome-os-partner:13064 BRANCH=snow TEST=manual build and boot on snow. See the AC power GPIO does not change when un/plugging power. Change-Id: I6731625a19f30f6dd35471b126f3083b39747203 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31304 Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit eb2348d05f00839d28b98936deff3c925e180749) Reviewed-on: https://gerrit.chromium.org/gerrit/31823
* flash: Only erase flash block that contain dataSimon Glass2012-08-295-9/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It wastes time to erase blocks that are already erased and it is faster on stm32 to check first. Add a check in flash_physical_erase() on all chips, using a common flash_is_erased() function. BUG=none BRANCH=snow,link TEST=manual Do software sync in U-Boot and see that it succeeds. This tests that we can still erase and then boot a written image. It typically saves a second on a full sync over i2c. SMDK5250 # cros_test swsync -f SF: Detected W25Q32 with page size 4 KiB, total 4 MiB Flashing RW EC image: erasing, writing, done Flashing RO EC image: erasing, writing, done Full software sync completed in 22.949s SMDK5250 # Also see that second erase is faster: SMDK5250 # time mkbp erase rw time: 0.952 seconds, 952 ticks SMDK5250 # time mkbp erase rw time: 0.054 seconds, 54 ticks SMDK5250 # Change-Id: I3699577217fdbb2f212d20d150d3ca15fdff03eb Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/30851 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 21c1bf96282e8ac6bf6ff43cb537cbdefd84fc65) Reviewed-on: https://gerrit.chromium.org/gerrit/31822 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* move pmu_init_registers() from pmu_init() to chipset pre-init hookDavid Hendricks2012-08-291-4/+1
| | | | | | | | | | | | | | | | | | | | | This moves the PMU register initialization from pmu_init(), which gets called whenever the EC reboots/sysjumps (even when the AP is running), to a hook which will can called selectively when the AP is cold booting. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:13315 TEST=tested on snow - jumping between RO <--> RW no longer causes the screen to turn off due to resetting FET control regs. Change-Id: I5453bf86af50b84a05a259dc896f04d818b5641b Reviewed-on: https://gerrit.chromium.org/gerrit/31740 Reviewed-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31793
* gaia: notify chipset pre-init hook before turning on APDavid Hendricks2012-08-291-5/+9
| | | | | | | | | | | | | | | | | | This notifies the CHIPSET_PRE_INIT hook before turning on the AP. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:13315 TEST=tested in subsequent CL Change-Id: Ic2bc17ed2b561f640af53970d291e5d04d2f72e7 Reviewed-on: https://gerrit.chromium.org/gerrit/31739 Reviewed-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31792
* add a new hook for pre-chipset startupDavid Hendricks2012-08-294-0/+9
| | | | | | | | | | | | | | | | | | This adds a new hook that is intended to be called immediately before host chipset/AP startup to initialize components such as the PMU. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:13315 TEST=tested in subsequent patches Change-Id: I2b38208de9f0f51abc0b22c49547ee0c4c889b82 Reviewed-on: https://gerrit.chromium.org/gerrit/31738 Reviewed-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31791
* gaia: update ap_suspended usageDavid Hendricks2012-08-291-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL updates ap_suspended usage so that it's only updated when it makes sense to do so: - Clear ap_suspended during power_off() since it can only be reliably determined when the pull-up on PA7 is enabled (when AP is on). - chipset_in_state() should not re-assign ap_suspended. That was a hack to try to get around earlier brokenness. However, that does not really work since SUSPEND_L can appear to be asserted when AP is off and could cause ap_suspended to become inconsistent with the actual AP state. - When AP is on, ap_suspended should be managed by gaia_suspend_event. When AP is off, ap_suspended should be 0 ( Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:13200 TEST=tested on Snow using "power" command at EC console 1. AP running > power on 2. after running powerd_suspend > power suspend 3. "power off" at EC console > power off Change-Id: I88dad9f02d57fe7244bf607eea2088ee0b80b75a Reviewed-on: https://gerrit.chromium.org/gerrit/31627 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31790
* snow: toggle pull-up on PA7 (SUSPEND_L) on power on/offDavid Hendricks2012-08-291-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds hooks to re-configure SUSPEND_L (GPIO PA7) when the system turns on/off. When the system is turned on, PA7 will have its internal pull-up enabled. This is required since SUSPEND_L is driven by an open- drain buffer. When the AP is off, we can disable the pull-up (configure PA7 as floating input) to reduce leakage. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:12700,chrome-os-partner:13200 TEST=see notes below 1. Dump GPIO_A CRL when system is off: read 0x40010800 = 0x41484144 2. Dump GPIO_A CRL when system is on: read 0x40010800 = 0x81484144 3. Dump GPIO_A when system is put into suspend: read 0x40010800 = 0x81484144 4. Resume, see power LED react quickly. 5. Soft poweroff, dump GPIO_A CRL: read 0x40010800 = 0x41484144 Change-Id: I62f02324a2a1fbfb6eff539fc6fdc35a035fa020 Reviewed-on: https://gerrit.chromium.org/gerrit/31315 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31789
* snow: configure USART Rx as an input with pull resistorDavid Hendricks2012-08-292-6/+11
| | | | | | | | | | | | | | | | | | | | | | | USART1 has always had its Tx and Rx pins configured as "alternate function output". However, this turns out to be incorrect since there is no concept of an AF input on the STM32F. Instead, the Rx pin should be configured as an input (and the Tx remains an AF output). This also simplifies the console resume code since we only need to enable/disable the interrupt rather than reconfiguring the GPIO. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:12223 TEST=flashed on snow, EC console works Change-Id: Ia92dbbac16fc55d0db62381dfb487aeb4f4121b4 Reviewed-on: https://gerrit.chromium.org/gerrit/30941 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31788
* Add GEC lock mechanism.Louis Yung-Chieh Lo2012-08-2911-4/+782
| | | | | | | | | | | | | | | | | Basically re-use the gec lock code from flashrom package. BUG=chrome-os-partner:12319 TEST=Build and run on link. Only build on snow. while true; do ectool hello; done & ; run 10 instances. ; expect all instances runs okay. Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Change-Id: I11d5824f46810c6f5a04a564a81387cdea081697 Reviewed-on: https://gerrit.chromium.org/gerrit/29763 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31787 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* stm32: don't go to stop mode in suspendVincent Palatin2012-08-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | When the AP is suspended, we are using the timer TMR2 to do the power led "breathing", so we cannot cut the clocks as they are used for this PWM. The EC will be in idle mode instead of stop mode during S3. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=chrome-os-partner:8866 TEST=on Snow, suspend the AP and see you can still type in the EC console and the power led is "breathing". Change-Id: Ib4cce36c5a9bf649996bf627baeb30ef2a3221a8 Reviewed-on: https://gerrit.chromium.org/gerrit/30057 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org> Commit-Ready: <arscott@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/31786 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
View Lorry Controller Status