The ioctl return status for CROS_EC_DEV_IOCXCMD is inconsistent across
kernel versions:
- In 3.8 kernel, on INVALID_VERSION EC result, -EBADMSG is returned
- In 3.14 kernel, on INVALID_VERSION EC result, success status is
returned
In both cases, the INVALID_VERSION result is written to the
cros_ec_command.result parameter.
The inconsistency here should be fixed with kernel patches. In any case,
there is little harm with trying v0 of GET_VERSIONS on any failure of the v1
command.
BUG=chrome-os-partner:37668,chromium:466896
TEST=Manual on peppy. Verify 'ectool thermalget 0 0' prints threshold info.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic1eb3f8f2fa95711ec15a5afb740af8f18b88b55
Reviewed-on: https://chromium-review.googlesource.com/260004
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Bill Richardson <wfrichar@chromium.org>
Trybot-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Modified version of /board/fruitpie.
Attempted to capture GPIO definitions. Other changes
consisted of modifying functions to enable compilation.
No real functionality as of yet.
TEST=Serial console and I2C functions have been verified
BUG=chrome-os-partner:37078
BRANCH=samus
Change-Id: Iedfc724a058e4220176193ef0f66e5bf45eabbd9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252426
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
- battery firmware filename need match with gs:// filename
- changed from "%04X" to "%04x"
- A fix for LGC battery firmware update.
- Add control flags:
F_AC_PRESENT - 1 iff AC is connected.
F_VERSION_CHECK - 1 if do version check
- option to disk version check for stress test.
- Add detail log messages
- Remove old debug flag.
BUG=chrome-os-partner:36310
BRANCH=none
TEST=run ec_sb_firmware_update on glimmer
Change-Id: Iebc15222a7a55a786291ce2d8931e70acc5b3c4d
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253970
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a new supplier type for VBUS chargers (USB chargers which supply VBUS
but are not identified as another charger type).
BUG=chrome-os-partner:37168
TEST=Manual on Samus with subsequent kernel commit. Modify code to
reject all non-VBUS suppliers, charge with SDP port, and verify charge
icon appears in OS.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fbdb1cb57bd0224b01aaf5a763f93b678b6d204
Reviewed-on: https://chromium-review.googlesource.com/254346
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Up until now, every image includes the time of compilation in the
build information. This makes it impossible to verify that a
particular image came from a particular source code snapshot.
With this change, specifying USE_GIT_DATE=1 to the make command
will use the author date of HEAD as the timestamp. That means
that successive builds from the same source will produce
bitwise-identical output (assuming the same toolchain, of
course).
BUG=none
BRANCH=none
TEST=manual
Do this twice:
\rm -rf build
make BOARD=cr50 USE_GIT_DATE=1
md5sum build/cr50/ec.bin
The md5sum should be the same for both runs.
Change-Id: If64307101a453cb13c62fa003f1bf432f4998273
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252751
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
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>
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>
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>
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>
mcdp_info is a logging payload, so related structures need to be moved
to the public include file.
BUG=chrome-os-partner:35935
TEST=make buildall -j
BRANCH=Samus
Change-Id: Idb939db884821fa85faafbfe643e713f5bcdbc59
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244780
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Current simplified implementation allows single mode entry. Specification
allows multiple mode entry and its advantageous for things like flashing RW
while staying in DisplayPort mode on video dongles.
CL adds capability on DFP to track as many alternate modes as supported by the
DFP. Initial mode entered is still the default supported mode ( 1st entry, 1st
opos). Policy manager can then use host command, EC_CMD_USB_PD_SET_AMODE, to
enter additional supported modes.
On the UFP (hoho, dingdong) a small modification to track multiple svid mode
entries was made.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdsetmode can successfully enter/exit multiple modes.
For example,
# port:1 svid:18d1 opos:1 cmd:1==enter
ectool --name cros_pd pdsetmode 1 0x18d1 1 1
Checking with pdgetmode shows both modes entered.
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. Still drives external display. With bootarg drm.debug=0x6 and following
command: 'tail -f /var/log/messages | grep "Received HPD" &'
I see HPD assert & deassert when switching between GFU and DP mode.
If both modes entered screen stays lit (after reboot) during write.
Change-Id: I7a21ebea377402eb1b0a0cf1d29df59694e301b1
Reviewed-on: https://chromium-review.googlesource.com/241790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Renaming this to 'opos' for consistency with USP-PD specifications
'object position' in VDM header.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35495
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdgetmode pdsetmode can successfully enter/exit
other modes
3. Works across hard & soft resets
Change-Id: I08cb8e003ced4de481adcb503bcba3437ebb1ab7
Reviewed-on: https://chromium-review.googlesource.com/241718
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Adding setup_openocd function to take care of setup of either servo v2 and or
servo v3 setup (setting up OCD_PATH and OCD_CFG variables). Have modified
flash_link, flash_lm4, and flash_npcx functions to use setup_openocd function.
BUG=chromium:412249
BRANCH=None
TEST=made sure that outputted flash_ec command lines prior/after change on host
are identical for link and peppy. Also made sure that flash_ec command
works on peppy with updated image on beaglebone. Also ran "make runtests".
Change-Id: Iacf42fae1f175d6acd08bbd16352afb8f3bd21b0
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242043
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use one line per entry and display the real time for the events.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33248
TEST=ectool --name=cros_pd pdlog
and see a nice log like:
2015-01-20 15:14:02.974 P0 Disconnected
2015-01-20 15:14:05.676 P0 SNK Charger Type-C 4958mV max 5000mV / 500mA
2015-01-20 15:14:11.810 P1 SRC
2015-01-20 15:14:14.460 P0 Disconnected
2015-01-20 15:14:17.277 P0 SNK Charger Type-C 5185mV max 5000mV / 3000mA
2015-01-20 15:14:17.287 P0 SNK Charger PD 5015mV max 20000mV / 3000mA
2015-01-20 15:14:17.383 P0 SNK Charger PD 20198mV max 20000mV / 3000mA
--- END OF LOG ---
Change-Id: Ibf189cdb9e5d9ba74cb1fb241a2945439dfb50f7
Reviewed-on: https://chromium-review.googlesource.com/242082
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
For dual-role USB ports (host/device), let the AP know whether we are
currently DFP (USB host) or UFP (USB device) by exporting the data role
in addition to the power role in the EC_CMD_USB_PD_CONTROL response.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=ectool --name=cros_pd usbpd 0
plug various accessories on the port and see properly "SRC DFP" for the
USB key, "SNK DFP" for the power supply and "SNK UFP" for a regular
C-to-A charging cable.
Change-Id: I292da15fa8cf3566109dd05995ef1d00bed6f92d
Reviewed-on: https://chromium-review.googlesource.com/242012
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Flashing PD devices works through ectool but only when device has
already entered GFU alternate mode. This CL adds ability to force
that entry for devices with default policy engine does not already do
that.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=manual,
1. On hoho flash RW successfully
ectool --name cros_pd flashpd 4 1 hoho.ec.RW.bin
Change-Id: Idd320cf91644f0c1bff87767ab20049d86aa86c6
Reviewed-on: https://chromium-review.googlesource.com/236959
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Add the charging events to the PD event log FIFO
and add an ectool to retrieve/decode them.
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Run `ectool --name cros_pd pdlog`, verify that
all log entries are dumped and the content matches expectation.
BRANCH=Samus
Change-Id: I65dd5696cc0487856ab42aff24134bcdfa1a8219
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238093
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
MIPS host CPU does not access IO registers using a separate address space.
Remove for support of LPC for this host architecture.
Confine x86 function to Intel Architecture only.
BRANCH=none
TEST=Compile: Test on ARM, MIPS and X86: using emerge... ec-utils.
BUG=chromium:443783
Change-Id: I9d4276ec3588037adfcff96e596bbe8be74f22fd
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236687
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the EC controls the lightbar and sets the sequence when
it notices the chipset transitioning between states, we can't
make exceptions for cases where we don't want to activate the
lightbar, such as in dark resume. Instead, let's make it a
separate command that we expect from the kernel.
BUG=chrome-os-partner:32181
TEST=build on samus, verify lightbar does correct thing with
manual control set
BRANCH=ToT
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I5dc619cbbf2498e2ef03ce622831b33e14c7c495
Reviewed-on: https://chromium-review.googlesource.com/239215
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With CL:
5ef45ad pd: Add timeout for HC flash commands.
I thought I'd licked the timeout related issues with flashing dingdong
& hoho.
With further testing however I found I was occassionally hitting the
failure where I couldn't return from 'flash erase' on PD peripheral
prior to the 1 second limit for host command timeout.
That could be remedied by retrying the erase on the host side which
then succeeds quickly. That solution seems non-optimal however.
Additionally, even when erase does succeed in <1sec we have the shared
i2c bus pending. That too is non-optimal.
For those reasons I've decide to return immediately from flash erase
command and instead put the burden of waiting the necessary time on
the host which at least does have some wider perspective on what the
system is attached to and doing.
CL also adds following related changes:
1. corresponding ectool edit to delay 3sec after RW erase.
2. fixup to error returns from hc_remote_flash for timeouts.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=flashing dingdong/hoho via ectool works reliably.
Change-Id: I8fbfb592f760273b26bcb16b67210d569454eee2
Reviewed-on: https://chromium-review.googlesource.com/239253
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
These USB type-C accessories don't have a write-protect GPIO.
Add a configure flag (CONFIG_WP_ALWAYS) to force the flash
write-protection on the dongles.
Also set the read protection (by elevating RDP to level 1),
so trying to unprotect the flash will trigger a full erase.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35088
TEST=boot Hoho,
check the flash OBR and WRPR registers:
"rw 0x4002201c" / "rw 0x40022020"
and the option bytes write-protect bits: "rw 0x1FFFF808"
dump the logical state with "flashinfo" command.
> rw 0x4002201c
read 0x40022020 = 0xffff0002
> rw 0x40022020
read 0x40022020 = 0xffff0000
> rw 0x1FFFF808
read 0x1ffff808 = 0xff00ff00
> flashinfo
Physical: 128 KB
Usable: 128 KB
Write: 2 B (ideal 2 B)
Erase: 2048 B (to 1-bits)
Protect: 4096 B
Flags: wp_gpio_asserted ro_at_boot ro_now
Protected now:
YYYYYYYY YYYYYYYY ........ ........
Change-Id: I45bbc0bce40ecc174b6b8a1ebacf4f53d2fd372d
Reviewed-on: https://chromium-review.googlesource.com/238893
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Currently, 'ectool usbpd' shows PD task state in numerical format. Every
time we add/remove a state, the number changes, and this makes the
command difficult to use. Modify the command to print the name of the PD
task state.
BRANCH=Samus,Ryu
BUG=chrome-os-partner:34296
TEST=Run 'ectool usbpd 0' with different combination of new/old PD
firmware and new/old ectool.
Change-Id: Ic0daa03e9f7565c1322166713c2cce3b7cb93a30
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237623
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
- Correctly identify certain source ports (ex. c-plug to empty a-receptacle)
- Correct ectool power unit print (mV * mA != mW).
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Connect c-plug to empty a-receptacle, run
"ectool --name usbpdpower", verify that port power role is identified
as source. Also, verify that 5000 mV @ 500mA port correctly prints
2500mW total power.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Icf0850afc570a1056578df9f1a647079a00229b3
Reviewed-on: https://chromium-review.googlesource.com/238235
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
We've extended host command range from 8-bit to 16-bit. Extend
EC_CMD_GET_CMD_VERSIONS so that the host may query supported command
versions of the new host commands.
BRANCH=All
BUG=chrome-os-partner:26577
TEST=Extend 'usbpd' to version 1. Test that we can check its version.
TEST=Run 'ectool gpioget' with new ectool and old EC.
TEST=Run 'ectool gpioget' with old ectool and new EC.
Change-Id: I1651aaf21ac2604aea101244b5e53713ead8c1af
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Check the flash protection at startup, if the RDP is still at level 0
(no read protection) or if the RO partition is not write protected :
- set the write protection on the first 16KB of flash (4 LSB of WRP0)
- push the RDP to level 1, so SWD/serial monitor needs to fully erase
the part before re-writing the code or the write-protection.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34935
TEST=dump the content of the option bytes.
Change-Id: I11af64365a6fbc34327b2e463eb8e2d369ffacd2
Reviewed-on: https://chromium-review.googlesource.com/238262
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This addition allows the AP to query whether the PD device is currently
running from RO or RW FW.
BUG=chrome-os-partner:34599
TEST=Manual on Samus. Run 'ectool --name cros_pd infopddev 0' and verify
that correct RO/RW status of Zinger is printed. Verify that the output
matches the index printed by "pd 1 hash" on samus_pd console.
BRANCH=Samus
Change-Id: I4266cae931f5c7855ca0531717c4a18b138b2d62
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236771
Reviewed-by: Alec Berg <alecaberg@chromium.org>
burn_my_ec is an utility that flash an image embedded in its code.
We can not compile it as part of ec-[dev]utils, because we have
devices that firmware should be build as part of chrome-ec package.
Remove burn_my_ec, barely used.
Split the makefile to build just the host utility when requested.
BRANCH=ToT
BUG=chrome-os-partner:32025,chromium:408713
TEST=Check that files are stil built when needed and
not when utils-host is invoked.
Change-Id: I3fabe16067d57c74ae36b05138f4c6fd2483c7c4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233347
CL adds sleep to USB-PD flashing loop in ectool. Real problem is
likely busy waiting within the host command master in the EC which
causes it to starve other lower priority tasks there.
Additionally,
1. Sleep 100ms after reboot to attempt to avoid colliding with other
USB-PD traffic communication that happens when accessories boot.
2. Sleep 100ms after last flash write prior to reboot as there's some
race between finalizing flash write.
Workaround should be removed once we've identified root cause.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33905
TEST=manual,
1. attach zinger to port 1 of samus
2. create ec.RW.bin for zinger and copy to samus
3. update RW fw on zinger via:
ectool --name cros_pd flash_pd 1 1 ec.RW.bin
Result:
- No longer see watchdog fire on samus EC
- See successful update of RW fw on zinger. Takes ~15secs.
Change-Id: If617cbf1c25ee92de94bdb312ec822af2a688640
Reviewed-on: https://chromium-review.googlesource.com/230845
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Add host command to set charge port override.
BUG=chrome-os-partner:32003
BRANCH=Samus
TEST=Manual on Samus. Insert PD charger in port1 and BC1.2 charger in
port0.
./ectool --name=cros_pd chargeoverride 0 --> Charges from port 0
./ectool --name=cros_pd chargeoverride off --> Charges from port 1
./ectool --name=cros_pd chargeoverride dontcharge --> No charge port
./ectool --name=cros_pd chargeoverride 1 --> Charges from port 1
./ectool --name=cros_pd chargeoverride 2 --> Correctly returns error
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib35f797a4a24e96fd2e3c008ace3fd6291b89d25
Reviewed-on: https://chromium-review.googlesource.com/230910
Reviewed-by: Alec Berg <alecaberg@chromium.org>
MOTIONSENSE_CMD_DUMP is deprecated, replaced with MOTIONSENSE_CMD_GET_DATA
Also use vector_3_t instead of x,y,z
ectool motionsense commands only work with newer firmware, to
handle a dynamic number of sensors.
- The host sends the number of sensor it has allocated space for.
- If 0, the EC just sends the number of sensors available
- Otherwise returns sensor information up to the limit imposed by the host.
Remove MOTIONSENSE_GET_STATUS: not needed. It is only useful for LPC,
to guarantee atomicity of the data.
Remove MOTIONSENSE_GET_DATA: not needed since we increase the version
number of MOTIONSENSE command.
BUG=chrome-os-partner:31071,chromium:430792
BRANCH=ToT
TEST=Compile. On a firmware that support the new command:
/usr/sbin/ectool --name=cros_sh motionsense
Motion sensing active
Sensor 0: 92 15 1030
Sensor 1: -94 -63 718
/usr/sbin/ectool --name=cros_sh motionsense active
0
On a machine with older firmware (samus), check these
functions are not working anymore.
Change-Id: I64b62afff96670fb93457760d43d4e64e26e029f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226880
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Factory test process need lid switch no function or keep lid opened
BUG=chrome-os-partner:33304
BRANCH=paine,yuna
TEST=Run command "ectool forcelidopen 1" and "reboot". Then lid close
quickly, the system boot as lid opened.
Deault value or run command "ectool forcelidopen 0" make the device normal.
Change-Id: I94527b7ef7f9efe779c6b86f3eab651f99af6000
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/230180
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-by: Bowgo Tsai <bowgotsai@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
When ec_command fails because of transport issue,
it should returns an error between -1 and -EECRESULT.
If the command fails because of the EC, the error should be less
than -EECRESULT.
Unify all transports to return the error in the same manner.
BRANCH=ToT
BUG=None
TEST=Samus: Check that unsupported command fails with the correct error
number over dev transport.
Qwarks: Check the same command with a 3.10 kernel (no dev transport,
just LPC) fails with the same error code.
Change-Id: I2e43d0cb003d75318b0edd3745e534c700d7d7d8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228295
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow to use larger RSA keys by setting CONFIG_RSA_KEY_SIZE to 4096 or
8192 rather than using the default 2048-bit size.
It's mainly for benchmarking purpose right now as we don't have the RAM
to store the 3x key size buffer and the flash space for the public key
structure.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=build Zinger with CONFIG_RSA_KEY_SIZE equals to 4096 and run it.
Change-Id: I9839121bf158d0a30dde1e48d875f345191bfec2
Reviewed-on: https://chromium-review.googlesource.com/228925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This simply renames ryu to ryu_p1, and ryu_p2 to ryu. 'ryu_p1' will be
kept for a while and will be decommisioned when most developers make
switch to the new boards.
BRANCH=None
BUG=chrome-os-partner:33583
TEST=Build ryu and boot on P2 board.
Change-Id: Ief61c64c6aefdaeae76ac7b86e0ea28131810aa1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229291
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
