summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Clear OWNERS for factory/firmware branchfactory-2846.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/+/3155024 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* Snow: Dont hang when trying to pmic-reset boardCharlie Mooney2012-08-312-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 Change-Id: I493122ee4da539f363a31f624ab9dd7db8068ec8 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32043 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* Save panic data across reboots, and add panicinfo commandRandall Spangler2012-08-313-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
* Use new panic stack on all platformsRandall Spangler2012-08-316-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>
* Place panic data and stack at end of RAMRandall Spangler2012-08-312-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>
* Minor fix for gcc 4.7 build problem for chromeos-base/ec-utils.Han Shen2012-08-311-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>
* lm4: add warm reboot key combinationSameer Nanda2012-08-311-1/+35
| | | | | | | | | | | | | | | | | | | Added a warm reboot key combination that resets the CPU while preserving RAM contents. This will be helpful in debugging CPU/OS hard hangs since in conjunction with PSTORE_CONSOLE in the kernel, the kernel log messages from the previous boot will be preserved. BUG=chrome-os-partner:12780 TEST=reboot the system using alt-volume_up-r key combination. Upon rebooting, check pstore contents with "cat /dev/pstore/console-ramoops" and ensure that they are same as dmesg from the previous boot. BRANCH=link Change-Id: I0ec835a4646f442997c04dc3a086d4fac0cf01cf Signed-off-by: Sameer Nanda <snanda@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31992 Reviewed-by: Randall Spangler <rspangler@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 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>
* 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/31932
* snow: Don't turn on SPI clockDoug Anderson2012-08-301-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>
* 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/31647 Commit-Ready: David Hendricks <dhendrix@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Doug Anderson <dianders@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>
* 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>
* 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>
* 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>
* Revisit USB charge modesVic Yang2012-08-282-34/+25
| | | | | | | | | | | | | | | | | | "Auto" mode is observed to cause problems and thus is removed. This leaves only three modes: - Standard downstream port. USB 2.0 mode. 500mA. - Charging downstream port. BC1.2. 1500mA. - Dedicated charging port. BC1.2. 1500mA. BUG=chrome-os-partner:11550 TEST=Check all modes work as expected. Check no discharge between the first two modes. BRANCH=link CQ-DEPEND=31639 Change-Id: I41102a8bc3ac34ff9a1bf4e47c89cdb93a2c4eb5 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31616
* stm32f: remove gpio_set_alternate_function()David Hendricks2012-08-281-37/+0
| | | | | | | | | | | | | | | | | | | | | gpio_set_alternate_function() for STM32F is not used, and even if it were it would be incorrect. So for now it just takes up space. Unlike STM32L, alternate functions rely on toggling bits in AFIO remapping registers rather than setting a simple AF number. This would make writing a working version of this function trickier, and it may not be worth the effort. Signed-off-by: David Hendricks <dhendrix@chromum.org> BRANCH=snow BUG=none TEST=locally compiled for snow Change-Id: I2ce1e7aba2760a94819500af4e322812f3346ad3 Reviewed-on: https://gerrit.chromium.org/gerrit/31630 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Copy host command params out of LPC space during checksummingRandall Spangler2012-08-282-11/+23
| | | | | | | | | | | | | This prevents the host from rewriting them during the checksum operation. BUG=chrome-os-partner:13202 TEST='ectool version' should still work BRANCH=link Change-Id: Ib44f45b027c0a54ba40f70052728ba427dc71849 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31511 Reviewed-by: Simon Glass <sjg@chromium.org>
* gaia: Add a warm reboot functionSameer Nanda2012-08-283-0/+55
| | | | | | | | | | | | | | | | | | | | Added a warm reboot function that reboots the AP while preserving RAM contents. This will be helpful in debugging AP/OS hard hangs since in conjunction with PSTORE_CONSOLE in the kernel, the kernel log messages from the previous boot will be preserved. BUG=chrome-os-partner:13249 TEST=1. From EC console issue the "warm_reboot" command. Upon rebooting "cat /dev/pstore/console-ramoops" and ensure that the contents are dmesg of previous boot. 2. Reboot the system using alt-volume_up-r key combination. Upon rebooting, check pstore contents in the same manner as case#1 above. BRANCH=snow Change-Id: Ic8f0415da6182f4c1bc2d35b91302ceda5c19569 Signed-off-by: Sameer Nanda <snanda@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31523 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Snow: Adding in EC ability to hard reset pmicCharlie Mooney2012-08-285-44/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By pulling line gio_A15 high, you can for a hard reset of the pmic after the stuff resistor is changed. This change adds a function that you can call from the EC and trigger this event (board_hard_reset). The user has access to this command over the EC console by running "pmu reset" and it will force the emergency reset. The board_hard_reset function is used in the pmu's reset code. Whenever it is trying to initialize or shut down the pmu, it resets many or all of its registers over i2c. If the i2c commands fail to get a response from the pmu, the EC will now force a hard reset of the system, which restores everything, allowing for a restart to fix any situation where the pmu has gotten its configuration trashed. BUG=chrome-os-partner:12913 TEST=boot the machine. From EC console check the pmic's register values, then alter them. Run "pmu reset" to force a reset, and check the values again. They should be safe values, which you can confirm by powering on the AP. Repeat this from various starting states: only the EC on, AP on as well, and setting various registers to 0x00's and 0xff's. To stress test the hard-reset ability from the EC's POV, run while true; do echo "pmu reset"; sleep 5; done | cu -l DEVICE -s 15200 BRANCH=snow Change-Id: I911fb9623a7c106d1f993ee4681258c05d4dedae Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31524 Reviewed-by: Simon Glass <sjg@chromium.org>
* snow: toggle pull-up on PA7 (SUSPEND_L) on power on/offDavid Hendricks2012-08-281-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>
* stm32f: Preserve flash write protect info across sysjumpVic Yang2012-08-281-1/+32
| | | | | | | | | | | | | | | | This is needed so that we know the flash module is locked up. Signed-off-by: Vic Yang <victoryang@chromium.org> BUG=chrome-os-partner:13219 TEST=Check PROTECT_ALL_NOW is still set after sysjump. BRANCH=snow Change-Id: I632d671058a49d30addb50744ed791f6b43609f5 Reviewed-on: https://gerrit.chromium.org/gerrit/31544 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Commit-Ready: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org>
* Support battery cut-off mechanism for factory.Louis Yung-Chieh Lo2012-08-285-0/+77
| | | | | | | | | | | | | | | | | | | The cut-off command is manufacturer-specific. Thus the logic is implemented in gas gauge IC code. For those boards using this gas gauge, define the CONFIG_BATTERY_BQ20Z453 in board.h. BUG=chrome-os-partner:12962, BRANCH=snow Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> TEST=Tested on snow ectool batterycutoff ; expect system is off immediately ; if AC power is not connected. Change-Id: Idd290c76439f3263c1c812b236b79623878f73b2 Reviewed-on: https://gerrit.chromium.org/gerrit/31466 Reviewed-by: Rong Chang <rongchang@chromium.org> Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org> Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
* snow: Change TPSCHROME fastcharge timeout to 6 hoursRong Chang2012-08-283-11/+92
| | | | | | | | | | | | | | | | | | When battery temperature t in range 0C to 10C, default charging current is 50%. And it will take longer than 3 hours to charge battery from 0% to full. Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:13172 TEST=manual Check pmu register 0x4. FASTCHARGE bits[4:2] should be 0b100. Change-Id: I133acee21c0886b0739b4b41766ca077bb4babbc Reviewed-on: https://gerrit.chromium.org/gerrit/31458 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Commit-Ready: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* Ignore TPSCHROME NTC reading in T40 rangeRong Chang2012-08-281-0/+10
| | | | | | | | | | | | | | | | | | | | | | | TPSCHROME NTC readings didn't match battery gas gauge temperature. The charging was turned off by TPSCHROME too early, and was resumed too late. This change disables TPSCHROME thermal protection in T40 by set charging voltage and current to 100%. Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:12221 BUG=chrome-os-partner:13171 TEST=manual Check pmu register settings. VSET/ISET are equal in T23,T34,T40 ranges. Change-Id: Ic60cc2bf606ed02496aad80b02360a19efafd3c0 Reviewed-on: https://gerrit.chromium.org/gerrit/31457 Commit-Ready: Rong Chang <rongchang@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* Disable SPI module on linkRandall Spangler2012-08-271-1/+0
| | | | | | | | | | | | | EC won't be accessing BIOS SPI, so no need to compile in this code. BUG=chrome-os-partner:11232 TEST='spi' command on EC console should no longer be valid BRANCH=link Change-Id: I09d5e99dbe1fd63cb7839454030067d29249a9ed Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31516 Reviewed-by: Vic Yang <victoryang@chromium.org>
* stm32f: Fix a bug that PROTECT_ALL_NOW is set incorrectlyVic Yang2012-08-271-1/+1
| | | | | | | | | | | | | | Signed-off-by: Vic Yang <victoryang@chromium.org> BUG=chrome-os-partner:13210 TEST=Check software sync works with WP enabled. BRANCH=snow Change-Id: I4d71924dfbe3b3731d4bd2dcdd1a62d6d474eb38 Reviewed-on: https://gerrit.chromium.org/gerrit/31514 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org>
* i2c: Enable arbitration GPIOs only when activeSimon Glass2012-08-272-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
* Make AC status feature optional at compile timeSimon Glass2012-08-274-3/+24
| | | | | | | | | | | | | | | | 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>
* Add CONFIG_CONFIGURE_BOARD_LATE for late board initSimon Glass2012-08-272-0/+8
| | | | | | | | | | | | | | | | It is useful to be able to perform some board init after GPIOs are set up. When defined, configure_board_late() will be called after GPIOs are ready. BUG=chrome-os-partner:13064 BRANCH=snow,link TEST=manual build and boot on snow with later changes. See the AC power GPIO does not change when un/plugging power. Change-Id: Idc56c0acde9f7bd46b4379731b973d1fce760b3f Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31303
* Allow GPIOs to be set up laterSimon Glass2012-08-274-1/+7
| | | | | | | | | | | | | | | | | | | | At present GPIOs must be staticly defined in a table. This is efficient but inflexible, and requires error-prone and correponding #ifdefs both in the board's gpio.h and gpio.c files. Create a GPIO_UNSET option for GPIOs. This allows them to be assigned an enum value, but have the actual use under program control. BUG=chrome-os-partner:13064 BRANCH=snow,link TEST=manual build and boot on snow with later changes. See the AC power GPIO does not change when un/plugging power. Change-Id: Iab58275923d7d6cfce62c890b5db9b6758279a4c Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31302 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Reset pmic registers to known safe values on bootCharlie Mooney2012-08-273-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | If a bug causes the pmic's internal registers to be overwritten with garbage, they won't go away and can cause long lasting problems. This change overwrites them all whenever the EC or AP turn on with known, safe values, so if that happens, a reboot will restore them instead of forcing the user to pull the battery. It also overwrites a few of them when the AP shuts down, to prevent AP bugs from leaving the pmu powering a bunch of peripherals that it doesn't need after it has turned off. BUG=chrome-os-partner:12913 TEST=from EC console run "i2c w 0x90 0x0c 0xff" to screw up one of the pmic registers. Reboot the EC, and the AP should be able to boot just fine. Once the AP is booted, run that command again. This time, just reboot the AP, it should come back on like normal. Try again with "i2c w 0x90 0x0c 0x00". Without the change, this fails to work. BRANCH=snow Change-Id: If3f0764f23e0112cc11be60b413f51e1b66e54a7 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31259 Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Puneet Kumar <puneetster@chromium.org>
* Rename EC_FLASH_PROTECT_RW_* flags to EC_FLASH_PROTECT_ALL_*.Louis Yung-Chieh Lo2012-08-256-35/+39
| | | | | | | | | | | | | | | | | | | | Current *_RW_NOW/RW_AT_BOOT is used to lock the entire flash. This could lead confusion in the future. So, rename them. Since the bit definition is unchanged, thus the callers (u-boot, flashrom) is fine if they don't change the name. BUG=chrome-os-partner:12951 BRANCH=snow,link TEST=build in chroot only:daisy,snow,link,bds Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Change-Id: I2395e93793f590e6fb8aae7006eb8e5c836002bc Reviewed-on: https://gerrit.chromium.org/gerrit/31199 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-by: Randall Spangler <rspangler@chromium.org>
* stm32: simplify hard resetVincent Palatin2012-08-241-102/+23
| | | | | | | | | | | | | | | | | | | use the watchdog instead of the hibernation mode and RTC wake-up to accomplish the hard reset. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=chrome-os-partner:13126 TEST=on Snow, in U-Boot console, type "mbkp reboot cold" and see the AP rebooting properly. BRANCH=snow Change-Id: Ic8b83f033e9dd4ccf1dff664226bf0ae6b9c47e5 Reviewed-on: https://gerrit.chromium.org/gerrit/31373 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Fix return size error in lightbar host commands.Bill Richardson2012-08-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | The response size was wrong. It should be right. BUG=none BRANCH=link TEST=none Build the lbplay tool, copy it to the DUT. cd src/platform/ec make BOARD=link scp build/link/util/lbplay root@LINKIPADDR:/tmp/ Run /tmp/lbplay on DUT. It used to print a warning message. Now it doesn't. The lightbar will glow green, then red (that's what lbplay does). Change-Id: Iee02a026f08b6f761e5f28f20b79bcb9f4704a43 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31403 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: fix AP auto power onVincent Palatin2012-08-241-3/+3
| | | | | | | | | | | | | | | | | | | | | The logic introduced by CL 28139 was incorrect (ie it just sets to 0 the auto_power_on variable which is already 0) For software sync, we always want to power the AP. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=chrome-os-partner:13126 TEST=on Snow, cold reset the EC and see the AP firmware booting. in U-Boot console, type "mbkp reboot cold" and see the AP rebooting instead of shutting down. BRANCH=snow Change-Id: Ib88f75a8b159015df708c041cdc14153fe8736a9 Reviewed-on: https://gerrit.chromium.org/gerrit/31370 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* gpio: Fix initting pulldownsDoug Anderson2012-08-242-4/+6
| | | | | | | | | | | | | | | | | | | | | At the moment we don't seem to have any pull downs configured, but they wouldn't work. That's because: * GPIO_PULL_UP => 0x0006 * GPIO_PULL_DOWN => 0x0002 ...so if we've got GPIO_PULL_DOWN in flags and then we run the test "if (flags & GPIO_PULL_UP)", we'll actually test TRUE. Oops. BUG=None TEST=Code inspection. BRANCH=snow Change-Id: Ie46ae291fe7edfc9f5237cf8bba3791de9755c5b Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31278 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Fix poweron state machine in the ECPuneet Kumar2012-08-242-53/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing state machine does the following: - when power button is pressed it 1. powers on the AP 2. sets a timer of 1 sec and then 3. waits for power button to be released When the timer fires it checks xpshold is set by the AP and if so it clears the pwron signal (which is used by the AP to detect power button is pressed). The problem occurs when the user holds the power button for more than a second. The AP turns on xpshold, then notices that pwron is still on and subsequently powers down because it thinks the power button is pressed. When the button is finally released, since it was held down for more than a second, the timer routine notices that xpshold is not on and therefore shuts down the system. Another problem found while analysing this state machine is that loop checking for poweroff only triggers on the rising edge of xpshold. This means that if the AP powers down the EC might miss a possible power event. Here is the proposed fix: When the power button is pressed the EC will: 1. power on the AP 2. Check for xpshold to be asserted with a 1 sec timeout 3. If uboot is healthy xpshold should come on pretty quickly; the EC then waits for the power button to be released in less than 8 seconds 4. If the power button is released then the EC waits for power off events. 5. If the power button is not released it waits for upto 8 seconds before turning off the AP. The added wrinkle is how to address a borked uboot case. In the case where xpshold doesn't come on in < 1 second, the EC will allow the AP to stay on for upto 16 seconds so that USB boot can finish. The user must hold the power button down until uboot boots and sets xpshold. The assumption here is that USB boot takes < 16 seconds. BUG=chrome-os-partner:12748 TEST="follow instructions in bug report" Change-Id: I5b582a6c3ae3449238e2813e4a581bd8f92dd846 Signed-off-by: Puneet Kumar <puneetster@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31291 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Allow hashing an empty RW imageRandall Spangler2012-08-241-16/+10
| | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:13084 TEST=manual flash_erase 0x14000 0x14000 reboot hash Offset: 0x00014000 Size: 0x00000000 (0) Digest: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 BRANCH=link,snow Change-Id: I3152c201edac5ef6ad8e28c4e55cd6245b61e786 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31277 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Snow: Increase timeout for i2c stop bit sendingCharlie Mooney2012-08-231-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On snow, there are reports of the following warning in the i2c master reciever code: Stop event deadline passed: CR1=0000001000000001 I've been running this torture test, and even with the timeout feature completely removed, it never hangs. The stop bit is always sent eventually, even through thousands and thousands of transactions (of which a couple take too long for the current timeout). I timed a lot of these and it looks like the vast majority are fine but just a few are really really slow. To this end, I'm increasing the timeout. It seems that the wait loop is getting preempted for a while before it can go back and check, causing these timeout messages. So every now and then the process get pre-empted for a long time causing what looks like a long timeout. The thing is, the stop bit is always getting sent, we're just not noticing for a while. So even in the really slow cases, everything should be fine. Since the bit's getting sent either way, it seems like increasing the timeout all but fixes the problem where the EC thinks it didn't send. However, since the timeout is quite high now, I added a sleep in the busy loop so that if a message is messed up and the stop bit doesn't send, the task won't steal the cpu for the entire time. Note: This also fixes a bug in the i2c error handler where it was trying to print ints and strings and ads a little more information to the timeout warning in case it starts showing up again. BUG=chrome-os-partner:12742 TEST=From the EC console run "battery 100000" while running "while true; do /usr/local/sbin/i2cdump -f -y 4 0x48; done" to seriously stress test the i2c bus. Then reboot the machine several times. There should be no Stop bit warnings, or failed i2c transfers BRANCH=snow Change-Id: I590a9458783d16e57987102b1ec1299d5ddb0fa2 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31024 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* flash: Only erase flash block that contain dataSimon Glass2012-08-235-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>
* stm32: fix missed event on MSB hardware timerVincent Palatin2012-08-231-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | When we set the TIM3 hardware timer match interrupt (used for 16-bit MSB of the 32-bit microsecond counter), as the STM32 hardware block is not triggering an interrupt on an exact match (only on the transition from N-1 to match value N), we need to check whether the counter has been incremented to the match value before we set the interrupt enable bit. In that case, we simply fallback to the existing code to set the LSB match interrupt. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=chrome-os-partner:12715 TEST=use Snow board and see we are no longer getting EC watchdog in the idle task. BRANCH=snow Change-Id: I4ceeb46425c799e328603ae0e99b678547d88fbe Reviewed-on: https://gerrit.chromium.org/gerrit/31228 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* Blink charger LED on charging errorRong Chang2012-08-233-7/+161
| | | | | | | | | | | | | | | | | | | | Charger LED is controlled by TPSCHROME chip. And it blinks only when hardware detected charging error. On other charging error conditions not detected by TPSCHROME, we set the temperature thresholds to make charger generate the error blink. Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:12224 TEST=manual Plug AC power, heat up battery to 65 C. The charging LED should start blinking instead of green. Change-Id: Ib1c38a88c026471a52fbbb4f803e3b2aba93ab40 Reviewed-on: https://gerrit.chromium.org/gerrit/31139 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org> Commit-Ready: Rong Chang <rongchang@chromium.org>
* Snow: Fixing invalid i2c error codesCharlie Mooney2012-08-231-2/+2
| | | | | | | | | | | | | | | | | | The i2c driver was returning the result from task_wait_event() as an error code when it failed. However, this function returns an event mask, not a valid error code. It has been replaced to return EC_ERROR_TIMEOUT instead when the even times out. BUG=chrome-os-partner:13057 TEST=Booting the machine, and normal use works fine. Running i2c stress tests also work without error. No functional changes were made, only the error codes for debugging. BRANCH=snow Change-Id: I3e48f97c08c82fd50b811e8289f3bd378ecb3171 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31214 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Snow: i2c arbitration cleanup (suspend)Charlie Mooney2012-08-231-9/+5
| | | | | | | | | | | | | | | | | | | | | | | The ec used to have to check the state of the AP since it would leave the arbitration lines when it suspended. That meant you couldn't trust the arbitration lines without checking the power state. Now the AP pulls the arbitration lines high when it suspends, so it no longer needs to test this when trying to acquire master. BUG=chrome-os-partner:12460 TEST=First, on the EC console run "battery" and "pmu" to make sure they work. Then repeat those steps after putting the AP in suspend by running powerd_suspend, they should still work. Then shutdown the machine entirely and try them again. Note: pmu needs the AP to be on to work, so if it fails here that's okay, just make sure it's not an arbitration error. BRANCH=snow Change-Id: I335156bbce4888949111f74e8a83fe9d184a7a63 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/30906 Reviewed-by: Jon Kliegman <kliegs@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* Check TPSCHROME VACG when power button is pressedRong Chang2012-08-221-5/+20
| | | | | | | | | | | | | | | | | | | | | | | The AC status GPIO also indicates power button. When power button is pressed, EC should return VACG in pmu_get_ac() funtion. If this function is called in interrupt context with power button pressed, return 1. Charging task will play nicely in charging mode without real AC. But in discharging mode, it will shutdown application processor if battery remaining capacity is too low. Signed-off-by: Rong Chang <rongchang@chromium.org> BRANCH=snow BUG=chrome-os-partner:12738 TEST=manual With AC plugged, press and hold power button. Run uart console command "pmu" and check output, "ac gpio" should be 1. Change-Id: I26d1a5a7a4ed2ff26a35e965a3ca2307a9c231e9 Reviewed-on: https://gerrit.chromium.org/gerrit/31112 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Ready: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* Minimum write size for Snow is 2 bytes, not 64 bytes.Bill Richardson2012-08-221-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>
* gaia: Assert PMIC_PWRON_L only if XPSHOLD is lowDavid Hendricks2012-08-221-2/+7
| | | | | | | | | | | | | | | | | | | This is intended to prevent accidental AP reboot when soft rebooting the EC, e.g. via sysjump during firmware updates. For our platforms, the PMIC_PWRON_L causes the AP to see a keyboard power button press. Signed-off-by: David Hendricks <dhendrix@chromium.org> BRANCH=snow BUG=chrome-os-partner:12650 TEST=sysjump via "ectool reboot_ec RW" or firmware update no longer causes AP to reboot, Change-Id: Ife227285499d5cd52d6a0cb0ebe5df2f51d706d4 Reviewed-on: https://gerrit.chromium.org/gerrit/30291 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>
* snow: configure USART Rx as an input with pull resistorDavid Hendricks2012-08-212-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>
* Add "lightbar demo" mode for executive bikesheddingBill Richardson2012-08-207-29/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I keep getting asked to build an EC image to manually control the lightbar patterns so that the Powers That Be can look at it. This change just makes it possible to turn that mode on and off for yourself. You'll need a root shell or the EC console to do it, though. BUG=chrome-os-partner:8039 BRANCH=link TEST=manual From the EC console, type lightbar demo 1 OR from the root shell run ectool lightbar demo 1 After that, these keys should change the lightbar appearance (transitions may be slow and subtle - that's intended): UP = battery is more fully charged DOWN = battery is less fully charged RIGHT = battery is charging LEFT = battery is discharging BRIGHT = increase lightbar brightness DIM = decrase lightbar brightness Note that this does not interfere with the normal function of any keys. It only adds some additional EC behavior. Change-Id: Ia1a9855188244d74b670f9dbfdf60e3ac0343460 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/30899
View Lorry Controller Status