summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* DragonEgg: enable EC UARTDino Li2018-07-131-0/+1
| | | | | | | | | | | | | | | EC UART works with this patch. BUG=none BRANCH=none TEST=the debug messages are printed on the UART console. Change-Id: I307331439e34546516199a1f321ffb3f53c1df0a Signed-off-by: Dino Li <Dino.Li@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1133615 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* cortex-m: Generate vector table in CPatrick Georgi2018-07-135-319/+385
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Different versions of the linker behave differently when mixing object built with lto enabled (desirable for code size reduction) and disabled (assembler code), especially when they refer to each other symbols: The file evaluation order of the linker becomes important as it eliminates dead code at various points in time, and LTO code referring to non-LTO code or vice versa, is not visible at early runs. Sadly, just changing the order on the command line isn't sufficient: What works for gcc8 breaks gcc6 (and may behave different in even more ways on gcc4 or other versions). Therefore, implement the vector table in C, so it's compiled in LTO mode, just like the code it refers to. BUG=b:65441143 BRANCH=none TEST=with this change coral EC is functional when built with the gcc 8.1 based coreboot toolchain. Change-Id: I9b75f6558f0357e18000ff1161096c8f9c94a8ac Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1120333 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Makefile.rules: only update version.h timestamp if it changedPatrick Georgi2018-07-131-1/+2
| | | | | | | | | | | | | | BUG=none BRANCH=none TEST=buildall with no change is much faster now (no relinking of ec.*.elf) Change-Id: I844b5f6836462efaa98a1d26edcaf8f8a3c47567 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1126316 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* flash-stm32h7: Invalidate D-cache after erase/write operationsNicolas Boichat2018-07-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When erasing or writing to the flash, the core may still have some of the old data in cache. Among other things, this confuses flashrom when it tries to read back an erased block, as it thinks that the erase operation was unsuccessful. This, of course, will have some moderate performance impact when doing memory operations, but hopefully those are rare enough to not matter significantly. The I-cache does not have such issues, as we invalidate it on sysjump/boot, when it actually matters. BRANCH=none BUG=b:111144409 TEST=flashrom works reliably: cp ec.bin ec.bin.blank dd if=/dev/zero of=ec.bin.blank bs=1024 seek=1024 count=1024 conv=notrunc flashrom -V -p ec:type=fp -i EC_RW -w ec.bin.blank flashrom -V -p ec:type=fp -i EC_RW -w ec.bin TEST=flashread returns correct data after an erase EC> flashwrite 0x180000 1024 => Initialize flash EC> flashread 0x180000 1024 => Loads data in cache EC> flasherase 0x180000 131072 EC> flashread 0x180000 1024 => Make sure cache was invalidated Change-Id: I58c26aa5a5715cea4fd7997414fd3f0c8a784572 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1134719 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32/system: Fix watchdog-initiated resetNicolas Boichat2018-07-132-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Reference Manuals for STM32H7 and STM32F4 makes it clear that, when updating the watchog reload value, one needs to wait until IWDG_SR bit RVU is reset before reloading the watchdog. (the code in question is only used on STM32H7 and STM32F4, as other variants use OBL_LAUNCH to reset themselves, so I didn't check the other RMs). This probably has not been seen before, as, normally, we use a 1s watchdog timeout, so the EC would reset anyway after a second (since it is stuck in the while loop below). On meowth_fp, however, we use a 10 seconds watchdog, and the EC takes too _long_ time to reboot, which breaks things like flashrom. BRANCH=none BUG=b:111144409 TEST=On nocturne_fp, run: for i in `seq 1 1000`; do echo $i; \ ./ectool --name=cros_fp reboot_ec cold; sleep 1; done No watchdog warning, no error. Change-Id: I110fa9873ed974bfafce23389866aac8cabb662a Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1134631 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* assert/panic: mark noreturn to inform the compilerPatrick Georgi2018-07-125-5/+11
| | | | | | | | | | | | | BUG=b:65441143 BRANCH=none TEST=buildall with gcc8.1 stops failing on this family of functions Change-Id: I44f9d643e46f955ea0cd0b5893c2806a4e3f52b0 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1126315 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Nami: Toggle power of PS8713B on suspend/resumeDaisuke Nojiri2018-07-122-1/+3
| | | | | | | | | | | | | | | | | | GPO32 is connected to #5:Power_Down pin of PS8713B on Sona. We enable power on resume and shut it down on suspend. Other boards don't use the pin. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b:79722847 BRANCH=none TEST=None Change-Id: Ic4fa6cafaf976bdba9b60b438a95b9ae8c684737 Reviewed-on: https://chromium-review.googlesource.com/1130658 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* tcpc: disallow PD_SUSPEND if not enough powerJett Rink2018-07-121-0/+42
| | | | | | | | | | | | | | | | | | | | | | We do not want to allow depthcharge to suspend the PD port for a firmware upgrade if there is not enough battery power to last us during the full firmware upgrade. We cannot use the active_charger function as the EC has just jumped to RW and has not fully initialized the charger state. We use Vbus presence as a good enough approximation that power may be coming in from that port. BRANCH=none BUG=b:78334391 TEST=No battery or deeply discharged battery will skip TCPC upgrade on a yorp if there is a usb charger in that port. Otherwise the upgrade will still be attempted. Change-Id: I9af9cb84cfae611b6ab051d318e2083962424de1 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1123314 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* charger/mt6370: Fix led_set_color enables wrong LED.Yilun Lin2018-07-122-2/+2
| | | | | | | | | | | | | | | | The index of LED enable bit in the register is counting from the MSB. BRANCH=None TEST=mt6370_led_set_color() on EVB, checks the LED flash accordingly. BUG=b:80160408 Change-Id: I9c748b5f91a62746adaeab59899cd0222305e06b Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1134927 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* yorp: Change LED blink timingVenkateswarlu Vinjamuri2018-07-111-2/+2
| | | | | | | | | | | | | | | | | | | | In S0ix, Charge/Battery LED consumes too much power. It's on for 4sec and off for 1sec and consumes 1mw. Change LED timing to on for 1sec and off for 3sec. This reduces power to negligible. BUG=b:78497503 TEST=Verify LED timing. Change-Id: I643cb742071e6e56559efadc0e7eadc7cc02132c Signed-off-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com> Reviewed-on: https://chromium-review.googlesource.com/1117749 Commit-Ready: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.corp-partner.google.com> Tested-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.corp-partner.google.com> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.corp-partner.google.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* grunt,careena: Raise the charger current supremum.Jonathan Brandmeyer2018-07-112-3/+15
| | | | | | | | | | | | | | | | | | | | | | Raise the current limit to the maximum Sink Standby limit allowable by USB-PD. The former current limit is intended to improve compatibility with BC1.2 chargers that brownout at the full 500 mA of supply. However, there is a risk that it will also cause battery brownouts and failure to boot in a startup condition of a highly imbalanced battery pack. This startup condition may happen after an extended period of rest prior to delivery to the end customer, which leads to poor customer first impressions and a high RMA rate. TEST=Grunt EVT clamshell and USB-PD analyzer, verify that the lowest current drawn during an initial boot sequence is ~0.5A. BRANCH=none BUG=b:111214767 Change-Id: I4dc7b143fd947c1c5bbdb8787ab30f92e587ed47 Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1133424 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* Bip: increase I2C bus speedsDiana Z2018-07-111-2/+2
| | | | | | | | | | | | | | | Now that bip is past initial bringup, the I2C speeds on the USBC lines should be increased to 400k. BUG=b:77139726 BRANCH=none TEST=verified type-C display behavior is unaffected by speed change Change-Id: Ic1c65d3a518663b6cefa3245742f2f42115f202c Signed-off-by: Diana Z <dzigterman@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1133583 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* DragonEgg: Change CHIP_VARIANT to it8320dxDino Li2018-07-111-1/+1
| | | | | | | | | | | | | | | To apply IT8320DX setting on DragonEgg board. BUG=none BRANCH=none TEST=make buildall Change-Id: I5a22a747f4431f2a8b17dcefca973375744ea2e4 Signed-off-by: Dino Li <Dino.Li@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1133078 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* vboot: Don't invalidate cached hash for EXEC_IN_RAM boardsDaisuke Nojiri2018-07-111-22/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a cached hash is invalidated on flash erase or write. This causes the hash to be (unintentionally) equal to the one expected by the AP after flashrom updates EC-RW directly on EXEC_IN_RAM devices. This patch makes EC skip invalidation of the cached hash if the board supports EXEC_IN_RAM. At the next AP reboot, AP will catch the hash mismatch and triggers software sync to resolve the mismatch. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b:78285812,b:80143039 BRANCH=none TEST=Verify EC-RO/RW versions are updated on a dogfood Akali as follows: 1. emerge-nami chromeos-firmware-nami to build chromeos-firmwareupdate 2. Replace bios.bin and ec.bin in chromeos-firmwareupdate with new images 4. Run 'chromeos-firmwareupdate -m autoupdate' on DUT 5. Run reboot command on AP Change-Id: Ie5f80e4784814569c14d4cf2a03ddb9d1257cfd5 Reviewed-on: https://chromium-review.googlesource.com/1130552 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* kukui: emulate eMMC boot mode using SPI controller.Nicolas Boichat2018-07-116-3/+333
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kukui is not able to boot from SPI-NOR, it can only boot from eMMC or UFS. Here we emulates the eMMC boot using SPI controller. AP tranmits on CMD line, and eMMC replies on DAT0 line. eMMC boot operation looks a lot like SPI: CMD is unidirectional MOSI, DAT is unidirectional MISO. CLK is driven by the master. However, there is no chip-select, and the clock is active for a long time before any command is sent on the CMD line. From SPI perspective, this looks like a lot of '1' are being sent from the master. To catch the commands, we setup DMA to write the data into a circular buffer (in_msg), and monitor for a falling edge on CMD (emmc_cmd_interrupt). Once an interrupt is received, we scan the circular buffer, in reverse, to be as fast as possible and minimize chances of missing the command. We then figure out the bit-wise command alignment, decode it, and, upon receiving BOOT_INITIATION command, setup DMA to respond with the data on the DAT line. The data in bootblock_data.h is preprocessed to include necessary eMMC headers: acknowledge boot mode, start of block, CRC, end of block, etc. The host can only slow down transfer by stopping the clock, which is compatible with SPI. In some cases (e.g. if the BootROM expects data over 8 lanes instead of 1), the BootROM will quickly interrupt the transfer with an IDLE command. In this case we interrupt the transfer, and the BootROM will try again. BRANCH=None BUG=b:110907438 TEST=make BOARD=kukui BOOTBLOCK=abc -j # check build pass Change-Id: I0f1f2d35c525c6475d90fca2cd6e97f87cd747cc Signed-off-by: Yilun Lin <yllin@google.com> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1126579 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* DragonEgg: Add misc pins section to gpio.incScott Collyer2018-07-111-26/+56
| | | | | | | | | | | | | | | | | This CL adds pins to gpio.inc for those signals in the MISC section of the schematic. BRANCH=none BUG=b:110880394 TEST=make buildall Change-Id: I705b4dc5914bb7d174d2c1e7fc68bcea86b4c926 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1119236 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* octopus: Move board_hibernate delay for TCPC low power modeScott Collyer2018-07-111-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | board_hibernate() may need to access the TCPCs, which in turn will cause the TCPCs to exit low power mode. If the EC is then put into hibernate, then the TCPC is left in normal mode. This CL moves a msleep call which was already there to happen after all possible TCPC accesses. The timer was also changed from 100 to 200 msec to ensure enough time for the low power mode operation to complete. Measuring using a logic analyzer showed that this took ~100 msec to complete. BUG=b:78242079 BRANCH=none TEST=Manual using dut-control pp3300_pd_a_mw -z 100 -t 300 to measure the PD power rail, verified that the power level did not increase when 'hibernate' command was issued on the EC console. In addition, using the logic analyzer verified that I2CIDLE command is written to both TCPCs during the msleep delay. Change-Id: Iec48c78c6d643b0bbf5a82943e0a99c5cbff4575 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1134039 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Tested-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.corp-partner.google.com> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.corp-partner.google.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* yorp: Enable tablet modeFurquan Shaikh2018-07-111-0/+3
| | | | | | | | | | | | | | | BUG=b:111264961 BRANCH=None TEST=Verified that Chrome enables auto-rotation when lid angle is >180. Change-Id: I05b14214c8efb02dcd6168b3aff08317e8ddcd30 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1132686 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* charge_manager: allow finding supply with VOLT > 0 and CUR = 0Fabien Parent2018-07-111-2/+1
| | | | | | | | | | | | | | | | | | | | On Fizz if we boot from type-C and later on plug the BJ, the BJ available current is set to a non-zero value but the current is set to 0. Because of this it is impossible to detect at runtime by the kernel that the BJ has been plugged in. This commit is allowing to find power supply information even when the current is equal to 0 as long as the voltage is > 0. The priority will still be lower than if PWR > 0. BUG=chromium:841944 BRANCH=none TEST=Checked that the kernel can see when the BJ is connected. Change-Id: I7342829aa3429102d8452e9d2beba38d1701027f Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-on: https://chromium-review.googlesource.com/1046594 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* acpi: Return 0 for tablet mode if EC has no device orientationFurquan Shaikh2018-07-111-2/+4
| | | | | | | | | | | | | | | | | | | | | This change returns 0 for EC_ACPI_MEM_DEVICE_ORIENTATION if CONFIG_DPTF_DEVICE_ORIENTATION is not selected. This ensures that EC returns 0 for tablet mode since it does not know anything about device orientation. Returning 0xff can result in AP thinking that tablet mode is enabled since bit 0 is set indicating tablet mode. BUG=b:111264961 BRANCH=None TEST=Verified that on yorp input devices are not inhibited anymore with TBMC device enabled in coreboot. Change-Id: I69ec047813bf456e6ac81b1e1b10cd18b23250e4 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1132611 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* phaser: Enable EC_RST_ODL as wake source from PSL hibernate modeFurquan Shaikh2018-07-111-4/+24
| | | | | | | | | | | | | | | | | | | | | | This change enables EC_RST_ODL as wake source from PSL hibernate mode. Since EC_RST_ODL does not need to be an interrupt during normal EC operation, it is configured as GPIO_INPUT with wake on low-to-high transition flag set to allow PSL common code to configure the input pin correctly before going into PSL mode. CQ-DEPEND=CL:1130853 BUG=b:109759558 BRANCH=None TEST=Verified that phaser wakes up from PSL hibernate by toggling EC_RST_ODL. Change-Id: I0617eee154cabce946b6e9694f5d6f3a155027b2 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1130934 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* baseboard/octopus: Add EC_RST_ODL as a wake source from PSLFurquan Shaikh2018-07-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | EC_RST_ODL needs to act as a wake source from PSL hibernate so that H1/servo can wake EC up from this mode by toggling the signal. Since the wake signals for PSL go to PSL_IN inputs for NPCX variants, EC_RST_ODL needs to be added to the list of hibernate_wake_pins so that the chip code can configure the input correctly. This wake signal is not required if chip variant is not NPCX or PSL is not being used. CQ-DEPEND=CL:1130934 BUG=b:109759558 BRANCH=None TEST=Verified that wake from EC_RST_ODL works as expected on phaser. Change-Id: If26b8a3d25797c015541a54a1fb18c1ab6d93b22 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1130853 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* it83xx: IT8320 DX version compatibilityDino Li2018-07-116-49/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [espi]: The supported maximum frequency of slave is adjustable and we set it at 66MHz at initialization (the same as Bx version). [gpio]: All GPIOs support interrupt on rising, falling, and either edge. More GPIOs support 1.8v input. [irq]: Enable newly added interrupts. [registers]: Remove unused declaration. [system]: Watchdog reset supports resetting the full EC domain function (include write protect setting). BUG=none BRANCH=none TEST=[espi]: Ensure the eSPI frequency is able to work at 50 MHz on small core CPU. [gpio]: The settings of input voltage 1.8v selection and both edge interrupt registers are matched to the declarations of GPIO signal in gpio.inc. [system]: The console command "reboot hard" is able to unprotected the flash. (testing failed) Change-Id: I053d8a59a9e90d28e2f2c9b79675ea84425f4959 Signed-off-by: Dino Li <Dino.Li@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1113166 Reviewed-by: Jett Rink <jettrink@chromium.org>
* kukui: Add LED behavior.Yilun Lin2018-07-111-4/+62
| | | | | | | | | | | | | | | | | | | Add simple LED rules. Charge: red Discharge under 10 percent: blink red Full: green Idle: red or green breath. BUG=b:80160408 TEST=none BRANCH=none Change-Id: I1d3a75dadb92e0dbf617a132990e3a0c4da66461 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1126748 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* charger/mt6370: Support RGB LED.Yilun Lin2018-07-112-0/+156
| | | | | | | | | | | | | TEST=test on EVB, and checks the led blinks accordingly. BUG=b:80160408 BRANCH=none Change-Id: Id0a06f51fd6369daa42e080af5e705321b93c732 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1132723 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* it83xx: disable ROM codestabilize-10866.BDino Li2018-07-101-0/+5
| | | | | | | | | | | | | | | | | | We dont need to use ROM code in the codebase. DX with 512KB flash space has an overlapping issue with the ROM code (0x70000 ~ 0x7ffff). This patch is to disable ROM code so we can properly use the 512KB flash space. BUG=none BRANCH=none TEST=Run console command "md .b 0x70000 256" on 512KB part, and the result is from flash instead of ROM code. Signed-off-by: Dino Li <Dino.Li@ite.com.tw> Change-Id: I9ad5cec44ec36b0f545324655c964bfe31f5a43f Reviewed-on: https://chromium-review.googlesource.com/1131014 Reviewed-by: Jett Rink <jettrink@chromium.org>
* stm32h7: Add support for TRNGNicolas Boichat2018-07-103-1/+50
| | | | | | | | | | | | | | | | | | | | | | | STM32H7 contains a True Random Number Generator. Add support for that. We source rng_clk from HSI48 oscillator (confusingly misspelled hsi8_clk in RM), and fine-tune number of tries to make sure we wait long enough for a random number, no matter the CPU speed (64 or 400 MHz). We also add a console command to test the random number generator (disabled by default). BRANCH=none BUG=b:111190988 TEST=reboot; clock pll; rand => works. TEST=reboot; rand => works. Change-Id: I45624ff4df30b6a332226245e02e3e435b9b15bf Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1128785 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* rollback: Ensure rollback_update writes blocks of correct sizeNicolas Boichat2018-07-101-11/+22
| | | | | | | | | | | | | | | flash_write (rightfully) fails if the size of not a multiple of CONFIG_FLASH_WRITE_SIZE. BRANCH=none BUG=b:111190988 TEST=rollbackupdate works on both whiskers and nocturne_fp Change-Id: I8e0b1f59b06d33f4171b6e09af94a5b7a60acc61 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1127803 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Louis Collard <louiscollard@chromium.org>
* rollback: Fix compile warning when local entropy is disabled.Nicolas Boichat2018-07-101-0/+2
| | | | | | | | | | | BRANCH=none BUG=b:111190988 TEST=make buildall -j Change-Id: I9cea8ce0270ca8a3f4fd33663d78d7d7c5b93643 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1128784 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Nami: Enable temperature contorl by fanDaisuke Nojiri2018-07-102-4/+99
| | | | | | | | | | | | | | | | | | | This enables temperature control by a fan. When the OS is running, the fan speed is controlled by DPTF. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b:111195564,b:77305963,b:80174676,b:110127818 BRANCH=none TEST=Verify fan speed is controlled as temperature goes up and system is shut down on Sona & Vayne. Change-Id: I2e5b19e9ede6210cbfbfc4f295ba8e17872113dc Reviewed-on: https://chromium-review.googlesource.com/1120851 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Raymond Chou <raymond_chou@compal.corp-partner.google.com>
* fpsensor: put the sensor in low power mode when not usedVincent Palatin2018-07-101-0/+4
| | | | | | | | | | | | | | | | | | | | Ensure we always put back the sensor in its lowest power mode when we are no longer waiting for an event from it (e.g. finger detection). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=poppy BUG=b:110498334 TEST=On ZerbleBarn, measure the power consumption with 'dut-control pp1800_fpc_ma' and verify it stays even after running fpcapture/fpenroll/fpmatch console or host commands. TEST=On Meowth, verify that enrollment and unlock-on-match still work. Change-Id: Iad2950d7ed15c536b9f2adff3e1f3df6b92c8d2c Reviewed-on: https://chromium-review.googlesource.com/1125062 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* npcx: Enable PWM when starting to spin fansDaisuke Nojiri2018-07-101-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the EC disables PWM for the fan with PWM=0 but it doesn't enable PWM when PWM goes up. This patch ensures the corresponding PWM channel is enabled when the EC starts spinnning a fan. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b:109951096 BRANCH=none TEST=Verify the followings on Teemo: 1. Fan stops when RPM=0 2. Fan starts spinning when RPM goes up from 0 3. Fan stops when entering S3/S5 4. Fan starts spinning when leaving S3. Change-Id: I49654df81953dc22eb1e6f34cb6534886fee6343 Reviewed-on: https://chromium-review.googlesource.com/1096547 Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1128051 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* phaser: Enable PSLFurquan Shaikh2018-07-102-0/+8
| | | | | | | | | | | | | | | | | | | This change enables PSL for phaser board by: 1. Selecting CONFIG_HIBERNATE_PSL 2. Configuring alternate functions for PSL_IN pins to allow wakeup from PSL hibernate BUG=b:109759558 BRANCH=None TEST=None Change-Id: I5747d4b0408e76eb234ccd6160ea7df36a765e7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1127454 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* meowth_fp: flash_fp_mpu: Make sure WP is deassertedNicolas Boichat2018-07-091-0/+5
| | | | | | | | | | | BRANCH=none BUG=none TEST=flash_fp_mcu complains if WP is asserted Change-Id: I2a84e568fdd54636c357857c4e70be45557635cb Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1128783 Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* flash-stm32h7: Fix protect_blocksNicolas Boichat2018-07-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting the bit to 0 (not 1) protects the block. BRANCH=none BUG=b:111190988 TEST=Follow these steps: host> dut-control fw_wp_state:force_off dut> bash flash_fp_mcu ec.bin EC> flashinfo Flags: Protected now: ........ ........ Flash is indeed not protected: EC> flasherase 0x40000 0x20000 Erasing 131072 bytes at 0x40000... EC> flashwrite 0x40000 0x100 Writing 256 bytes to 0x40000... EC> flashread 0x40000 0x100 Corrupt RW (else RO will jump to RW and protect all flash): EC> flasherase 0x100000 0x20000 host> dut-control fw_wp_state:force_on EC> flashwp true EC> flashinfo Flags: wp_gpio_asserted ro_at_boot Protected now: ........ ........ EC> reboot EC> flashinfo Flags: wp_gpio_asserted ro_at_boot ro_now Protected now: YYYYYYYY ........ RO flash is indeed protected: EC> flasherase 0x40000 0x20000 fails, but RW is not: EC> flasherase 0x100000 0x20000 succeeds Change-Id: Id1a69f186db3eff5986951cf270661f8e735dcfe Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1127804 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* flash-stm32h7: Fix flash_physical_erase/write at bank boundaryNicolas Boichat2018-07-061-2/+2
| | | | | | | | | | | | | | | | | | | | | For example, if we just want to erase the last block of flash, this would fail: flasherase 0x1e0000 0x20000 As the test would think that the end of the erase operation is in a different bank: ((offset + size) / HWBANK_SIZE != bank) BRANCH=none BUG=b:111190988 TEST=flasherase 0x1e0000 0x20000 works. TEST=flasherase 0xe0000 0x20000 works. TEST=flasherase 0xe0000 0x40000 fails (as expected) Change-Id: I2698efcc3d03d55b32f4e1e305c5be7485358ceb Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1127802 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* flash_fp_mcu: Unlock flash before programming itNicolas Boichat2018-07-061-1/+2
| | | | | | | | | | | | | | | Also, add a short sleep before stm32mon, which seems to make programming more reliable. BRANCH=none BUG=none TEST=bash flash_fp_mcu ec.bin works on first attempt with protected flash. Change-Id: Iccb815186aaa13395eac8efb4e25edb74549ed30 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1127799 Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* fan: Don't enable or disable thermal control on resumeDaisuke Nojiri2018-07-061-5/+4
| | | | | | | | | | | | | | | | | | | We don't need to enable or disable thermal control on the resume path. It should be already enabled by pwm_fan_init on cold boot or by pwm_fan_S3_S5 on warm reboot. If it needs to be disabled, DPTF and host command will do so Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=Verify fan spins as expected on Nami and Fizz. Change-Id: If6e4ecdf328b24cc5ba86dbc3bc2824610fcd340 Reviewed-on: https://chromium-review.googlesource.com/1110485 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* ec-devutils: update pyusb to 1.0.2Nick Sanders2018-07-065-13/+24
| | | | | | | | | | | | | | | | | | | | Pyusb interface has changed yet again. Patch calls to get_string and usb.core.find. Modify ordering of detetch kernel driver and avoid rereferencing endpoints. BRANCH=None BUG=b:110907544 TEST=emerge ec-devutils, run powerlog, usb_console, servo_updater CQ-DEPEND=CL:1119632 Signed-off-by: Nick Sanders <nsanders@chromium.org> Change-Id: I33df474ce3bb57d2e11c9f384ac013b51d210843 Reviewed-on: https://chromium-review.googlesource.com/1125354 Commit-Ready: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* test/pinweaver: Fix clang compilation errorNicolas Boichat2018-07-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When building with clang -Waddress-of-packed-member, it throws a warning: test/pinweaver.c:2032:5: error: taking address of packed member 'data_length' of class or structure 'pw_request_header_t' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member] &buf.request.header.data_length); This is because struct pw_test_data_t is defined as __packed (actually, its members are), which also implies a base alignment of 1 byte. Tell the compiler that the structure must be aligned on a 4-byte boundary, which fixes the issue above. BRANCH=none BUG=chromium:854924 TEST=make buildall -j TEST=make CC=clang CFLAGS_y=-Waddress-of-packed-member run-pinweaver -j Change-Id: I498ff311438303b3f648e370af580075dab613a9 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1111760 Commit-Ready: Allen Webb <allenwebb@google.com> Reviewed-by: Allen Webb <allenwebb@google.com>
* npcx: uart: Add driver support for the second UARTCHLin2018-07-0514-227/+484
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nuvoton NPCX79nxB serie chips include two UART ports. In this CL, we add the driver support for these two UART modules. Develoers can select one of the UART ports as EC console by configuring "CONFIG_CONSOLE_UART" in board.h BRANCH=none BUG=none TEST=No build errors for make buildall. TEST="#define CONFIG_CONSOLE_UART 0"; build and flash image on npcx7 EVB; check EC console working via J21. TEST="#define CONFIG_CONSOLE_UART 1"; build and flash image on npcx7 EVB; check EC console working via J22. (Note: J16.3-J16.5 and JP6.2-JP6.3 must be connected together.) TEST=build images of board npcx_evb, poppy, and grunt, make sure EC console is functional on these boards. TEST=#define "CONFIG_CONSOLE_UART 0" and "CONFIG_UART_PAD_SWITCH" in board.h; build and flash image on npcx7_evb. check uart_alt_pad_read_write function still works by using the console command like: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/659460/1/board/poppy/board.c Change-Id: I7de91680e5d4f56c7cae66482c0953d8c324dbe7 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1113269 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* phaser: enable lid angle tablet modePaul Ma2018-07-052-0/+7
| | | | | | | | | | | | | | | | | | This enable lid angle tablet mode for phaser 360(S). BRANCH=none BUG=b:111078678 TEST=Boot phaser 360, use evtest to see the event of "Tablet Mode Switch" device. When lid angle > 300, tablet mode should be enabled; When lid angle < 240, tablet mode should be disabled. CQ-DEPEND=CL:1125261 Change-Id: I8caa1fe8c76346612093f56a2f9f1db8c8f14e03 Signed-off-by: Paul Ma <magf@bitland.corp-partner.google.com> Reviewed-on: https://chromium-review.googlesource.com/1126682 Reviewed-by: Peichao Li <peichao.wang@bitland.corp-partner.google.com> Reviewed-by: Chao Ding <chao.ding@bitland.corp-partner.google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org>
* meowth_fp: Update SPIID for nocturneNicolas Boichat2018-07-051-3/+6
| | | | | | | | | | | | | On nocturne, the FP controller device name is spi-PRP0001:02. BRANCH=none BUG=b:111144409 TEST=flash_fp_mcu ec.bin Change-Id: Ie356bc824248e8a629a4317d5e40483e5bae4185 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1126582 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* phaser: Enable DPTF and orientationJustin TerAvest2018-07-041-0/+3
| | | | | | | | | | | | | | | | | | These are required for the EC to correctly report tablet mode changes to the SoC. BUG=b:111078678 TEST=With coreboot change, tablet mode detected by evtest and powerd BRANCH=none Change-Id: I8882873b884fe8be755675151e3992a30a4cb018 Signed-off-by: Justin TerAvest <teravest@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1125261 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Paul Ma <magf@bitland.corp-partner.google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* yorp: Enable DPTFJustin TerAvest2018-07-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change enables DPTF on Yorp. This change is being performed specifically for yorp instead of baseboard so that it can be slowly rolled out as we determine DPTF settings. Here are messages I see on the EC console after enabling this patch: [29.268649 DPTF sensor 0, threshold -73 C, index 0, disabled] [29.269531 DPTF sensor 0, threshold -73 C, index 1, disabled] [29.271917 DPTF sensor 1, threshold -73 C, index 0, disabled] [29.272803 DPTF sensor 1, threshold -73 C, index 1, disabled] [29.274852 DPTF sensor 2, threshold -73 C, index 0, disabled] [29.275736 DPTF sensor 2, threshold -73 C, index 1, disabled] [29.370718 DPTF sensor 2, threshold 120 C, index 0, enabled] [29.375691 DPTF sensor 2, threshold 90 C, index 1, enabled] [29.379107 DPTF sensor 2, threshold 120 C, index 0, enabled] [29.381799 DPTF sensor 2, threshold 62 C, index 1, enabled] [29.389872 DPTF sensor 1, threshold 120 C, index 0, enabled] [29.393946 DPTF sensor 1, threshold 90 C, index 1, enabled] [29.400152 DPTF sensor 1, threshold 120 C, index 0, enabled] [29.404406 DPTF sensor 1, threshold 48 C, index 1, enabled] [29.414159 DPTF sensor 0, threshold 120 C, index 0, enabled] [29.417368 DPTF sensor 0, threshold 125 C, index 1, enabled] [29.422578 DPTF sensor 0, threshold 120 C, index 0, enabled] [29.425361 DPTF sensor 0, threshold 120 C, index 1, enabled] BRANCH=None BUG=b:80145756 TEST=Enabled DPTF, rebooted Yorp Change-Id: I859df5ad981ea644ab2317e96bf0b559a25efed3 Signed-off-by: Justin TerAvest <teravest@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1121200 Reviewed-by: Jett Rink <jettrink@chromium.org>
* driver: Add driver header for it8300 I/O port controllerVijay Hiremath2018-07-041-0/+106
| | | | | | | | | | | | | BUG=b:111107786 BRANCH=none TEST=Manually tested on GLKRVP using ITE eval board, i2cxfer works Change-Id: I74055a1138516e1364779fbb0758251c70792c3d Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/1123216 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* whiskers touchpad: adjust value rangeWei-Han Chen2018-07-042-5/+7
| | | | | | | | | | | | | | | | | | | | | | | 1. In usb_hid_touchpad.h, `pressure` is defined as unsigned:10, while in touchpad_st.h, `z` is defined as unsigned:8, scale it up to match size of `pressure`. 3. Scale up `width` and `height` for similar reason. 2. Update physical dimension, so it match the real device. With this change, I can use EC touchpad on my Linux machine. BRANCH=none BUG=b:70482333 TEST=tested on Linux Signed-off-by: Wei-Han Chen <stimim@chromium.org> Change-Id: I651f2345ea48c7c9ed495e9684b762bde167092e Reviewed-on: https://chromium-review.googlesource.com/1125652 Commit-Ready: Wei-Han Chen <stimim@chromium.org> Tested-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* usb_hid_touchpad.c: change report_desc to USAGE(touch pad)Wei-Han Chen2018-07-041-1/+1
| | | | | | | | | | | | | BRANCH=none BUG=b:70482333 TEST=tested on device Signed-off-by: Wei-Han Chen <stimim@chromium.org> Change-Id: Ifc1ece2de00979e171f0a29226d927da3951515e Reviewed-on: https://chromium-review.googlesource.com/1124267 Commit-Ready: Wei-Han Chen <stimim@chromium.org> Tested-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: fix build errorZhuohao Lee2018-07-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch is used to fix the below build error: power/mt8183.c:92:6: error: redefinition of chipset_force_shutdown void chipset_force_shutdown(void) ^ In file included from power/mt8183.c:9:0: include/chipset.h:105:20: note: previous definition of chipset_force_shutdown was here static inline void chipset_force_shutdown(void) { } ^ power/mt8183.c: In function chipset_force_shutdown: power/mt8183.c:94:10: error: CC_CHIPSET undeclared (first use in this function) CPRINTS("%s()", __func__); ... BRANCH=master BUG=b:80159522 TEST=make -j12 BOARD=kukui tests Change-Id: I70e879d11a4f34d785b932893d3e847248b99fde Signed-off-by: Zhuohao Lee <zhuohao@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1125640 Reviewed-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* USB PD: Don't restore the default power state.Aseda Aboagye2018-07-041-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Now, the PD state machine will try and issue a Soft Reset if the port was previously in an explicit contract prior to the EC resetting. However, there was a bug where the state machine would actually restore the default power role instead of the actual power role that was stored in in battery-backed RAM. This commit fixes that bug by simply setting the default power role if and only if it hasn't been set already by going down the Soft Reset code path. BUG=None BRANCH=None TEST=flash nocturne, verify that soft reset path works. Change-Id: Ia2baeda2674c6febf4c8c04496a131698099dcdc Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1117368 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
View Lorry Controller Status