summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* stm32/spi: Print packet on bad datastabilize-6297.BAlexandru M Stan2014-09-231-0/+7
| | | | | | | | | | | | | | | | | Just after a bad data error the EC will print the packet(pretty much the whole thing): in_msg=[02 00 0f 03 f4 09 00 00 ] I found it very helpful when debugging SPI TX/RX to know what the EC sees. BUG=chrome-os-partner:31390 TEST=Load spidev and send the EC bytes manually(malformed packets) BRANCH=None Change-Id: I037ab909076dc454379040e2e927dc6a0b5c5ea9 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218442 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* samus: accel: fix calibration bug, only using base sensor dataAlec Berg2014-09-231-1/+1
| | | | | | | | | | | | | | | | Fix accel calibration bug from refactoring. The motion_get_accel_lid() function used by calibrate routine to get lid accel data was actually returning base accel data. BUG=none BRANCH=none TEST=load onto samus, run accel calibration routine. Change-Id: I095381390267aa6ea3b3a74311c27f30d70e9c81 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219520 Reviewed-by: Sheng-liang Song <ssl@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* Remove floating point usage in lightbar codeVic Yang2014-09-231-84/+96
| | | | | | | | | | | | | | | Not every chip that we use has FPU. To make it easier to enable lightbar on chips other than LM4, let's remove floating point usage in lightbar code. Instead, scale those numbers by a factor of 10000. BUG=chrome-os-partner:32203 TEST=Run on Samus. Visually check lightbar. BRANCH=None Change-Id: I88b12bb66b5c586f2e14135069bd97d6b56832a1 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219246 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* plankton: Set polarity when connectedVic Yang2014-09-231-0/+1
| | | | | | | | | | | | | | | When a cable is connected, set USBC_POLARITY to the right polarity. This is done in a different way than how we do this on other boards because we only want to control polarity automatically on cable connection. BUG=chrome-os-partner:32163 TEST=Flip the cable, check USBC_POLARITY changes. BRANCH=None Change-Id: I903123b8fd729e8c913014b83812d20328600f8e Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219291 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* plankton: Do not send soft reset unless already sourcing powerVic Yang2014-09-231-10/+16
| | | | | | | | | | | | | | | | | | | | When 5v/12v/20v buttons are pressed, plankton first switchs to source role, set the requested source cap, and then perform a soft reset. However, if plankton was sink and just switched to source, the port partner might not have switched to sink and this leaves the CC line in a state where communication is not possible. The subsequent soft reset then fails. If we are not already sourcing power, we actually don't need a soft reset after changing source cap. BUG=chrome-os-partner:32163 TEST=Switch from sink to source. Doesn't see "soft reset" in console. TEST=Switch from 5V to 12V. See "soft reset". BRANCH=None Change-Id: Ia4b834c2e7dc1324b9143c46a72938845499e2fb Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219004 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* pd: use GET_POLARITY for SNK_DISCONNECTED state as well.Todd Broch2014-09-231-1/+2
| | | | | | | | | | | BRANCH=none BUG=none TEST=compiles Change-Id: Ic4c0631737885ca66ac4d8b826d5447363c820bb Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218384 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* hoho: Enable USB PD support.Todd Broch2014-09-235-2/+237
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CL to allow hoho to receive initial USB PD communication (source capabilities payload). BRANCH=none BUG=chrome-os-partner:31192 TEST=manual, When attaching hoho to fruitpie and configured via 'pd dualrole source' I see on hoho side: --- UART initialized after reboot --- [Reset cause: reset-pin power-on] [Image: RO, hoho_v1.1.2213-2bf6a29-dirty 2014-09-15 12:10:22 tbroch@brisket.mtv.corp.google.com] [0.000466 Inits done] C0 st2 Console is enabled; type HELP for help. > [0.250678 USB PD initialized] C0 st3 [0.264629 PD TMOUT RX 1/1] RX ERR (-1) Request [1] 5V 3000mA C0 st4 C0 st5 C0 st6 > pd 0 state Port C0, Enabled - Role: SNK Polarity: CC2 State: SNK_READY Change-Id: Ic5871946425f0ff12d717fbbbbb9e81c6b67cc6f Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217977 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Plankton: reset USB hub on PORVic Yang2014-09-231-1/+20
| | | | | | | | | | | | | | | On power-on reset, the USB hub might get stuck in a locked state due to a race condition in hardware. Let's reset the hub after 0.5 seconds to make sure this doesn't happen. BUG=chrome-os-partner:32163 TEST=Power on the board. Measure the reset signal. BRANCH=None Change-Id: I0f89883c5db7c5376f3612da1615ba4f86b5efa6 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219199 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Plankton: Add console command to reset USB hubVic Yang2014-09-235-0/+121
| | | | | | | | | | | | | This command resets the USB hub through the IO expander. BUG=None TEST=Reset the hub on Plankton. BRANCH=None Change-Id: Ia77a1e326adc6aba65438534158a4c461479727a Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218758 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: Do not assert RTCRST on every recovery mode bootDuncan Laurie2014-09-231-4/+0
| | | | | | | | | | | | | This causes the loss of CMOS stored flags like dev_boot_usb. BUG=chrome-os-partner:30832 BRANCH=none TEST=pass suite:faft_bios on samus Change-Id: I5e168eaf496ddebb5b409a42b6d8b1a05693db40 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219215 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* stm32-USB: Initial USB bulk endpoint stream driverAnton Staaf2014-09-234-0/+422
| | | | | | | | | | | | | | | | | This stream driver works like the USART stream driver but connects to two bulk USB endpoints. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I9cbd2e54a811d3e32c68a820f7ab5de693c29569 Reviewed-on: https://chromium-review.googlesource.com/216002 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* ectool: Do not increase buffer size after probe max size from ecPuthikorn Voravootivat2014-09-231-6/+16
| | | | | | | | | | | | | | | | During the communication init, ectool will probe max request and response packet size from ec and set packet size accordind to that. However, with older kernel's ec driver, the buffer allocated by kernel is not large enough and this will cause kernel bug. BUG=chrome-os-partner:31989 TEST=ectool version runs fine on blaze BRANCH=ToT Change-Id: I499a5305c8fa8b0fd6f3be8554c9cf066b7e0828 Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219114 Reviewed-by: Mohammed Habibulla <moch@chromium.org>
* samus_pd: enable low power idleAlec Berg2014-09-236-25/+74
| | | | | | | | | | | | | | | | | | | | | Enable low power idle for samus_pd. Low power idle is only entered when no USB PD device is connected. BUG=chrome-os-partner:31226 BRANCH=none TEST=load onto samus_pd, use idlestats command to verify that we are going into deep sleep (STOP mode). Run 30 min. and verify no watchdog reboots or anything out of ordinary. Also, verify that host commands from EC work when going into deep sleep by sending host commands on the EC console with pdcmd 0 0. Change-Id: I3e2e04e6c4c0a84e291286dbed90945847e0dfdd Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218957 Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32-USART: Add generic stream based usart driverAnton Staaf2014-09-2312-0/+847
| | | | | | | | | | | | | | | | | | | This driver can be used to access multiple usarts using an abstract stream interface. The stream interface can also be used in drivers for the host interface and USB console interface, providing a consistent API across all character stream style IO. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: Icf567f0b0fa4eb0e9ad4cdb0be8edc31c937a7de Reviewed-on: https://chromium-review.googlesource.com/209671 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* samus: enabled fast charging for EVT ATL cellsAlec Berg2014-09-231-19/+51
| | | | | | | | | | | | | | | | | Enable fast charging with profile designed for ATL cells that will be used in EVT. BUG=chrome-os-partner:23776 BRANCH=none TEST=Took detailed charging/discharging data and verified that the actual profile matches the desired profile and that the fast charging profile is actually faster than the standard. See bug report for more info and data collected. Change-Id: Ic11ab89e48afb73987b8013abf8b0564e1138156 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/212980 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* stm32f0: low power idle taskAlec Berg2014-09-222-22/+170
| | | | | | | | | | | | | | | | | | | Add low power idle task to stm32f0. This can be enabled by defining CONFIG_LOW_POWER_IDLE. This low power idle uses STOP mode to conserve power. BUG=chrome-os-partner:31226, chrome-os-partner:28335 BRANCH=none TEST=add #define CONFIG_LOW_POWER_IDLE to samus and use idlestats console command to verify using deep sleep. also #define CONFIG_FORCE_CONSOLE_RESUME and make sure serial console works without problems when going into deep sleep. Change-Id: I76b0ceb8587a139faa74353d3d8efb4f689fc669 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218956 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32f0: fix UART clock source for console on UART2Alec Berg2014-09-221-2/+2
| | | | | | | | | | | | | | | | Bug fix. Recently changed to use HSI 8MHz clock as clock source for console UART, but the clock register was set incorrectly for the case that the console UART is UART2. BUG=chrome-os-partner:32170 BRANCH=none TEST=Tested on fruitpie which is using UART2 for console. Verified that console works. Change-Id: Ied629eb3828e5fab911acb6a8e5f4087563ddb32 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219312 Reviewed-by: Vic Yang <victoryang@chromium.org>
* pd: make flash_pd.py forward compatible.Todd Broch2014-09-221-11/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Older versions of flash VDM supported a 'rw_hash' command that has since been deprecated in favor of 'info' command. This CL makes flash_pd.py try either in order to determine whether the pd flash erase was successful. BRANCH=none BUG=chrome-os-partner:28330 TEST=manual, succesfully run on zinger with only 'info' command support util/flash_pd.py -m 1 zinger_ec.RW.flat 2014-09-18 14:35:39,305 - root - INFO - Current PD FW version is zinger_v1.1.2192-5cd 2014-09-18 14:35:39,305 - root - INFO - Flashing 11532 bytes 2014-09-18 14:35:45,779 - root - INFO - Successfully erased flash. 2014-09-18 14:35:45,890 - root - INFO - Chunk 0 of 481 done. ... 2014-09-18 14:36:39,133 - root - INFO - Chunk 480 of 481 done. 2014-09-18 14:36:46,072 - root - INFO - Flashing DONE. 2014-09-18 14:36:46,072 - root - INFO - SHA-1: f6b296ba d474edc4 2e917ad0 33cd16cb 0f51a3fc 2014-09-18 14:36:46,090 - root - INFO - New PD FW version is zinger_v1.1.2226-bea Change-Id: I32f8b06fa546aa99c8290b6b73faa9b8df05e4fb Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218878 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* stm32f0: Change uart clock to HSIAlexandru M Stan2014-09-191-1/+22
| | | | | | | | | | | | | | | | | | | | | When waking up from sleep, the real CPU_CLOCK is a lie for a moment(since we cannot switch to the real clock during the first character) so the first character will be corrupted. The UART clock is now sourced from HSI(8MHz) which is available from the first moment after the cpu wakes up from sleep. BUG=None TEST=Console should work. When waking up(not implemented yet) it will also not lose a character BRANCH=None Change-Id: Ia12ed0634290f3edadfe3471b311759c3176260e Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218728 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* stm32f0: add RTC alarm functionalityAlec Berg2014-09-192-0/+220
| | | | | | | | | | | | | | | | Implement RTC alarm, with resolution 50us, for stm32f0. This is useful for using low power modes and waking up after set period of time. BUG=chrome-os-partner:31226, chrome-os-partner:28335 BRANCH=none TEST=tested on samus_pd with CONFIG_CMD_RTC_ALARM defined and used rtc_alarm console command to test various timeout periods. Change-Id: Ibabd8662cfbea654c7de387669f7be83af4fd79d Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218322 Reviewed-by: Todd Broch <tbroch@chromium.org>
* Remove PD power check in flash erase routineVic Yang2014-09-191-17/+0
| | | | | | | | | | | | | | Now that ping is disabled by default, we can remove the PD power check in flash erase routine. BUG=chrome-os-partner:31362 TEST=Build Ryu BRANCH=None Change-Id: Id021529aa2323050ff760b3ce22312c96f23609e Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218080 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Fixup for coreboot & portability.Todd Broch2014-09-191-5/+5
| | | | | | | | | | | | | | | Removed include for sha1 and just hardcoded the #define for now. BRANCH=none BUG=chrome-os-partner:32108 TEST=manual, can compile EC & BIOS firmware for samus Change-Id: Iab03315041ec9ac12e85ca93f97b80b850c61377 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218809 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Stream: Add In and Out stream interfaces and configAnton Staaf2014-09-186-0/+187
| | | | | | | | | | | | | | | | | | These interfaces will be used by USART, USB and I2C stream drivers to provide a uniform interface for console mux'ing code. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: If8938512c29708f7b8c28f6ca1c707aa6b5c1708 Reviewed-on: https://chromium-review.googlesource.com/216001 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org>
* Queue: Add functionality needed by new USART stream driverAnton Staaf2014-09-186-160/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously there was no way to remove multiple units at a time from the queue, and the queue was wasting an entry to disambiguate full from empty. There was also no way to get the free entry count from the queue, only the ability to query if it was above a required amount. The queue was also storing its constant compile time configuration as well as its dynamic state in the same structure. This wasted RAM on configuration information that doesn't change. This refactor fixes these issues, making the queue suitable for use in the new USART stream driver. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I284cee52d8189928dbc4c499f87ab34e14019e5a Reviewed-on: https://chromium-review.googlesource.com/210533 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org>
* samus: exchange status with PD MCU on bootAlec Berg2014-09-172-4/+11
| | | | | | | | | | | | | | | | | | | | | On boot, the EC should send host command to exchange status with PD MCU. This allows EC to get the correct input current limit when EC reboots and PD does not. Also had to move some of the charger state machine initialization to run with HOOK_INIT so that it runs before the tasks run. BUG=none BRANCH=none TEST=tested on EVT samus. Without this change, if you reboot EC, and run charger command, the charger input current limit is 512mA. with this change, when the EC reboots, it sends host command to PD MCU to get current limit and sets it appropriately. Change-Id: I5426f0fc3a62b6cd7a73f55cb11b895902a54903 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216879 Reviewed-by: Todd Broch <tbroch@chromium.org>
* fruitpie: Fix default OSPEEDR reg settings for PB15.Todd Broch2014-09-171-1/+1
| | | | | | | | | | | | | | | | OSPEEDR cfg for PB15 was inadvertently set to '01' for PB15 (should be '00'). Not sure it causes any harm but shouldn't be set according to comment which is speeding up output pins on SPI interface PB12-14 only. BRANCH=none BUG=none TEST=manual, compiles, boots, talks PD w/ samus_pd. Change-Id: Ibc2ec1c427a2c3c92ffdf424b668752b1c0b0032 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217963 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Add support for BQ27742 battery gauge chipVic Yang2014-09-171-5/+24
| | | | | | | | | | | | | | | | This reuses most of the existing BQ27541 driver, but changed necessary parts to make it work. BUG=none TEST=Boot on Ryu. See battery charging. BRANCH=factory-ryu-6212.B Change-Id: I3a7325a821c81f84396bcc328036b6a5e7749a2e Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217198 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit f44593e20bf61a2243d7baaae901c912ca798d75) Reviewed-on: https://chromium-review.googlesource.com/218413
* samus: add automatic retries for host commands from EC to PDAlec Berg2014-09-173-22/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add three retries for EC to PD host commands. With this change, removed retry mechanism in host_command_pd.c which was a retry only for the specific EC_CMD_PD_EXCHANGE_STATUS host command. BUG=chrome-os-partner:32006 BRANCH=none TEST=Loaded EC code onto samus. Added the following code for testing failed host commands to samus_pd common/host_command.c host_command_task(): if ((evt & TASK_EVENT_CMD_PENDING) && pending_args) { if (i++ != 4) pending_args->result = host_command_process(pending_args); else { pending_args->result = -7; i = 0; } host_send_response(pending_args); } This test code on samus_pd drops one in every five host commands. With this code, from the EC, I send "pdcmd 0 0", and verified that 1 out of 5 times the EC prints a host command failed code, but then retries successfully. Change-Id: Ibf43feefbfc7d791c45c6689b82c66f5d71046ab Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217461 Reviewed-by: Todd Broch <tbroch@chromium.org>
* ectool: add new parameter to identify proper EC.Gwendal Grignou2014-09-146-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | Add parameter name to identify which EC to talk to. Superseed --dev parameter, removed soon. --name cros_ec (the default): send commands to /dev/cros_ec. --name cros_pd: send commands to /dev/cros_pd. ... BUG=chrome-os-partner:31513 TEST=Tested on samus: check ectool --name cros_pd version returns proper data: ectool --name=cros_pd version RO version: samus_pd_v1.1.2079-8e4f9fc-dirt .... CQ-DEPEND=CL:217297 BRANCH=ToT Change-Id: Ie8b5c6c184d73a89b4445e88d6f104169176b9f3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217311 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Veyron: Fix warm-reset commentAlexandru M Stan2014-09-131-1/+1
| | | | | | | | | | BUG=None TEST=None, no code changes BRANCH=None Change-Id: Ie5675938c918d0f79779bf46557aff1074f49512 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217882
* Veyron: Fix leakage power before AP runningChris Zhong2014-09-132-5/+2
| | | | | | | | | | | | | | | | | EC needs to ensure EC_INT & SPI_CS are in input state or output low, Before AP on. Otherwise it will cause leakage to AP, and power_on timing is incorrect. BUG=None TEST=power_on timing is correct. BRANCH=None Change-Id: I2dc9c35b4782e4f5c138b31944af21d8248215cd Signed-off-by: Chris Zhong <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/217691 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Alexandru Stan <amstan@chromium.org> Commit-Queue: Alexandru Stan <amstan@chromium.org> Tested-by: Alexandru Stan <amstan@chromium.org>
* Veyron: Change PWREN to PWRONChris Zhong2014-09-132-11/+9
| | | | | | | | | | | | | | | | The PWRON signal is actually a pulse that's only supposed to happen at the S0->S5 transition. We can release it when we see POWER_ON. BUG=None TEST=Power on and power off normally. "halt" makes the system go to S5 instead of rebooting. BRANCH=None Change-Id: I14f1cc83c8a4a89226574cf605823d247ce9508a Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217690 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* hoho: Enable spi2 master for comm with external flash.Todd Broch2014-09-123-0/+46
| | | | | | | | | | | | | | | | | | | | | | | BRANCH=none BUG=chrome-os-partner:31192 TEST=manual, from console, > spi_flashinfo Manufacturer ID: ef Device ID: 40 14 Unique ID: dc 63 a0 00 db 57 56 28 Capacity: 1024 MB > spi_flashread 0 64 Reading 64 bytes from 0x0... 00: 00 b8 00 00 8e d0 8e d8 8e c0 bc 00 80 b8 94 41 10: 8e d8 be 00 00 bf 00 1a b9 ee 1a 2b cf d1 e9 f3 20: a5 b8 00 00 8e d8 fd b8 55 55 bf fe 7f b9 00 04 30: f3 ab fc bd 00 00 ea e0 00 02 40 c3 56 96 92 85 Change-Id: I9d8aade3fb99f4a9d85afceb153a350750382a81 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217531 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* auron/peppy: fix setting fan max speed by rpm instead of duty cycleMohammed Habibulla2014-09-121-1/+1
| | | | | | | | | | | | | | | Setting initial max speed works by setting RPM but fails when setting with duty cycle BUG=chrome-os-partner:31801 TEST=booted on auron and peppy and confirmed that initial fan speed is set to maximum BRANCH=none Change-Id: I81172a414df13c2e0b2d0f4fe7ff1270fa5f60a3 Signed-off-by: Mohammed Habibulla <moch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217790 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* extra: Move lightbar simulator into subdirectoryAnton Staaf2014-09-118-43/+41
| | | | | | | | | | | | | | | | | This clears the top level extra directory for additional extras. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=cd extra/lightbar; make; lightbar Change-Id: If05a768e4d33cbf21b2ce47a056c960a95728558 Reviewed-on: https://chromium-review.googlesource.com/217537 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* samus: increase stack size for PDCMD taskAlec Berg2014-09-111-1/+1
| | | | | | | | | | | | | | Increase task stack size for PD host command task to 512. The nominal stack size is 328 / 384, which is pretty close to the edge. BUG=none BRANCH=none TEST=make -j buildall Change-Id: Ifdf04923b817c832cbb77ba7f61c06a560aec97d Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217452 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* stm32f07: change erase page size to 2kBAlec Berg2014-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change erase page size from 1kB to 2kB. The datasheet specifies that the page size is 2kB. This was causing occasional failures in flashrom because flashrom only erases and writes pages where the flash contents don't match the new binary. BUG=none BRANCH=factory-ryu-6212.B TEST=Load onto samus_pd, and verify that flashrom works successfully. Also added console debugging to verify that the actual erase page size is 2kB. I left the CONFIG_FLASH_ERASE_SIZE at 1024 and added the following code. static int command_flash_is_erased(int argc, char **argv) { int offset = -1; int size = CONFIG_FLASH_ERASE_SIZE; int rv; rv = parse_offset_size(argc, argv, 1, &offset, &size); if (rv) return rv; ccprintf("Offset %d, size %d, is erased: %d\n", offset, size, flash_is_erased(offset, size)); return EC_SUCCESS; } DECLARE_CONSOLE_COMMAND(flashiserased, command_flash_is_erased, "", "", NULL); Then: > flashiserased 2048 Offset 2048, size 1024, is erased: 0 > flashiserased 3072 Offset 3072, size 1024, is erased: 0 > flashiserased 4096 Offset 4096, size 1024, is erased: 0 > flasherase 2048 Erasing 1024 bytes at 0x800... > flashiserased 2048 Offset 2048, size 1024, is erased: 1 > flashiserased 3072 Offset 3072, size 1024, is erased: 1 > flashiserased 4096 Offset 4096, size 1024, is erased: 0 You can see when it tries to erase 1kB at 2048, it actually erases 2kB. Change-Id: I02772d4671784930765df63fa99968a07b15882e Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217475 Reviewed-by: Vic Yang <victoryang@chromium.org>
* samus: enhance usbpd host command to return port status.Todd Broch2014-09-113-5/+31
| | | | | | | | | | | | | | | | | | | | | | | CL provides some useful information similar to the EC console command 'pd state <port>' when host command 'usbpd <port>' is sent from host with no additional arguments. Also added a few build asserts for role & mux strings. BRANCH=none BUG=chrome-os-partner:31690 TEST=manual ectool --interface=lpc --dev=1 usbpd 1 Port C1 is enabled. Role:SNK Polarity:CC1 State:6 # has zinger attached ectool --interface=lpc --dev=1 usbpd 0 Port C0 is enabled. Role:SNK Polarity:CC1 State:2 Change-Id: Id44eb7bf6a6fcfa888a0008a2249601967c50bcc Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217138 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: Add host command to query USB type-C accessory attached.Todd Broch2014-09-116-24/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | PD accessories that are RW update-able will broadcast their rw_hash SHA1 digest upon connection to the PD MCU which will store it. For update purposes, the host needs that accessories device id and rw_hash to determine its proper firmware update payload. This CL creates a host command that requests the type-C accessory info attached to a particular port. It also implements an ectool command to expose the host command. BRANCH=none BUG=chrome-os-partner:31361 TEST=manual, # connect zinger to port 1 on samus ectool --dev=1 --interface=lpc infopddev 1 Port:0 Device:1 Hash: 0x7f4d7a13 0xf07b65b9 0x41181e10 0xb99b3d5f 0x9dee1206 ectool --dev=1 --interface=lpc infopddev 0 Port:0 has no valid device Also do the same on port 0 with similar results. Change-Id: Id63c7edad77a43d43c14d8cd6bd96e08d0d9b501 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216814 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* PD: Cleanup 'pd' console command.Todd Broch2014-09-111-55/+61
| | | | | | | | | | | | | | | | | | | | | | | Cleanup pd commands that were unnecessarily parsing port argument. BRANCH=none BUG=chrome-os-partner:31361 TEST=manual, following commands work as intended pd dualrole pd dualrole off pd dualrole pd dump pd dump 1 pd dump pd enable 1 pd rwhashtable Change-Id: Id70af323ec2684aca04d13ba5f9417be8feb5765 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216813 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: Add host command to store USB PD device id & rw_hash entry.Todd Broch2014-09-113-1/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PD accessories that are RW update-able will broadcast their rw_hash SHA1 digest upon connection and remain in RO briefly for a response. In order to speed-up the response and decouple common case of accessory is up-to-date, the PD MCU will keep a small 4 entry table of PD accessory device ids and their corresponding RW hashes for quick lookup. The AP will be the source of new updates and their corresponding device id's and RW hashes and therefore needs a method to update the PD MCU table. This CL creates the table, host command & ectool command to facilitate future driver / daemon to update the RW hash entries. BRANCH=none BUG=chrome-os-partner:31361 TEST=manual, # from AP for i in `seq 1 8` ; do ectool --dev=1 --interface=lpc rwhashpd $i $i $i $i $i $i done # from samus_pd console pd rwhash Device:5 Hash: 0x00000005 0x00000005 0x00000005 0x00000005 0x00000005 Device:6 Hash: 0x00000006 0x00000006 0x00000006 0x00000006 0x00000006 Device:7 Hash: 0x00000007 0x00000007 0x00000007 0x00000007 0x00000007 Device:8 Hash: 0x00000008 0x00000008 0x00000008 0x00000008 0x00000008 Change-Id: Ibe87b3594793cd5215eba42160489b26974aadbc Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/214366 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* STM32F0 TX FIFO FixesAlexandru M Stan2014-09-111-17/+75
| | | | | | | | | | | | | | | | | | | | | | | | | Whenever we're sending raw status bytes from the EC(while the we're not DMAing) the bytes kinda get garbled, and not get sent in the right order. Sometimes we want the last byte sent to keep repeating, the problem is that it doesn't. Seems like the tx fifo doesn't play nice with the DMA. The way we fix this is by sending bytes 4 times, effectively bypassing the TX fifo. Protocol v2 was not fixed yet. It just displays a warning if one tries to use it on F0. BUG=chrome-os-partner:31390 BRANCH=None TEST=ectool version should work in the most recent kernel(with the v3 protocol version). spidev/python "s.transfer("\xdc\x02\x00\xde"+"\x00"*100)" should return a deterministic packet(the only variation between calls should be the number of \xfa recieved(40 vs 41 or so)). "flashrom -p ec -l /tmp/layout.txt -i rw:/tmp/rw.bin -w -V" now works properly. Change-Id: Ia2772277428bd45013f5721a6bedab13d0591423 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217083 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* plankton: fix charging voltage selectionAlec Berg2014-09-102-2/+5
| | | | | | | | | | | | | | | | Fix for plankton v2 so that the VBUS voltage selection buttons work properly (5V, 12V, and 20V). BUG=none BRANCH=none TEST=load onto plankton v2, connect type-C to samus, and press 5V, 12V, and 20V buttons. read adc on samus side to verify it is getting the proper voltage. Change-Id: I5004675bf658834219c295292c669182af7d8393 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217258 Reviewed-by: Vic Yang <victoryang@chromium.org>
* plankton: add flag for prog_en to flash_ecAlec Berg2014-09-101-0/+11
| | | | | | | | | | | | | | | | | | | | Add setting of new GPIO, prog_en, to flash_ec to be able to program new plankton boards. This pin must be on for boot0 and nrst to be connected from the FTDI to the MCU. BUG=chrome-os-partner:31633 BRANCH=none TEST=manual, sudo servod -c plankton.xml util/flash_ec --board=plankton CQ-DEPEND=CL:216160 Change-Id: I29f882856e24147a7af283c5e82298c7736b8662 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216161 Reviewed-by: Todd Broch <tbroch@chromium.org>
* Flashing: Force board into reset for flashingAnton Staaf2014-09-092-1/+5
| | | | | | | | | | | | | | | | | | | | | This ensures that nothing previously flashed to the baord can interfere with the flashing operation (by wedging the MCU or putting it into a state that the falshing code can't handle). This also adds a dependency on ec.bin to the flash target, ensuring that the firmware image is up to date when flashing. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=none TEST=make buildall -j Change-Id: I8cdfa6f5c84ed84d6b6e6b30d6683a23087f2c63 Reviewed-on: https://chromium-review.googlesource.com/215991 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* Util: Make MAX and MIN macros side effect safeAnton Staaf2014-09-091-3/+14
| | | | | | | | | | | | | | | | | Previously the MAX and MIN macros evaluated their arguments twice. This can cause problems with parameters that have side effects, or parameters that are volatile. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=none TEST=make buildall -j Change-Id: I51c6c6c207d9cd4d11a3b4d237eb9e491a9c4935 Reviewed-on: https://chromium-review.googlesource.com/215990 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* samus: Fix comment about I2C portDuncan Laurie2014-09-081-2/+2
| | | | | | | | | | | | | The comment indicates port 1 but should be port 0. BUG=chrome-os-partner:31833 BRANCH=None TEST=build and boot on samus Change-Id: I5dc39af2cb52dfca625110ed3c410611dd89d176 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216943 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* pd: check result of enabling vbus on type-C portsAlec Berg2014-09-081-1/+8
| | | | | | | | | | | | | | | | | | | | | | | Add checking the return value of enabling vbus in SRC_DISCONNECTED. If failed to enable vbus, don't transition to SRC_DISCOVERY. This can happen on zinger if zinger is in a fault condition, but once the fault is cleared, we need to be in SRC_DISCONNECTED in order to re-apply vbus. BUG=none BRANCH=none TEST=load onto EVT zinger. without this change, if zinger is plugged into a samus without a battery, when PD MCU is reset, zinger gets stuck in SRC_DISCOVERY with vbus disabled because pd_set_power_supply_ready() returns an error. This means to get power back to samus, we need to unplug and replug raiden. This change fixes the problem. Change-Id: I2ac75c7095b5d819b54b2f25ec974ccfd974e1e2 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216608 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* samus: change PD reset gpio to push-pullAlec Berg2014-09-081-1/+1
| | | | | | | | | | | | | | | Change USB_MCU_RST gpio used to reset PD MCU to push-pull instead of open drain. BUG=none BRANCH=none TEST=tested on EVT samus by using gpioget/gpioset to make sure we can actually reset the PD MCU from the EC. Change-Id: Id8460fdb32bc32d0dd4c236f3050d241312dce23 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216607 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* samus_pd: fix switching spi bus for type-C port 0 and 1Alec Berg2014-09-081-2/+2
| | | | | | | | | | | | | | | | | We switched which spi bus we were using for each type-C port EVT, but missed one place where the busses should have been switched. Note, this bug wasn't actually causing any problems because we enable both spi busses at init time and they remain enabled. BUG=none BRANCH=none TEST=load on EVT samus, make sure PD negotiation works on both ports Change-Id: I7b4fbee01b58be41521745d7bef6d9357e50be57 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216606 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
View Lorry Controller Status