summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Clear OWNERS for factory/firmware branchfactory-whirlwind-6812.41.BBrian Norris2021-09-102-10/+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/+/3155125 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* pd: Bugfix for write log entry command.stabilize-js-6812.26.Bstabilize-js-6812.25.Bstabilize-js-6812.21.Bstabilize-6812.85.Bstabilize-6812.83.Bstabilize-6812.75.Bstabilize-6812.41.Bstabilize-6812.34.Bstabilize-6812.29.Bstabilize-6812.15.Bstabilize-6812.14.Bstabilize-6812.13.Brelease-R42-6812.BTodd Broch2015-03-031-1/+1
| | | | | | | | | | | | | | | | BRANCH=samus BUG=chrome-os-partner:37264 TEST=manual, ectool --name cros_pd pdsetmode 0 0xff01 1 0 successfully exits displayPort mode again. Change-Id: Ica2faf8de92460f01c2af9be829795c0cd538135 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/254990 Reviewed-by: Shawn N <shawnn@chromium.org> (cherry picked from commit 5e9eb3263d4f47f006f7b8e4eeaadd229a8df611) Reviewed-on: https://chromium-review.googlesource.com/255130
* samus_pd: remove resetting pericom 30 sec after detecting SDPAlec Berg2015-02-211-20/+3
| | | | | | | | | | | | | | | | | | Remove resetting pericom 30 seconds after detecting SDP. This is not helpful anymore since we have fixed pericom detection problems and have a charge ramp for SDPs. BUG=chrome-os-partner:36813 BRANCH=samus TEST=connect samus A port to samus C port. this detects as SDP and ramps to 1A, but every 30 seconds resets the pericom. with this change it detects SDP, ramps to 1A and stays constant. Change-Id: I2400a06d237cef8c03f921960954dcf54d93de1e Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251583 Reviewed-by: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org>
* common: Add the possibility to filter UART inputMyles Watson2015-02-213-0/+24
| | | | | | | | | | | | | | | | | | | Add CONFIG_UART_INPUT_FILTER, which is undefined by default. BUG=chrome-os-partner:36745 TEST=buildall for the case where it is not defined. Added a filter function to the btle code on hadoken. Tested reset, transmit test, receive test, test end, and test mode end. BRANCH=None Signed-off-by: Myles Watson <mylesgw@chromium.org> Change-Id: I3a9c067ffcb114449b61f468271a48491a8c7ec5 Reviewed-on: https://chromium-review.googlesource.com/250580 Tested-by: Myles Watson <mylesgw@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Myles Watson <mylesgw@chromium.org>
* timer: usleep: Use HW clock to detect elapsed sleep timeAlec Berg2015-02-211-1/+9
| | | | | | | | | | | | | | | | | | | If a non-timer task event is received while in usleep, we will again attempt to sleep for the entire duration. This can cause an infinite sleep in cases where a periodic task event occurs. Fix this by checking the HW clock for our elapsed duration. BUG=chrome-os-partner:36864 TEST=Manual on Samus. Verify that we don't get stuck in usleep during VCORE_PGOOD interrupt storm. BRANCH=Samus Change-Id: Ie3ab8ce3c22822095845a3d9a6f33bd4b1273c6e Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251311 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: Only enable VCORE_PGOOD interrupt when it is validDuncan Laurie2015-02-201-0/+15
| | | | | | | | | | | | | | | | The VCORE_PGOOD signal to the EC goes through a buffer which is powered by PP1050_VCCST that itself is gated by SLP_S3. Until this point the input is invalid and may be oscillating so only enable it as an interrupt once we are in S3->S0 state. BUG=chrome-os-partner:36864 BRANCH=samus TEST=boot on samus to ensure power sequencing still works properly Change-Id: I90ad3b578297a5194c110407be1cba2d65226290 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251324 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* charge_state_v2: Do not draw max input current if battery is presentVic Yang2015-02-201-12/+11
| | | | | | | | | | | | | | | | | | | | | Currently we set the input current limit to its maximum when the system is unlocked, so that we can boot the system with a powerful charger when the battery is absent. However, with a low power charger, we risk browning out the charger. If the battery is present, reduce the input current limit so that low power chargers work in this case. BRANCH=None BUG=None TEST=On Ryu, reboot EC when the a low power charger is used. Without this change, the charger browns out right after the reboot. With this fix, the problem doesn't happen anymore. Change-Id: I9d491cbe45e77f864198c97a47624918e6c272db Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/248442 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org>
* samus: samus_pd: Increase task stack sizesShawn Nematbakhsh2015-02-202-7/+5
| | | | | | | | | | | | | | | Since we have RAM to spare, increase the stack sizes of certain tasks that may come close to stack overflow. BUG=chrome-os-partner:36914 TEST=Manual on samus / samus_pd. Run task_info, verify new task stack sizes. BRANCH=Samus Change-Id: Id667f963bffbf7776e7cbe07b7e7d34f4ac27398 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251420 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* EC: Support firmware updater to auto select a battery fw imageSheng-Liang Song2015-02-202-144/+221
| | | | | | | | | | | | | | | | Auto select a battery firmware image based on the current "battery info." sprintf(auto_image_name,"/lib/firmware/battery/maker.%04X.hwid.%04X.bin" maker_id, hardware_id); BUG=chrome-os-partner:24741 BRANCH=glimmer TEST=Verified Simplo Battery Update on glimmer Change-Id: Ie6b2f797a4629fdde3a45e9a6a83c4568655db7a Signed-off-by: Sheng-Liang Song <ssl@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250130 Reviewed-by: Shawn N <shawnn@chromium.org>
* samus: add i2c retries to backlight controlAlec Berg2015-02-201-15/+69
| | | | | | | | | | | | | | | | | | Add i2c retries to backlight control. Also check return value, if i2c transfer fails, do not continue. Also modified backlight control so that we only send I2C commands when backlight chip is enabled (in S0 and lid is open). BUG=chrome-os-partner:36803 BRANCH=samus TEST=test suspend/resume and booting and make sure panel always comes up. Change-Id: I0dd71c12d0c3f64a08fb389c37f64b1b0ac16fb8 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250670 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* cr50: Separate ARM core GPIOs from pinmux configurationBill Richardson2015-02-208-179/+276
| | | | | | | | | | | | | | | | | | | | This separates the configuration of the ARM core GPIOs from the routing of internal peripherals to external pins. Both are still described in the gpio.inc file, but are less dependent on each other. BUG=chrome-os-partner:33818 BRANCH=none TEST=manual Before this CL, running "sysjump rw" or trying to use more than 8 GPIOs caused hangs and reboots. Now it doesn't. Change-Id: If962a7c5ad4136837b2ea00ae016a440f07d7e23 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251015 Reviewed-by: Sheng-liang Song <ssl@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: Add ec.hex to hex: build targetBill Richardson2015-02-201-1/+5
| | | | | | | | | | | | | | | When the default build target creates .hex files, emit the complete ec.hex output as well as the RO and RW halves. BUG=none BRANCH=none TEST=make BOARD=cr50 Change-Id: Ia87bbace29d89695ef6a9c090c895ca10f14d919 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251014 Reviewed-by: Sheng-liang Song <ssl@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: bitmasks should be unsigned valuesBill Richardson2015-02-201-1/+1
| | | | | | | | | | | | | | | Change the struct gpio_info to use uint32_t for the mask field, instead of signed integer. BUG=none BRANCH=none TEST=make buildall Change-Id: I8cc7e3d06a00bd3c890522a896e36e1eb18a862e Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251013 Reviewed-by: Sheng-liang Song <ssl@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Don't admit the existence of unimplemented gpiosBill Richardson2015-02-201-1/+1
| | | | | | | | | | | | | | | | | | | For boards with unimplemented GPIOs, don't display those GPIOs in the output of "gpioget" or accept them as signal names in "gpioset". BUG=none BRANCH=none TEST=manual Pick a board with an unimplemented GPIO (search board/*/gpio.inc for UNIMPLEMENTED), run "gpioget" and "gpioset". It shouldn't show up. Change-Id: I343ece7d6df5fa09fda8418e3f3148d74f1540ae Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251012 Reviewed-by: Sheng-liang Song <ssl@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Poke the watchdog when dumping lots of memoryBill Richardson2015-02-201-0/+9
| | | | | | | | | | | | | | | | | | | If you use the "md" command to display lots of memory, it can cause the watchdog to trip. This just pokes it every now and then to be sure it's happy. BUG=none BRANCH=none TEST=manual Print a lot, see that it doesn't timeout: md 0 0x4000 Change-Id: Ic4e2746c07f4fbdf922e87ea3efbe90b88ae08c9 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251011 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* panic: fix logging of watchdog in panic dataAlec Berg2015-02-202-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix bug with the new CONFIG_SOFTWARE_PANIC where a watchdog panic will write panic data after jump_data pointer is calculated. Since jump data uses the same RAM location as panic data (the end of RAM), we rely on panic data being written BEFORE jump data pointer is calculated so that we don't use the same RAM space. BUG=chrome-os-partner:36871 BRANCH=samus TEST=without this CL, can reproduce problem where jump data is corrupted using samus with following steps: 1) hibernate 1 (this will clear panicinfo) 2) waitms 3000 (this will cause a watchdog reset) 3) let system boot to S0 4) sysjump rw On sysjump to RW, the jump data will be corrupt because while we were in RO panic data was added where there wasn't any before. This means the jump_data pointer in RW will differ from the jump_data pointer that was used in RO and we will fail to find the magic jump data. Most visible consequence of this is that the USB ports will be disabled after these steps because we use jump data to store last state of USB port enables. With this CL, following the steps above, the USB ports are restored to the pre-sysjump state, which is enabled. Change-Id: Ia129419db7400eddb54bcf57b4d4aed63d5c52ef Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/251110 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* hwtimer/hwtimer32: Remove task_resched_if_needed from watchdog helpAlexandru M Stan2015-02-182-8/+4
| | | | | | | | | | | | | | | | | | | | | Remove task_resched_if_needed, since we don't do any task scheduling modifications. Just return instead. This makes it work on F0 as well, where we don't have task_resched_if_needed BUG=None TEST=With series, see watchdog help work on any veyron BRANCH=veyron Change-Id: I93cce722b6d53008b015c7cdd56b7e77dc07bbff Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/242713 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 8363dfb14cb36fca412132ab14d2c9451de7d94e) Reviewed-on: https://chromium-review.googlesource.com/250671 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org>
* samus: initiailze boostin_voltage in extpower moduleAlec Berg2015-02-181-1/+1
| | | | | | | | | | | | | | | Fix complile bug, initialize local var boostin_voltage. BUG=none BRANCH=samus TEST=make -j buildall Change-Id: Ie178d3bfe164fc900b1c52a05412f75d5a090ddd Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250820 (cherry picked from commit 54f01a6c030ed7608a4bf0d673740a0dca24a52f) Reviewed-on: https://chromium-review.googlesource.com/250821 Reviewed-by: Shawn N <shawnn@chromium.org>
* cortex-m0: Fix panic reason on div0Shawn Nematbakhsh2015-02-181-1/+1
| | | | | | | | | | | | | | The wrong constant was used in the previous commit. BUG=chrome-os-partner:36744 TEST=None BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I74e365b00adb6909a4940229647f9aecebe5e0b1 Reviewed-on: https://chromium-review.googlesource.com/250700 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: panic reboot EC if PD MCU crashesAlec Berg2015-02-186-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | Use the EC to check if PD MCU has crashed. The EC knows this by checking the PD status bits: if PD MCU was in RW, and is now in RO, AND it did not get to RO via a sysjump, then it must have crashed. When the EC detects this, the EC will also panic and reboot the entire system, so that we can software sync to a known good state. Also, when EC panics due to PD crash, it will log panic info. BUG=chrome-os-partner:36636 BRANCH=samus TEST=load onto samus EC and PD, try sysjump'ing back and forth on PD MCU console and verify EC does not do anything. Crash the PD MCU when in RW by reboot command and crash divzero command, and make sure the EC panics with PD crash panic message. Crash the PD MCU when in RO (before sysjumping to RW) and make sure EC does not panic. Change-Id: I57961028e6b23a878b8e477a9d8e180cb121a742 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250100 Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* cortex-m*: Save panicinfo on non-exception panicsShawn Nematbakhsh2015-02-1813-77/+163
| | | | | | | | | | | | | | | | | | Make non-exception "software" panics such as stack overflow and assert failure save a panic log. Log the panic type in r4, and misc. panic data in r5 so that panic reasons can be distinguished. BUG=chrome-os-partner:36744 TEST=Manual on samus_pd. Run 'crash divzero' then 'panicinfo' after reboot. Verify that panic info is printed with "r4 :dead6660". Trigger stack overflow, verify that panic info is printed with "r4 :dead6661". BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I5f7a8eb0a5c2ac5799d29bb241deb24fabf38f68 Reviewed-on: https://chromium-review.googlesource.com/249912 Tested-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: add charge ramp moduleAlec Berg2015-02-183-0/+104
| | | | | | | | | | | | | | | | | | | | | Add charge ramp module to samus. For BC1.2 DCPs allow ramping up to 2A, and for BC1.2 SDPs allow ramping to 1A. Charge ramp is disabled when in RO and write protected. BUG=chrome-os-partner:34946 BRANCH=samus TEST=tested with a variety of BC1.2 chargers, type-C only chargers, and PD chargers to make sure we always stabilize charging at an appropriate current limit. tested in RO and write protected, BC1.2 chargers do not ramp. when you jump to RW it does ramp. Change-Id: I7c36c8fb0a34139c69a475307c325f891099b3dd Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/249933 Reviewed-by: Shawn N <shawnn@chromium.org>
* charge_manager: Assume all chargers are dedicated when in locked ROShawn Nematbakhsh2015-02-181-0/+9
| | | | | | | | | | | | | | | | In locked RO, the PD state machine is crippled and unable to determine whether a charger is dual-role capable. In order to charge in locked RO, assume that all chargers are dedicated. BUG=None TEST=Manual on samus_pd. Lock system and reboot to RO. Insert Zinger and verify that system charges 3A @ 5V. BRANCH=Samus Change-Id: I88a3ff248914cd95ebce8e9b91de1001c0f78b55 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250650 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: Only update fan speeds every N secondsBill Richardson2015-02-183-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | This adds CONFIG_FAN_UPDATE_PERIOD to limit the frequency at which the fan speeds are updated. Short version: the CPU core temp fluctuates rapidly, causing the fans turn off and on annoyingly often (assuming you have good hearing and are in a quiet room). With this CL, we limit the speed changes to only once every N seconds. N should be long enough to be less annoying, yet short enough that the CPU doesn't overheat while we're not looking. BUG=chrome-os-partner:34789 BRANCH=ToT,samus TEST=manual Let it sit quietly, then visit a busy webpage, then let it sit a while. The fan speed should only change every 10 seconds or so, not every second. Change-Id: Id985350394f24d56dc4a1e51af09487ac643285b Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250501 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* charge_ramp: initial commit of charge ramp moduleAlec Berg2015-02-189-4/+972
| | | | | | | | | | | | | | | | | | | Add new charge_ramp module which works with charge_manager to slowly increase input current limit in order to find the optimal charging current. To do this it looks for either VBUS drooping too low or for the charger to over-current. BUG=chrome-os-partner:34946 BRANCH=samus TEST=tested with a variety of BC1.2 chargers, type-C only chargers, and PD chargers to make sure we always stabilize charging at an appropriate current limit. Change-Id: Icc95aa2738ddb221f163f91c14a342a0674f9e0f Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/247304 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* pd: charge_manager: make new VBUS charge supplierAlec Berg2015-02-185-64/+109
| | | | | | | | | | | | | | | | | | | | | | Make new VBUS charge supplier for Samus and Ryu which allows default 500mA charging when VBUS is present. Before this was accomplished via the type-C supplier, but type-C supplier should only be used for 1.5A and 3A pull-up. VBUS supplier is lowest priority so that any other supplier will take precedence over the default charging rate. This work is done in preparation for charge_ramp module where we don't want to ramp for typeC supplier. BUG=chrome-os-partner:34946 BRANCH=samus TEST=make sure we can boot without battery on samus, and test other chargers including legacy chargers, zinger, and donette. Change-Id: I89f1e9520e4bf9e5debbaf8dd2de1262154eecf8 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250312 Reviewed-by: Shawn N <shawnn@chromium.org>
* samus: avoid attempting unwedge charge circuit if VBUS is at 5VAlec Berg2015-02-181-9/+20
| | | | | | | | | | | | | | | | | | | | Change unwedge code to not attempt unwedging circuit if VBUS is at 5V because the circuit can't wedge itself at 5V. If BQ PROCHOT is high, we should just read it to clear it, and move on. BUG=chrome-os-partner:36081 BRANCH=samus TEST=test with ramp code. make sure ramp never gets stuck at minimum value because we are in the middle of unwedging the circuit when ramp starts. also test that manually wedging charge circuit with zinger using "charger voltage 7000" is still recovered from. Change-Id: I209bf324eab39bdca1948b7764870a909ea480c8 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250463 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* samus: disable i2cscan console command to save spaceAlec Berg2015-02-183-4/+8
| | | | | | | | | | | | | | Disable the i2cscan console command by default to save space BUG=none BRANCH=samus TEST=make -j buildall From .map file, 512 bytes of flash saved Change-Id: I4bcb50b00e843abbc3523a3e0d4cc599a1e01d3a Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/249850 Reviewed-by: Vic Yang <victoryang@chromium.org>
* make idlestats console command optionalVincent Palatin2015-02-183-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | To save flash space, disable "idlestats" console command on samus_pd. This saves 384 B of flash Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=chrome-os-partner:34489 TEST=make buildall and check firmware size. === build/samus_pd/ BASELINE === FLASH 57.8k / 60.0k [ text 48.0k rodat 9.7k data 0.1k ] RAM 11.8k / 16.0k [ data 0.1k bss 11.7k ] === #undef CONFIG_CMD_IDLE_STATS === FLASH 57.4k / 60.0k [ text 47.9k rodat 9.4k data 0.1k ] RAM 11.8k / 16.0k [ data 0.1k bss 11.7k ] Change-Id: Iba9654a88ec195026945881bc2687a1e67747706 Reviewed-on: https://chromium-review.googlesource.com/241452 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org>
* samus: avoid waking extpower task until task has been initializedAlec Berg2015-02-171-2/+8
| | | | | | | | | | | | | | | | | | | | | | | Fix booting without battery by avoiding waking the extpower task until it has run extpower_board_hacks() the first time. The problem was if there was no battery and AC was attached, extpower_board_hacks() would run twice on boot, once in extpower task initialization, before the while(1) loop, and a second time due to the AC_PRESENT interrupt. This would cause extpower_board_hacks() to think that AC had transitioned from 1 to 1, which represents a glitch on ACOK, so it would disable charging, thus causing us to lose power. BUG=chrome-os-partner:35570 BRANCH=samus TEST=load on a samus and boot with and without battery Change-Id: Idf6d0022f7dbedbb66a2fbe1c2b7dd885eabc43b Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250301 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* flash_ec: Add --no-ns-pid check and freeze instead of kill PTY clientsJulius Werner2015-02-171-20/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | The switch to PID namespaces inside the chroot broke flash_ec's ability to detect (and then kill) other processes that use the EC serial PTY (leading to potential flashing failures). After a long discussion we decided that users who need features like this should be forced to run their chroot without PID namespacing (using cros_sdk --no-ns-pid). This patch adds a hard check for this to flash_ec, so that using it in an unsafe way becomes impossible. In addition, this ports the more advanced SIGSTOP/SIGCONT logic to flash_ec that was pioneered in fwgdb. With this, other processes accessing that PTY will just freeze and become available again after flash_ec finished. BRANCH=none BUG=chromium:444931 TEST=Ran on a Jerry with and without --no-ns-pid, with and without an open EC terminal, all results as expected. Change-Id: I45ffc3ec6cfe9c25a0b82b4d5288a41485c326c4 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/249835 Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* USB: fix memcpy_to_usbramAnton Staaf2015-02-171-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | A change to the toolchain or environment surfaced an issue where the writes to packet RAM were being split into two 16-bit writes. This was interacting poorly with the AHB2APB bridge. Marking the packet RAM destination pointer volatile forces the compiler to use full 32-bit writes. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Check that Ryu's console is accessible over USB Change-Id: I0c3db08c704389a627570b90ef97bce81ab553fa Reviewed-on: https://chromium-review.googlesource.com/248840 Trybot-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* stm32f0: Change idle task warning printf to save stack spaceAlec Berg2015-02-161-1/+2
| | | | | | | | | | | | | | | | | | Change the idle task overslept warning printf to save stack space. The current warning uses CPRINTF which adds too much to the stack and overflows the idle stack. BUG=chrome-os-partner:33138, chrome-os-partner:36636 BRANCH=samus TEST=comment out the if (margin_us < 0) check and always print warning message. Without this CL stack overflows. With this CL, stack does not overflow and gets to 168/256, which is plenty of headroom considering the task doesn't do much. Change-Id: I19a8336b8584d2a1342e7b9290aad471d326a060 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/250300 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* samus: increase extpower task stack sizeAlec Berg2015-02-141-1/+1
| | | | | | | | | | | | | | | Increase extpower task stack size due to occasional stack overflow in extpower task on plugging/unpluggin AC. BUG=chrome-os-partner:36760 BRANCH=samus TEST=load onto samus, connect/disconnect a bunch of times and check high water mark on stack usage: 368/512 Change-Id: I4531176ce6f15356a2267cdecf907a7694567da9 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/249920 Reviewed-by: Shawn N <shawnn@chromium.org>
* pd_log: Add command to request PD MCU to write a logShawn Nematbakhsh2015-02-126-2/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we find that charging is in a wedged state, we may wish to write a PD log entry, but the PD MCU cannot detect such a state on its own. Therefore, add a new command to ask the PD MCU to write a log of a given type, and add a new board-specific custom log event. BUG=chrome-os-partner:36668 TEST=Manual on samus: ./ectool --dev=1 pdwritelog charge 0 ./ectool --dev=1 pdwritelog charge 1 ./ectool --dev=1 pdwritelog 1 0 ./ectool --dev=1 pdwritelog 2 0 ./ectool --dev=1 pdlog Verify log output matches expectation: 2015-02-12 11:12:49.290 P0 SRC 2015-02-12 11:12:49.296 P1 SNK Charger PD 20286mV max 20000mV / 3000mA 2015-02-12 11:12:49.303 P0 New connection 2015-02-12 11:12:49.310 P0 Board-custom event --- END OF LOG -- Also, verify kernel logging of wedged event: [ 181.378420] PDLOG 2015/02/12 19:13:44.019 P0 Event 02 (0000) [] Also, trigger wedged state on Samus and verify log entry is written. BRANCH=Samus Change-Id: I55c7c839cf8300fcd3931dccdaaf16c1065e31a8 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248981 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: unwedge charge circuit if not charging for long timeAlec Berg2015-02-121-12/+105
| | | | | | | | | | | | | | | | | | | | | | | | This is another workaround for charge circuit wedging. It appears that the BQ PROCHOT is not entirely reliable at detecting charge circuit wedged, so let's take a big hammer to this and say if we have a >5V charger and we haven't been charging for a while, then attempt to unwedge the charge circuit. Only impact on user is the battery won't charge quite as fast since we stop charging briefly to unwedge the circuit. BUG=chrome-os-partner:36081, chrome-os-partner:36620 BUG=chrome-os-partner:36636 BRANCH=samus TEST=remove the PROCHOT check and wedge the circuit using "charger voltage 7000" and make sure that we unwedge after 10s (or 2min if we never recovered from last time). Change-Id: I6a0d83aef5fcfdecaeb85367d8207aeea7a99c06 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248940 Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org>
* pd: DRP: VCONN should be off at start of pd task.Todd Broch2015-02-125-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VCONN should be off at the start of pd task. This is handled initially by the defaults in gpio.inc. However in the case of a sysjump after a RW only firmware update the previous state would be preserved. This in turn would allow us to evaluate polarity incorrectly if an accessory was connected in the CC2 polarity and subsequently enable both VCONNs which would leave the port with both CCx lines at 3.3V. This change adds a new function, pd_config_init, which initializes VCONN(s) to off. Future CLs will evaluate other PD related GPIOs that may be left unitialized as a result of sysjump. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:36481 TEST=manual, 1. Boot samus w/ samus_pd in RO 2. connect hoho | dingdong in CC2 polarity to type-C port 3. sysjump to RW 4. unplug / plug hoho | dingdongs No longer see both VCONNs enabled. Change-Id: Ia53c06ea8face4da6829f9667f4f44a9034183be Reviewed-on: https://chromium-review.googlesource.com/248831 Trybot-Ready: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* cortex-m0: Add deferred schedulerAlexandru M Stan2015-02-127-80/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If 2 interrupts happen at the same time, there is a chance that the nested interrupt will not call svc_handler when it needs to. In extreme cases this could lead to tasks not getting woken up when they're supposed to and watchdog resetting. The reason stuff worked was because there were enough other interrupts around to eventually call the scheduler and switch to the ready task. This change modifies the interrupt calls to not call the scheduler directly (because in nested interrupt situation this causes problems), but defer the call to scheduling until after the irq finishes by triggering a low priority interrupt which will for sure call svc_host at the end. The PendSV irq was used for this purpose. BUG=chrome-os-partner:36193 TEST=No more SPI errors caused by scheduler problems TEST=usleeps now are more accurate, they're guaranteed to not take forever now BRANCH=veyron Change-Id: I42acde6b3eb7be2540a0de9a8562dee2ea2be7ab Signed-off-by: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248902 Tested-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* cortex-m0: Fix handling uint64 divide-by-0stabilize-6783.BRandall Spangler2015-02-111-0/+3
| | | | | | | | | | | | | | | | | | | | Divide-by-0 was jumping to a missing __aeabi_ldiv0 label. Add it, equivalent to the cortex-m code. BUG=chrome-os-partner:36126 BRANCH=minnie TEST=hack into main(): volatile uint64_t a = 1, b = 2; a /= b; and see that code compiles. Change-Id: I93884c6e41c8a3c5f47c141c323860efbfbc9ba9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248640 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* charge_manager: Minimize log spewShawn Nematbakhsh2015-02-112-18/+33
| | | | | | | | | | | | | | | | | | | | | | | | Previously, we tried to minimize log spew by keeping track of previous log entries and not writing new entries in some cases. Instead, we can write a log on the following events only: 1. A port becomes active or 2. A port becomes inactive or 3. The active charge port power limit changes or 4. Any supplier change on an inactive port Also, make charge_manager_save_log a non-static charge manager API function, so that other modules can record a log, if they have reason to believe a port has changed outside of a charge manager change. BUG=chrome-os-partner:33248 TEST=Manual on Samus. Make various power actions and observe logging. BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I5d5d3e186e85fdb1c59797ffbfb2f5a6ec04d94d Reviewed-on: https://chromium-review.googlesource.com/247891 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* charge_manager: Store dualrole capability in charge managerShawn Nematbakhsh2015-02-115-90/+51
| | | | | | | | | | | | | | | | | | | | Since charge manager is now informed of all capability changes as they happen, it makes sense to store the port capability within charge manager, rather than storing in pd. BUG=chrome-os-partner:36390 TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection. Run 'chgoverride -2' to prevent charging, then repeatedly insert + remove a dual-role charger on the other charge port. Verify that charging is still prevented. Finally, insert a dedicated charger and verify that the override is removed. Also, pass unit tests and verify correct detection in various scenarios with various chargers. BRANCH=Samus Change-Id: I3669050b37ddd67f6608bf790a07e74f86b6ac01 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/247724 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* CCD: Enable CCD when a debug peripheral is detectedAnton Staaf2015-02-101-0/+14
| | | | | | | | | | | | | | | | | | | This includes an additional call to board_set_usb_mux to ensure that the USB lines are correctly muxed for Case Closed Debugging to work. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I80694a1bc6cabb9c2ac2437552a68210855e94f0 Reviewed-on: https://chromium-review.googlesource.com/247722 Trybot-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* samus: fix won't charge after zinger plugged in during EC rebootAlec Berg2015-02-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix bug recently introduced in 1ab9aac that causes some units to not charge after an EC reboot with zinger plugged in. The problem is that we don't log the previous state of ACOK on initialization of the extpower task. So, the PD MCU gets stuck in charge state NONE when you unplug zinger because the EC thinks that ACOK transitioned from low to low. Fixed in two ways: first, the EC stores the initial state of ACOK when extpower task first runs. second, changed extpower_board_hacks() to run the same code when ACOK goes from low to low as it does when it goes high to low. BUG=chrome-os-partner:36596 BRANCH=samus TEST=Found a unit that reliably shows the problem. loaded this fix in RO and ToT in RW. sysjump RW with AC plugged in, then when you unplug AC, the PD goes to chgstate NONE and won't ever charge on subsequent attaches. sysjump RO with AC plugged in, then when you unplug AC, the PD acts as normal and goes to chgstate NONE and then 5V, and will allow charging every time AC is subsequently attached. Change-Id: I4124535b17d43a5711586ff2894df67a3bd49ec6 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248170 Reviewed-by: Shawn N <shawnn@chromium.org>
* CCD: Remove CCD specific board connect and disconnectAnton Staaf2015-02-103-37/+2
| | | | | | | | | | | | | | | | | | | | Previously the Case Closed Debugging system provided a way for the board to connect and disconnect the CCD USB lines correctly, but this functionality is better implemented by board_set_usb_mux. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I697ee9740c64ac93557d9fca8b2d10e858c51193 Reviewed-on: https://chromium-review.googlesource.com/247721 Trybot-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* Power Button: Wait for power button to be stable when waiting for releaseAlexandru M Stan2015-02-103-34/+52
| | | | | | | | | | | | | | | | | | The debounce timer might be too slow to actually update the state of debounced_power_pressed by the time we do power_button_is_pressed in the S3->S5 state transition. Solution is to move the power_button_wait_for_release function here and make sure there are no deferreds active. BUG=chrome-os-partner:35948 TEST=During dev mode screen, press power button, note the device stays off TEST=Print debounced_power_pressed in power_button_is_pressed(void), note it's not 0 when power button is actually pressed BRANCH=veyron Change-Id: I8258e9e5524bd65d6ea9c77ea5649304d2195bf0 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244590 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* USB: Fix cut and paste bug for board specific disconnectionAnton Staaf2015-02-101-1/+1
| | | | | | | | | | | | | | | Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I8ec4396370b7e3068d29d569b73fddc648e1f76f Reviewed-on: https://chromium-review.googlesource.com/247720 Trybot-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* stm32: Add delay after enabling peripheral clockVic Yang2015-02-1022-1/+129
| | | | | | | | | | | | | | | | | We need a dummy read after enabling AHB peripheral clock before we can access the peripheral. For APB, we also need a dummy read for STM32F3. BRANCH=All affected BUG=chrome-os-partner:33007 TEST=make buildall Change-Id: I47f4a024dca294f555428c3f2053c1d32835ebe0 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/246181 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* llama: add llama board supportBen Lok2015-02-1012-0/+1099
| | | | | | | | | | | | | | | | | | | This is to add llama board support: - new files in board/llama folder, including battery.c and led.c - new file power/mediatek.c, which is mostly based on power/tegra.c - modified flash_ec for llama board - disable tests for llama board. BRANCH=none BUG=none TEST=make BOARD=llama Change-Id: Ie1ae068c1a402f08e1449668b1be8f31105bb804 Signed-off-by: Ben Lok <ben.lok@mediatek.com> Reviewed-on: https://chromium-review.googlesource.com/243510 Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: lok.ben ben.mtk <ben.lok.mtk@gmail.com> Commit-Queue: lok.ben ben.mtk <ben.lok.mtk@gmail.com>
* mec1322: Fix LPC interrupt bit maskVic Yang2015-02-101-4/+4
| | | | | | | | | | | | | | | LRESET# interrupt should be GIRQ19 bit 0 instead of bit 1. BRANCH=None BUG=chrome-os-partner:36326 TEST=Run on Glower and doesn't see LRESET# interrupt storm. Change-Id: I1adedea63e9ec2851e1e09fc8c0eb8185070dad1 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/247790 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* Assert warm reset while flashing STM32 partsVic Yang2015-02-091-4/+14
| | | | | | | | | | | | | | | | | | | | | The STM32 bootloader reacts to the first command it sees and then sticks to that interface. On some devices, the AP is connected to I2C or UART on the EC, and if the AP talks when we are trying to flash the EC, the EC sticks to that interface and ignores requests from the servo board. Fix this by holding warm_reset so that the AP is down. BRANCH=None BUG=None TEST=Flash Ryu several times. TEST=Flash Plankton to make sure it doesn't break devices without warm_reset. Change-Id: I860fc65ba7fdaf0cbc9a0be641148b5095de394b Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/247360 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@google.com> Commit-Queue: Vic Yang <victoryang@chromium.org>
View Lorry Controller Status