once firmware branch exists, this commit need go into it and
doesn't need to be carried in master forever
BRANCH=blaze
BUG=chrome-os-partner:27120
TEST=USE="nyan_blaze" emerge-nyan_blaze chromeos-ec;flash nyan
board, verify ec is alive and version is reported as blaze
Change-Id: I115890a7122440a25c3d1f5e4b94248099a1de99
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/190610
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Add STM32F03x as part of the STM32F0 family.
STM32F031 will be used for devices requiring low-end parts.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=along with the following CLs, run on STM32F051 Discovery with
limited RAM and Flash to mimic STM32F031.
Change-Id: Ie95303eaf00ce53fe7c8d2ac84c19a983aadbf0d
Reviewed-on: https://chromium-review.googlesource.com/189404
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Add support for the STM32F0xx family of devices using a Cortex-M0 core
and slightly newer peripherals than F1xx family.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run EC console on STM32F072B Discovery board.
and pass all available unit-tests on target.
Change-Id: Idaa3fcbf1c0da8a8f448c0e88e58bfd976b0a735
Reviewed-on: https://chromium-review.googlesource.com/188983
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This is needed to calibrate the tmp006 remote sensor values.
BUG=chrome-os-partner:26581
BRANCH=none
TEST='ectool tmp006raw N' works for N=0,1,2,3
And fails with invalid param for N=4.
Data matches result of tmp006 ec console command.
Change-Id: I04ec093c7727b55caca7d02baaf373d1ff234731
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189207
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The EC already provided this information, but ectool wouldn't print it.
BUG=chrome-os-partner:23803
BRANCH=samus
TEST=from ec console, 'fanset 0 3000' and 'fanset 1 1000'
ectool pwmfangetrpm -> prints both fans
ectool pwmfangetrpm all -> prints both fans
ectool pwmfangetrpm 0 -> prints ~3000
ectool pwmfangetrpm 1 -> prints ~1000
Change-Id: I19d3081d09edd42c16bf8b0cdbc48ca58d134027
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187454
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Previously, the AP could only set the current wireless power state.
It couldn't determine what the EC would do in S3, nor could it get the
current wireless power state. Extend the wireless command to do so,
and add an EC console command to aid in debugging.
BUG=chrome-os-partner:25655
BRANCH=rambi
TEST=manual; expected numbers are from EC 'wireless' command
AP off -> 0x0, 0x9
AP on -> 0xd 0x9
AP suspended -> 0x9 0x9
AP on -> 0xd 0x9
ectool wireless 0x1 -> 0x1 0x9
ectool wireless 0xd -> 0xd 0x9
ectool wireless 0 0 0 0 -> 0xd 0x9 (and prints 0xd 0x9 to root shell)
ectool wireless 5 -1 -1 0 -> 0x5 0x9
AP suspended -> 0x1 0x9 (doesn't turn on 0x8, just turns off 0x4)
AP on -> 0xd 0x9
ectool wireless 0 0 0 -1 -> 0xd 0x0
AP suspended -> 0x0 0x0
AP on -> 0xd 0x9
Change-Id: I8ead2d4a4423b51ec4f638bf94c62de98726b25c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187273
This is just an example, demonstrating how a userspace program can access
and control the Pixel lighbar. This change reflects the new unprivileged
access methods. You can run this program to drive the lightbar without being
root.
BUG=chromium:239205
BRANCH=none
TEST=manual
Nothing builds this by default, but you can test it with
cd src/platform/ec
gcc -static util/lbplay.c
then copy a.out to your Pixel and run it (from /tmp, since other directories
are mounted noexec).
Change-Id: I7c07512087c924d16c1c03df6176fba995fcd4f4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186672
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This enforces that "make buildall" runs at least once after the last
file change.
TEST=Try to upload without running "make buildall"
TEST=Change a file without re-running "make buildall", and try to
upload.
BUG=None
BRANCH=None
Change-Id: Ia4abb3c0e17cf4d559975574f398d74c7986c89f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185116
Reviewed-by: Dave Parker <dparker@chromium.org>
LPC mapped memory is not supported for MEC1322. We'll need a separate
communication module. Update comment to reflect this.
BUG=chrome-os-partner:24280
TEST=None
BRANCH=None
Change-Id: I1863c7c230f895cb2cef65459406ffcf1e2b515d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182798
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The main bottleneck on current LPC transfer speed is the delay required
between address write and data read/write. Using auto-increment mode, we
can not only skip most of the delay but also skip repeated address
write.
This gives about 30x speed-up (comparing the time spent on 4096-byte
read test.)
BUG=chrome-os-partner:24107
TEST=Measure speed of 'ectool readtest'
BRANCH=None
Change-Id: Ib34661474b149b19a900c60db884bd474881f742
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182797
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EMI module is the only LPC module suitable for port 80 implementation,
and thus let's move it to 0x80. Consequently the EMI mapped memory is
moved to 0x82-0x87.
BUG=chrome-os-partner:24107
TEST=Write to port 80 and see the data printed to console
BRANCH=None
Change-Id: I7d749650d6d109af2941a1db6e6c4a32e7482f61
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182796
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This includes:
- Remove an unused function argument
- Style fix
- Handle EOF by pexpect instead of catching exception
BUG=chrome-os-partner:19235
TEST=Run all tests
TEST=Make a test crash and check EOF is handled properly
BRANCH=None
Change-Id: I3636cdab6e68cacf97c4b245b14b2d57613a1674
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182049
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Unexpected EOF usually means error in the test code or assertion
failure. In this case, let's treat it as test failure.
BUG=chrome-os-partner:19235
TEST=Check assertion failure fails the test.
BRANCH=None
Change-Id: I9270d223d7252f611673a2c55af0c2d68b6116c4
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181747
Emulator test failures are sometimes hard to debug, especially when the
test is stuck somewhere and times out. Let's have the emulator dump
stack trace when an assertion fails or a test times out.
The produced stack trace is in this format:
#0 build/host/kb_8042/kb_8042.exe() [0x412421]
/home/victoryang/trunk/src/platform/ec/test/kb_8042.c:104
#1 build/host/kb_8042/kb_8042.exe() [0x4124a9]
/home/victoryang/trunk/src/platform/ec/test/kb_8042.c:129
#2 build/host/kb_8042/kb_8042.exe(run_test+0x3a) [0x412e2c]
/home/victoryang/trunk/src/platform/ec/test/kb_8042.c:262
#3 build/host/kb_8042/kb_8042.exe(_run_test+0x11) [0x4061de]
/home/victoryang/trunk/src/platform/ec/core/host/task.c:90
#4 build/host/kb_8042/kb_8042.exe(_task_start_impl+0x79) [0x406b72]
/home/victoryang/trunk/src/platform/ec/core/host/task.c:408
#5 /lib64/libpthread.so.0(+0x70b1) [0x7f6dc2fa10b1]
??:0
#6 /lib64/libc.so.6(clone+0x6d) [0x7f6dc2cd8efd]
??:0
The file name and line number in the trace is generated by addr2line.
BUG=chrome-os-partner:19235 chromium:331548
TEST=Put in a infinite loop in a test, and see stack trace when it times
out.
TEST=Add a failing assertion, and see stack trace when it fails.
BRANCH=None
Change-Id: I4494ffd1ebc98081ce40e860a146202084aa2a1e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181730
Implement LED color policy (crosbug.com/p/23957)
Update battery vendor information (crosbug.com/p/24684)
BUG=chrome-os-partner:24885
BRANCH=rambi
TEST=manual
system on, lidclose -> power LED off
system on, lidopen -> power LED on
system suspended -> power LED blinks green every 2 sec
system suspended, lid closed -> power LED off
system off -> power LED off
plug AC in, battfake 95 -> charging LED green
plug AC in, battfake 94 -> charging LED orange
unplug AC, battfake 10 -> charging LED off
unplug AC, battfake 9 -> charging LED blinks orange
battcutoff -> after a few sec, system powered down
plug back in AC -> system comes back on
charger -> I_in < 1700
Change-Id: I89161e2c024d85197b8612a40a61dd50c106549e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181755
We changed the behavior of indata.size==0 case in cros_ec kernel driver.
This breaks the nyan battery driver. Change the ectool as well.
BUG=chrome-os-partner:24851
BRANCH=nyan
TEST=verified on nyan rev B
% ectool battery
Battery info:
OEM name: SANYO
Model number: AP13J3K
Chemistry : LION
Serial number: 174E
Design capacity: 4030 mAh
Last full charge: 4030 mAh
Design output voltage 11250 mV
Cycle count 0
Present voltage 12934 mV
Present current 0 mA
Remaining capacity 3966 mAh
Flags 0x03 AC_PRESENT BATT_PRESENT
Change-Id: Id63d933802ed85d7f5d8f1c53e6389b083f41a8a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181667
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
By merging make_all.sh to Makefile, parallel make can be made faster.
Previously, if one does 'util/make_all.sh -j32', most of the time is
spent on waiting for linking. Now that we invoke sub-make, linking an
executable doesn't block the next board.
With '-j32', the new 'make buildall' takes about 7 seconds, while the
original 'util/make_all.sh' takes about 27 seconds.
BUG=None
TEST=make buildall -j32
BRANCH=None
Change-Id: I7c2f0d1e928a9b60a8a9070bdcb71b00a3d534cd
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181091
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The igloo board has a different product ID than bds board. Add the new
product ID to ec_uartd.
BUG=chrome-os-partner:24713
TEST=Run ec_uartd with igloo board
BRANCH=None
Change-Id: Idcbb08072661e12ed744a60fb04a55d4f58cf89b
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181082
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
Move the non-core dependent code out of core/$(CORE) directory to
common/ directory.
Put all panic printing code in common/panic_output.c
Put timer management code in common/timer.c
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23574
TEST=./util/make_all.sh
use "crash divzero" and "panicinfo" on Link.
Change-Id: Ia4e1ebc74cd53da55fe24f69e96f39f512b9336d
Reviewed-on: https://chromium-review.googlesource.com/178871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
We are using EMI module instead of LPC memory transaction. This requires
a different protocol for accessing mapped memory from host. For easier
development, let's add a new comm-mec1322.c until we can switch back to
LPC memory transaction.
BUG=chrome-os-partner:24280
TEST=ectool version
TEST=util/make_all.sh
BRANCH=None
Change-Id: Id8914d0413561991d3e46bef7e3fe76c4f8b83e4
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178251
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These boards are unloved and unsupported. They'll never grow up to be
laptops, and hardware is increasingly hard to come by.
Comparable functionality is available in the other, more-loved boards.
Removing these boards speeds up util/make_all.sh by 40%. (If you're
not running that before every upload, you should be...)
BUG=chrome-os-partner:24062
BRANCH=none
TEST=build all remaining platforms and pass unit tests
Change-Id: I4d8a49e4d52d7393471f1b1cbef059c8db4a4f77
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177373
Instead of hardcoding the common files for host utils in the generic
rules, let's declare them in the build.mk file using the same system as
the Linux kernel build.
if a binary "foo" declared in "host-util-bin" or "build-util-bin" has a
matching "foo-objs" variable, it will be build from all objects declared
in "foo-objs" else it uses directly "foo.o" (single source file).
This is preparatory to add new "build" tools sharing common sources.
note: the dependencies on the utils are a bit less fine-grained as a
result of this change, but given the low number of tools, that should be
acceptable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=./util/make_all.sh
Change-Id: Ieffce7ca6f5b685ffb7d1f4626b99aff07b61443
Reviewed-on: https://chromium-review.googlesource.com/176174
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:318342
TEST=Run "ectool boardversion" on device with and without support
for board ID. Note, boards without support will return an error.
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: Ib7599570c84a7ed5cf70ce9d8336467785b35569
Reviewed-on: https://chromium-review.googlesource.com/176543
Added ability to erase and program flash to iteflash.
BRANCH=none
BUG=chrome-os-partner:23576
TEST=generate random 192kB file, write it to the ITE chip, read flash
back and make sure file read in matches file written.
Change-Id: Id525b43e523a3d710ee65b623fec07800cf7f347
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176022
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
QEMU tests served us well, but it has been more and more difficult to
maintain as we now have more chips and use more functionality from each
EC chip. With emulator tests in place to test common code and hardware
test to test per-chip/per-board drivers, it's time to remove QEMU tests
to simplify our code base.
QEMU tests that are covered by other emulator tests are removed
completely; tests that are not covered are left alone for now to
preserve the test logic.
BUG=chrome-os-partner:18343
TEST=util/make_all.sh
BRANCH=None
Change-Id: I5a4dd2f5ac42f7f66f86fdce0b62dbd2c65bf66a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174669
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The EC LPC implementation guarantees that the status byte will have at
least one zero bit, so there's no need to scan the parameter space as
well. Removing this unneeded check will slightly speed up ectool.
BUG=chrome-os-partner:10963
BRANCH=none
TEST=on an x86 chromebook (e.g. link), ectool hello still works
iotools io_read8 0x200 && iotools io_read8 0x204 -> not both 0xff
Change-Id: Ic02ca0ee686ab10e50093807717ec638aaa468c6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174059
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is to add nyan board support:
- new files in board/nyan folder, including battery.c
- new common/chipset_tegra.c, which is mostly based on
chipset_gaia.c
- new include/tegra_power.h
- modified build.mk and flash_ec for nyan
BUG=none
BRANCH=nyan
TEST=tested on Venice 2 board
Change-Id: I36895f34f2f4d144a9440aff358c8274797ebbd6
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/168078
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just does a copy/rename from Bolt. Tweaking for Samus' peculiarities
will come next.
BUG=chrome-os-partner:22870
BRANCH=none
TEST=manual
The only thing we can check is that it compiles:
cd src/platform/ec
make BOARD=samus
Change-Id: Ied95ebdd1137548b21334b4a65a298c68482c517
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the ChipID for the stm32l152c board to stm32mon. Add discovery to the list
of supported boards in flash_ec.
BUG=None
TEST=With modified servo connector, see that image can be loaded onto
stm32l152c discovery board.
BRANCH=none
Change-Id: Ie16c64d17c907f7de765b09de98f534c486ae04c
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This should have all the correct GPIO mappings.
Chipset and charger tasks are currently disabled, until we bring up
the voltage rails and I2C communication.
BUG=chrome-os-partner:22895
BRANCH=none
TEST=compiles; everything else needs to wait until we get hardware
Change-Id: Iea49fe7ab8bd17f61c8cc6c71f236a503418ee28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170540
Reviewed-by: Vic Yang <victoryang@chromium.org>
Having a per-device enum list for use by the EC_CMD_GET_SET_VALUE command
won't work when the one-and-only ectool tries to talk to different devices.
Any particular enum may be missing or have a completely different meaning.
Instead, we can do the same thing that EC_CMD_HOST_EVENT_* does - use the
same structs for a bunch of different commands.
If/when we run out of command numbers (it's currently only 8 bits), we'll
just switch to using EC protocol v3 (see crosbug.com/p/20820), which
provides 16 bits for the command.
This CL renames EC_CMD_GET_SET_VALUE to EC_CMD_GSV_PAUSE_IN_S5 (since that's
the one-and-only use of it at present), and renames the params/response
structs as well. Since only the names are changing, the implementation
remains backwards-compatible (assuming the flags value usage is preserved by
ectool for the EC_CMD_GSV_PAUSE_IN_S5 command, which it is).
If I can cherry-pick this change into the one place where it's being used, I
will.
BUG=chromium:287969
BRANCH=ToT
TEST=manual
Although this is primarily an internal name change, it also means that the
commands to invoke the previous usage of this feature have changed. To test:
On Haswell systems only.
To enable the pause in S5 at shutdown, do either of these:
EC console: pause_in_s5 on
root shell: ectool pause_in_s5 on
Shut the AP down politely, and it should pause in S5 for 10 seconds before
continuing to G3. You can see this by watching the EC console.
To disable the pause in S5 at shutdown, do any of these:
EC console: pause_in_s5 off
root shell: ectool pause_in_s5 off
or
press Refresh + POWER
Boot the system, then politely shut down. This time it should go directly to
G3 without pausing in S5.
Change-Id: Ic614fed37ad89db794c2bbcca2b83d1603030ab2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168816
At normal AP shutdown, Haswell systems skip S5 entirely and go directly to
G3. It's sometimes handy to pause in S5 as the other systems do, for things
like power-cycle tests that use the RTC to do a delayed wake from S5.
This CL adds a console command and a host command to enable/disable that
pause in S5.
The default is to skip S5, and the override value is not persistent across
EC reboots, so whenever the EC hibernates or reboots (Refresh + Power, software
sync), you'll have to re-enable it again.
BUG=chrome-os-partner:22346
BRANCH=falco,ToT
TEST=manual
On Haswell systems only.
To enable the pause in S5 at shutdown, do either of these:
EC console: gsv s5 1
root shell: ectool pause_in_s5 on
Shut the AP down politely, and it should pause in S5 for 10 seconds before
continuing to G3. You can see this by watching the EC console.
To disable the pause in S5 at shutdown, do any of these:
EC console: gsv s5 0
root shell: ectool pause_in_s5 off
or
press Refresh + POWER
Boot the system, then politely shut down. This time it should go directly to
G3 without pausing in S5.
Change-Id: I324e6e2373bc20b61a731b4ef443d7bb8edb6b83
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Most systems don't have a lightbar. Those that do need a way to detect that
one exists. That's easily done by just sending a EC_CMD_LIGHTBAR_CMD command
to the EC and checking the result. If the response is
EC_RES_INVALID_COMMAND, there isn't a lightbar.
But what .cmd value should we use in struct ec_params_lightbar? Future
lightbar implementations (if any), could remove existing functions or add
new ones, so there isn't a safe choice.
This change adds a LIGHTBAR_CMD_VERSION operation to determine if any new
implementation exists. Future systems should return some useful information
in response to this command. Existing systems will return
EC_RES_INVALID_PARAM, which is enough to distinguish them.
BUG=chromium:239205
BRANCH=none
TEST=manual
make BOARD=link
make BOARD=link runtests
There are no user-visible changes in functionality to anything.
Change-Id: Ibe37f74a4dcbf68dd6bfd1963530aec907e67534
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167549
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The flash_ec utility was not honoring --board=bolt. Therefore,
add it to the known variants of flash_slippy.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=flash_ec --board=bolt dosen't fail
Change-Id: I8f9c1ddcf7d40b8b579cd90af7dd5c4d90537084
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66820
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Problems with existing thermal control loop:
* Not multi-board friendly. thermal.c only supports Link and needs
refactoring. Temp thresholds and fan speeds are hard-coded.
* Only the PECI temp is used to determine the fan speed. Other temp sensors
are ignored.
* Has confusing data structures. Values in the CPU temp thresholds array mix
ACPI thresholds with fan step values.
With this change, the thermal task monitors all temp sensors in order to
perform two completely independent functions:
Function one: Determine if the host needs to be throttled by or informed of
any thermal events.
For thermal events, each temp sensor will have three threshold levels.
TEMP_HOST_WARN
* When any sensor goes above this level, host_throttle_cpu(1) will be called
to ask the CPU to slow itself down.
* When all sensors drop below this level, host_throttle_cpu(0) will be called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_HIGH
* When any sensor goes above this level, chipset_throttle_cpu(1) will be
called to slow the CPU down whether it wants to or not.
* When all sensors drop below this level, chipset_throttle_cpu(0) will be
called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_SHUTDOWN
* When any sensor is above this level, chipset_force_shutdown() will be
called to halt the CPU.
* Nothing turns the CPU back on again - the user just has to wait for things
to cool off. Pressing the power button too soon will just trigger shutdown
again as soon as the EC can read the host temp.
Function two: Determine the amount of fan cooling needed
For fan cooling, each temp sensor will have two levels.
TEMP_FAN_OFF
* At or below this temperature, no active cooling is needed.
TEMP_FAN_MAX
* At or above this temperature, active cooling should be running at maximum.
The highest level of all temp sensors will be used to request the amount of
active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to
convert the amount of cooling to the target fan RPM.
The default pwm_fan_percent_to_rpm() function converts smoothly between the
configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages
between 1 and 100. 0% means "off".
The default function probably provide the smoothest and quietest behavior,
but individual boards can provide their own pwm_fan_percent_to_rpm() to
implement whatever curves, hysteresis, feedback, or other hackery they wish.
BUG=chrome-os-partner:20805
BRANCH=none
TEST=manual
Compile-time test with
make BOARD=falco runtests
On the EC console, the existing fan commands should work correctly:
faninfo - display the fan state
fanduty NUM - force the fan PWM to the specified percentage (0-100)
fanset RPM - force the fan to the specified RPM
fanset NUM% - force the fan to the specified percentage (0-100) between
its configured minimum and maximum speeds from board.h
(CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX)
fanauto - let the EC control the fan automatically
You can test the default pwm_fan_percent_to_rpm() with
fanset 1%
faninfo
The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it
automatically again with
fanauto
Also on the EC console, the thermal settings can be examined or changed:
> temps
PECI : 327 K = 54 C
ECInternal : 320 K = 47 C
G781Internal : 319 K = 46 C
G781External : 318 K = 45 C
>
> thermalget
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 0 0 G781Internal
3 0 0 0 0 0 G781External
>
> help thermalset
Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]]
set thermal parameters (-1 to skip)
>
> thermalset 2 -1 -1 999
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 999 0 0 G781Internal
3 0 0 0 0 0 G781External
>
From the host, ectool can be used to get and set these parameters with
nearly identical commands:
ectool thermalget
ectool thermalset 2 -1 -1 999
Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66688
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This allows stm32mon built in kirby build directory to be used to flash EC.
BUG=chrome-os-partner:21964
TEST=util/flash_ec --board=kirby --image=build/kirby/ec.bin
BRANCH=None
Change-Id: I38ab6de0e129996010974c8766e1f84f4e8eb3a7
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66005
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Firmware development for this board is happening on the
firmware-wolf-4389.24.B branch.
BUG=chrome-os-partner:21815
BRANCH=None
TEST=Run util/make_all.sh. Verify all is made.
Change-Id: I4b58a982a87562231453f3f201024b809c6a24fb
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65514
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When running certain ectool commands, our ioctl may succeed, yet our
command may not be successful for a variety of reasons (see ec_status
enum). In this case, we should return a non-success exit code so that we
can easily detect such failures in scripts.
BUG=chrome-os-partner:21171.
TEST=Pass FAFT suite on Peppy. Pass factory tests on Peppy.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia33b8285fb048b256f0668b709573e86c15f1162
Reviewed-on: https://gerrit.chromium.org/gerrit/64686
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Glue between the existing ectool led command and the
led control logic.
BUG=chrome-os-partner:20776
BRANCH=peppy
TEST=Manual. Run "ectool led" commands:
Should pass:
ectool led power blue|yellow|off|auto|blue=1 yellow=1
ectool led battery blue|yellow|off|auto|blue=1 yellow=1
Should fail:
ectool led adapter <color>
ectool led power|battery red|green|white
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I2540940baa553866760dd9ae62278b6b845793ef
Reviewed-on: https://gerrit.chromium.org/gerrit/64627
This would allow us to do something like:
util/make_all.sh -j32
util/make_all.sh V=1
BUG=None
TEST=util/make_all.sh -j
TEST=util/make_all.sh V=1
BRANCH=None
Change-Id: Ifed0baf6c94fbe8b0296cbdc70ba84f92f04b75b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64268
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
