Previously they reported on the system channel, not the hostcmd channel.
BUG=none
BRANCH=none (affects all platforms, but only affects use of 'chan' ec console command)
TEST=manual
- chan 0x40
- x86reset
- should see HC debug output.
Change-Id: Ie9873db015c94a0198a94ebafad87d51b0f73620
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35953
Reviewed-by: Simon Glass <sjg@chromium.org>
This makes the timing for the S3 low-power indicator adjustable without
reflashing.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Boot, log in, run this to put the lightbar into demo mode:
ectool lightbar demo 1
ectool lightbar seq s3s0
The lightbar should act as though the system is asleep.
Then press the left arrow a couple of times and the down-arrow four or five
times. You should see the red light pulse every 5 seconds or so.
Now run
ectool lightbar params > /tmp/w
Edit /tmp/w to change the timing lines to this:
100 # .s3_ramp_up
100 # .s3_ramp_down
Then run
ectool lightbar params /tmp/w
After a cycle or two, you should see the lightbar flash instead of pulse.
Change-Id: If815ff2fb9a158c0e1f4dbb6a269ad07e122d84c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35839
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The charging voltage and current are not necessary zero. Remove the
conditions.
BUG=chrome-os-partner:14094
TEST=Remove the battery with AC connected. LED turns red after 30
seconds.
Plug in AC with battery disconnected. LED turns red after 30 seconds.
BRANCH=link
Change-Id: I754383b05af6de0ceeb706612f1cb534254e47e3
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35807
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This is hopefully the finally final tweak to the lightbar behavior. It does
this:
* When booting or awakening from sleep, Google colors pulse briefly.
* When the chromebook is fully on, lightbar is dim blue. Every 3-5 seconds,
a pulse of brighter blue sweeps across.
* On battery, the lightbar is not quite as bright, and the sweep goes in the
other direction and is slightly slower. If the battery charge drops below
10%, the lightbar changes from blue to red (but only on battery, not AC).
* When going to sleep (close lid while logged in), lightbar fades to black,
then pulses Google colors, then off.
* While asleep, lightbar does nothing, UNLESS on battery and battery charge
is under 10%. Then it pulses red every 5-8 seconds.
* When shutting off, it just goes black with no special effects.
Other than the slight dimming on battery power, there is no ambient light or
dynamic brightness control.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Turn it on, watch the blinky lights. Log in, close the lid, open the lid.
Connect/disconnect AC. The lights should change as described above. Ta Da.
Change-Id: Id174a452639decc4b5eefb9e21b28cf3643529f5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35742
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I introduced a glitch in the parameterization CL. This fixes it, and makes
the choice between the gentle throbbing and occasional pulse something that
can be selected as a parameter. Default is the new pulsey style.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Using the ectool that's part of this change, run these commands to flip
between suspend and active displays:
ectool lightbar seq s3s0
ectool lightbar seq s0s3
Change the "new_s0" value (0/1) and reload the params with
ectool lightbar params | tee /tmp/w
vi /tmp/w
ectool lightbar params /tmp/w
In each case you'll see some pretty patterns. Pass/Fail is an artistic
decision. No QA required.
Change-Id: I8de0b1b3cc77f65879befe95e110bbbce18846d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35620
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, any command which set the fan duty manually would leave
the PWM RPM controller disabled. Setting the fan back to auto mode
via 'ectool autofanctrl' or 'autofan' or 'ectool pwmsetfanrpm'
wouldn't turn the controller back on. Now it does.
BUG=chrome-os-partner:14307
BRANCH=link
TEST=manual
- Reboot in recovery mode and wait for INSERT screen
- From EC console
fanduty 100 -> fan turns on all the way
faninfo -> mode is duty
fanset 6000 -> fan turns down to a lower level
faninfo -> mode is rpm
fanduty 0 -> fan turns off all the way
faninfo -> mode is duty
(wait a min or so for the system to heat up)
autofan -> fan turns on
faninfo -> mode is rpm
- Reboot normally
- From root shell
ectool fanduty 100 -> fan turns on all the way
ectool pwmsetfanrpm 6000 -> fan turns down to a lower level
Change-Id: I3b07e8b49500f5f8a42f20909d2869cf63987d6d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35335
Reviewed-by: Sameer Nanda <snanda@chromium.org>
The remote temperature sensors for case temps are now not used until
they're calibrated by the host. But the EC still tries to control the
fan based on case temps. At best this has no effect because the
sensors haven't been enabled by host calibration. At worst, the host
calibrates them, but doesn't set up the temerature thresholds to
match, so the EC spins up the fan briefly during boot before the host
takes over (annoying), or potentially asserts prochot, shuts the
system down, or triggers a bunch of SMIs (really annoying). It's
safer just to leave these thresholds disabled by default; if the host
wants the EC to use them, it can easily set them at the same time it
sets the remote sensor calibration data.
Also, adjust overheated thresholds up based on snanda's recommendations.
BUG=chrome-os-partner:9193
BRANCH=link
TEST=thermalconf 2 --> should print 0 K for all levels
Change-Id: I5bd1ea65eaefc4d39238b22363176d32663434a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35449
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This change replaces most of the hard-coded lightbar constants with values
that can be updated at run-time, so that if we change our minds about colors
and timing we can tweak some of the values without requiring an EC/BIOS
update.
It also adds the "ectool lightbar params" command to get and set those
values from the host. You can see the values from the EC console ("lightbar
params"), but there's no way to set them.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
From the EC console, run
lightbar params
It should display the current values that can be changed.
Log in to the host and run this to see the same values:
ectool lightbar params
Or edit and change them with this:
ectool lightbar params > /tmp/vals.txt
vi /tmp/vals.txt
ectool lightbar params /tmp/vals.txt
The updated parameters are persistent across EC jumps (RO->RW), but are lost
when/if the EC reboots (as it will after the AP is off for 24 hours, for
example).
Change-Id: Ic2a3fd6f8062673432b48904933e0c7239b8658b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35289
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, if the AP took fan control, the EC would never take it
back. This meant the EC would leave the fan off even if the system
was sitting at the INSERT screen or booted an alternate OS.
BUG=chrome-os-partner:15189
BRANCH=link
TEST=manual
- boot system
- from EC console, fanset 0
- faninfo shows fan at 0rpm
- from root shell, crossystem recovery_request=123 && reboot
- wait a few mins
- faninfo should show fan spinning again
Change-Id: I534c9978194085467f1df6eae971c55d4e8083be
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35309
S0 values are incorrect and may even need to be calibrated on a
per-system basis. Set them to 0 by default so that the EC doesn't
return inaccurate remote temperature readings before calibration data
is sent.
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
- temps -> remote temps are all not calibrated
- t6cal 1 s0 9301
- temps -> PCH D-Object temp now returns a temperature
Change-Id: I43facc60cf947ebd9441a8a629a76f7ffc8f3959
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35302
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual, from root shell
- ectool temps all -> prints all temps
- ectool tmp006cal 1 0 0 0 0
- ectool temps all -> sensor 3 not calibrated
Change-Id: I16ee818c948fe90ac7c18b230c5d9f9a0ec83ded
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35288
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the need for a separate method to check sensor power, and
gets rid of temp_sensor.c knowledge of what powers each sensor.
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
- reboot
- within a second, type 'temps'; I2C sensors should return error 1
- type 'temps' again; all sensors should return data
- power off system
- type 'temps' again; I2C sensors and PECI should return error 8
- 'gpioset enable_vs 1'
- type 'temps' again; I2C sensors should return valid data; PECI should still
return error 8.
Change-Id: I17c353b3c483bc320769307c7715008ec729089b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35287
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This will be used in a follow-up CL to return specific error codes
(not powered, not calibrated, etc.)
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
Power on system.
'temps' should return all good temps.
Power off system (into S5)
Only ECInternal temp should work; others should return Error 1
'gpioset enable_vs 1' and wait a second
Now all the I2C temps should display good data, but PECI will still be error 1.
Change-Id: I925434e71653ad53ad76bad992a7a8fdeadb088c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35286
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Note that radix must be specified as an integer, because we don't have
floating-point parsing. So to set the first sensor's S0 to 3.600e-14,
do:
t6cal 0 S0 3600
BUG=chrome-os-partner:14955
BRANCH=link
TEST=manual
From EC console,
t6cal 0 s0 3500
t6cal 1 b0 -3000
t6cal 1 b1 -5600
t6cal 2 b2 4700
t6cal
The final t6cal should show the changes from the previous commands
Change-Id: I2f8f71890e8e64a427cc29c3ef86ca991ce6b039
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35204
1) Use floating-point more freely, since it's on all the time now, and
the old fixed-point code no longer compiled.
2) Sensitivity and Bn values are now in a RAM-based struct in
preparation for setting them at runtime. No changes from current
values.
3) If a sensor fails to read good data, is initialized, or loses
power, its die temperature history will be set to the next good
temperature, rather than persisting an arbitrary start value or old
state. This fixes reading wildly inaccurate object temperatures for
the first few seconds following boot/resume.
4) If a sensor loses power, wait for the sensor to report data-ready
before reading temperature/voltage. Otherwise, those read as 0, which
again throws off the first few seconds of data.
BUG=chrome-os-partner:14955
BRANCH=link
TEST=Boot system and set at login screen for a minute to reach thermal
equilibrium. Then reboot system, type 'temps' repeatedly. Data from
TMP006's should initially be Error; after a second or so it should be
good, and shouldn't change more than a few degrees.
Change-Id: Id0b42b9b18e94978ba7d3a1ee33194e44b1904bc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35188
An earlier commit made the lightbar test sequence run much too quickly. This
puts it back. I'm not sure if the factory still looks at this, but I think
they did at one time, so we might as well keep it working. It's helpful for
debugging anyway.
BUG=chrome-os-partner:8039
BRANCH=link
TEST=manual
Log in, run "ectool lightbar seq test". You should see the lightbar colors
pulse in various colors, then go back to whatever they were doing before.
Change-Id: I11c24a448bf40f0c0c82456fcf6e0415a0392c28
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35190
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Experiments showed that some UVP batteries took ~30 seconds to restart
its gas gauge IC. This change adds 30 seconds polling check to determine
the condition.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=link
BUG=chrome-os-partner:13923
BUG=chrome-os-partner:14094
TEST=manual
Disconnect battery and plug in charger. The charging LED should turn
red after 30 seconds.
Change-Id: I425e63c428aeeaf1468bc2f9886457de1145cada
Reviewed-on: https://gerrit.chromium.org/gerrit/34886
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
We already shut down the main processor below 3%. Hibernating the EC
below 2% will further cut power draw and minimize the risk of
deep-discharging the battery.
BUG=chrome-os-partner:14839
BRANCH=link
TEST=manual
1) discharge battery below 3%; system should shut down. when powered
on again it should shut back down within ~10 sec.
2) discharge battery below 2%; when system shuts down it should also hibernate.
(I've also tested this with a hacked smart_battery.c which lies about
the battery state of charge, since that's faster than waiting for my
battery to discharge.)
Change-Id: I504ba927012430db5cf10b895a36e6cd6fdf4c8b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34793
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This enables the OS to request the EC drop into its lowest-power
shutdown state. Targeted at end of factory flow, where the
at-shutdown variant is the desired variant because it allows the main
processor to shut down cleanly first.
BUG=chrome-os-partner:14838
BRANCH=link
TEST=from root shell,
ectool reboot_ec hibernate at-shutdown
shutdown -h now
System should shut down, and EC console should be unresponsive (since
it's hibernating). Press power button, and system should power back on.
ectool reboot_ec hibernate
System should shut down immediately. Press power button, and system
should power back on.
Change-Id: I8084a3a1bca6b7c201e090552b193fe1568708a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34569
Reviewed-by: Vic Yang <victoryang@chromium.org>
Latest tweaks after working with the UI folks. This changes the S3 and S0
sequences and the transitions between them, using Google colors, smooth
fades, and persistent state across EC resets.
In S3, we only pulse when the battery is low and is discharging.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=none
Artistic criticism only, please.
Change-Id: Id75b8c2c96e2e9dc9ff27af0bfe126cfad5d490e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34465
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tell the host the battery is no longer charging when it hits 97%, and
set the power adapter LED to green.
This solves several problems:
1) The last 3% of charge takes a looong time. Kernel/ACPI/UI already
have a hack to show the battery as charged when it's about 3% from
full, but the EC still showed a yellow LED.
2) If the system is charged and you briefly unplug the adapter, the
LED turned yellow for a long time as it slowly trickle-charged. Now
it goes right to green.
3) A fully-charged battery will drop below 100% charge as it settles,
but won't accept more current at that time. This caused the LED to
turn yellow and stay there until the battery finally settled down to
~96%, at which point it'd accept more current and top itself off. The
whole time it did this, the kernel/ACPI/UI hack from (1) would keep
reporting "battery full". Now the LED stays green too.
BUG=chrome-os-partner:11248
BRANCH=link
TEST=manual
- Discharge system to <95% full.
- Plug adapter in. LED should come on yellow.
- At around 97% full, the LED should turn green.
- Around that the UI will display "battery full".
(Note that due to rounding, the UI may take a few minutes to display
"battery full" after the LED goes green; that's ok)
- Unplug and replug adapter. LED should come on green. UI still reports
"battery full".
Change-Id: Ie56fbf3a05239e73d2c765bb98d36aa5cfedc2ef
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34452
With this CL, if CONFIG_FPU is defined (only for Link, ATM), the EC task
switcher will enable CONTROL.FPCA and expect all stack contexts to include
floating point state as well as normal state (an additional 18 words).
To support this, we need to increase the allocated stack space for each
task. The stack sizes are already chosen empirically, so I'm just rounding
them up a bit.
BUG=chrome-os-partner:14766
BRANCH=Link
TEST=manual
There should be no noticeable change. If you run the EC command "taskinfo"
you'll see the increased size each thread's stack, but everything that was
working before should continue to work just fine.
The additional overhead required to load and store another 18 words on each
context switch is not really measurable (I tried).
Change-Id: Ibaca7d7a2565285f049fda6906f32761e83207af
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34391
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, the charge state machine sets the power LED green the first
time it hits IDLE. This causes the LED to briefly flash green when
the adapter is inserted, because the state machine goes
discharging->init->idle->charging.
Instead, add a new idle0 state in between init and idle which does not
set the power LED. This allows the state machine to go
discharging->init->idle0->charging, so the LED only goes from off->yellow.
If the system is actually fully charged, it'll go init->idle0->idle
and show green.
BUG=chrome-os-partner:14630
BRANCH=link
TEST=manual
- Remove adapter and allow system to discharge a bit
- Insert adapter
- Should see LED go from off directly to yellow
- Wait for charge
- Should see LED go green
Change-Id: I9b77f01fad27c8574133211c9fe250486609f3c1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34387
Reviewed-by: Rong Chang <rongchang@chromium.org>
Previously, ports were only enabled on S5->S3, not S3->S0. Seems like
they should always get re-enabled on resume.
This also consolidates the USB code into a single file, cleans up the
debug output, and prints the current USB charge state when the
usbchargemode command is run without args.
BUG=chrome-os-partner:12904
BRANCH=link
TEST=manual
- Boot system
- At ec console, 'usb' should print port 0 and 1 are in mode 1.
- At a root shell, 'ectool chargemode 0 0'
- At a root shell, 'ectool chargemode 1 0'
- Suspend system
- At ec console, 'usb' should print port are in mode 0.
- Resume system
- At ec console, 'usb' should print port 0 and 1 are in mode 1.
Change-Id: I3875a104338fb64db503929a018b8577d6f970e4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34062
Reviewed-by: Vic Yang <victoryang@chromium.org>
1) Only send the host response immediately for commands which won't
return. This prevents double-sending a response for the disable-jump
command.
2) Remove references to the POWER_ON flag. This was never implemented
or used, since with EC software sync the EC always powers on after
rebooting.
3) Fix help text for reboot_ec command. (Both "A" and "RW" still do the
same thing, but "RW" is now the preferred option string.)
BUG=chrome-os-partner:12635
BRANCH=link (also applies to snow, but don't pick unless needed)
TEST=from a root shell,
flashrom -p internal:bus=lpc -r /tmp/ec.bin
flashrom -p internal:bus=lpc -w /tmp/ec.bin
ectool reboot_ec RW
ectool reboot_ec RO
ectool disable-jump
All commands should succeed.
Change-Id: Ibf5b4fb88d93e64fc7361a9f962ec7aa1df0cf3c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34051
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
This reduces power consumption in S3/S5 because the EC doesn't need to
poll the battery every 500ms.
BUG=chrome-os-partner:9676
BRANCH=link
TEST=manual
As much as can be tested with the current debug information:
- Boot system with AC adapter in. Charge state machine should go to
charging state.
- Remove AC adapter. Charge state -> discharging.
- Shut system down.
- Plug AC adapter in. Charge state -> init -> charging over the course of
a few seconds (NOT a minute).
- Remove AC adapter. Charge state -> discharging.
Really good testing requires a source-level change. Hack in a line of
debug output above task_wait_event(sleep_next) in
charge_state_machine_task() which prints how long the charge state
machine is sleeping. It should sleep for ~250ms when charging, ~500ms
when discharging and the system is on, or ~60000ms when discharging
and the system is off. (I did this when writing this change, but
removed it because it clutters up the debug console output.)
Change-Id: I7d3e291fbc40bfcc67d1fb4982d91f0e6bf2e785
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33921
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
This reduces oscillations in the charging algorithm. This change also adds
more debug output so it's easier to see what the charging state machine is
doing.
BUG=chrome-os-partner:9572
BRANCH=link
TEST=discharge battery; charge battery; note infrequent but useful debug output
Change-Id: I4c8609c2ca8a6cab3eae151ecf2bb1520103fece
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33811
Reviewed-by: Rong Chang <rongchang@chromium.org>
Yet another set of tweaks to the lightbar patterns:
At Startup or wake from sleep, Google colors cycle in.
While running, > 25% power level in the battery:
All blue, in a breathing effect (cycle up and down 30%).
While running, <= 25% power level in battery:
Same as above, but with red
Shutting down, or going into sleep:
Cycle out the Google colors (Note: the effect is only visible for S0->S3,
because shutting down kills power to the lightbar before we can react).
While sleeping:
Similar to now, but only using Blue and red for battery indication as above.
The EC doesn't have access to the ALS, so we use the keyboard backlight to
control the lightbar brightness instead:
If keyboard backlight is OFF (which it is when ambient is bright), use max
brightness for lightbar.
If keyboard backlight is ON, use keyboard backlight brightness.
BUG=chrome-os-partner:13870
BRANCH=Link
TEST=none
This is an aesthetic change. Nothing to test, only artisitic criticism.
Change-Id: Ib0b98eef18984945a83e988588c225025c4e8e52
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We recently changed the way host messages are passed to the EC to make it
work nicer across I2C. When we did, we updated all the internal structs
except those used for lightbar commands. This CL updates the lightbar
commands too.
BUG=chrome-os-partner:11277
BRANCH=all
TEST=manual
This shouldn't change anything, but you can ensure that by poking at the
lightbar manually. On Link, run this from a root shell:
ectool lightbar seq stop
ectool lightbar 4 ff 00 ff
ectool lightbar seq run
With the first command, the lightbar pattern should freeze.
With the second command, it should turn magenta.
With the third command, it should resume pulsing as before.
Change-Id: Ic5dc4c827b3b4459288d7d9bd7d06af8a5176b3c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33798
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some designs will have the PMU not directly connected to the AP but
behind the EC.
For easier bring-up, it's nice to be able to force power rails.
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:10912 chrome-os-partner:14324
TEST=manual
On snow, switch on and off the backlight using the API
BRANCH=none
Change-Id: I74e05308043546cb11f7f2cdbe644944c0a0a35e
Reviewed-on: https://gerrit.chromium.org/gerrit/26234
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
At other times, the battery should follow the normal charging rules.
Using the trickle charging logic has 2 problems here:
1) Battery voltage is near maximum, so trickle charging logic starts
out with voltage less than the actual battery voltage, and less than
the charging spec.
2) Trickle charging only exits when battery requests more current
(which it won't if it's near full) or on 4-hour timeout, not when
battery reads 100%. So this can cause overcharging.
Note that we still limit the charging current to what the battery asks
for, but if that's less than the minimum current from the charger we
simply provide the minimum and don't fiddle with the voltage since
that may interfere with the battery's ability to determine it's fully
charged.
BUG=chrome-os-partner:14402
BRANCH=link
TEST=manual
1. charge laptop to full
2. quickly unplug and plug charger
3. look at debug log; should either not charge at all (if charge is currently
100%) or charge at 8400mV (if charge is less than 100%).
Change-Id: Ifd5a9eb2e9bb791f74196713b645d1c9211eb736
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33729
Reviewed-by: Rong Chang <rongchang@chromium.org>
the PMU VACG signal used to detect AC state is connected to a GPIO, so
it's a board specific configuration.
On top of that, Daisy variants have custom logic on that line which is
not present on the next boards, so we need to update it before doing BSP
for next-gen boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14313
TEST=make BOARD=snow && make BOARD=daisy
on snow EC console, type "pmu" command with AC plugge and unplugged, see
that the "ac gpio" line reflects the right value.
BRANCH=none
Change-Id: If1e19b89b2f2de45d8dddc8340931e56c5f7f0a5
Reviewed-on: https://gerrit.chromium.org/gerrit/33630
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This solves the problem where the AP updates EC-RW as part of software
sync, then tells the EC to jump to EC-RW. On the next boot the EC
still returned the saved old RW hash, causing a needless cold boot.
This change is backwards/forwards compatible; existing RO code will
simply save a hash new RW code won't look at, and existing RW code
already knows to recompute the hash if the RO code didn't save it.
Hash computation is done in the background and takes ~350ms, so this
should have no noticeable effect on performance.
BUG=chrome-os-partner:13511
BRANCH=all (not needed for FSI, since RW code with this change will do
the right thing with existing RO code)
TEST=at the EC console, "sysjump RW" and look at the EC debug log for
"hash done".
Change-Id: Ie5255727b9d896b7c4e4f537e91d831682afc7f6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33634
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
CL 31370 almost fixed the power on bug except in the sysjump mode. While
EC firmware is being updated, the EC would sysjump between RO and RW.
So that gaia_power_init() would be called and accidentally set auto_power_on
to 1, which makes the next shutdown reboot instead. Thus, clear the
auto_power_on if the system is already on.
Also added more debug for future debug and fixed the XPSHOLD message output.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
BRANCH=Snow
BUG=chrome-os-partner:14183,
TEST=On snow:
; reboot successes. power on 1 (XPSHOLD seen)
ssh root@snow_ip "ectool reboot_ec RO; ectool reboot_ec A; reboot"
;
; system halts (no more automatical power-on, ending loop 3)
ssh root@snow_ip "ectool reboot_ec RO; ectool reboot_ec A; shutdown -h now"
Change-Id: Iad54377d53701b986ff4f0c9996f02f8f17f070a
Reviewed-on: https://gerrit.chromium.org/gerrit/33601
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
Previously, after the first error when trying to reset the pmu over i2c,
the ec would immediately give up and force a hard reset. Since i2c can
be a little flaky from time to time, to prevent unneeded resets this
allows the EC 3 attempts to configure it nicely it before it forces the
whole system to reset.
BUG=chrome-os-partner:14156
TEST=Boot machine successfully multiple times. Add a line in to force a
failure whenever the pmu is accessed to simulate a total failure and
check the EC logs, it should try 3 times on startup and on shutdown
before finally resorting to a hard reset. If you add a fake failure that
only triggers once, the machine should still turn out without incident.
Without any fake failures, everything should work as normal.
BRANCH=snow
Change-Id: I1f453e9a6acc59d63e4cc80cffb58684f104ca6d
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33466
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Otherwise the host needs to tell the EC how big this image is (which
it knows, but it's inconvenient for it to provide).
BUG=chrome-os-partner:13511
BRANCH=all
TEST=manual
1. ectool echash recalc ro -> prints hash of RO code (offset 0)
2. ectool echash recalc rw -> prints hash of RW code (offset non-zero)
In each case, size should be an exact number and not the size of the
whole RO or RW section. So for link, output should be something similar to:
localhost ~ # ectool echash recalc ro
Hashing EC-RO...
status: done
type: SHA-256
offset: 0x00000000
size: 0x00012a64
hash: 03a66c076d6dd4b4aa9ed6386713f45291f5143f9af2093003e632485899daf1
localhost ~ # ectool echash recalc rw
Hashing EC-RW...
status: done
type: SHA-256
offset: 0x00014000
size: 0x000123d1
hash: 0d6225e70f0b1e0419e987370371e00783f945827ef25915a8fb8549159dd2a4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
3. At ec console, 'hash ro' or 'hash rw' should regenerate the same
hash values printed above.
Change-Id: I3f6085d29927b8cdf9dabc6930f0fdc7222bd8b5
Reviewed-on: https://gerrit.chromium.org/gerrit/33123
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
This allows recomputing hash after EC boots.
BUG=chrome-os-partner:13988
BRANCH=all
TEST=manual
1. hash 2048 2048
2. hash 0 2048
3. hash -> hash value should be different than in step 1
Change-Id: Id66d0655a143b5190b5d8949b0fa9a18dbbc05f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33118
Reviewed-by: Simon Glass <sjg@chromium.org>
Previously this was in lightbar.h. ec_commands.h should not require
other header files.
Also make brightness local variable static, so it won't leak outside
lightbar module.
This is simply code cleanup; values themselves have not changed.
BUG=none
TEST=if it builds, it's fine
BRANCH=none (not required in link branch since it's just cleanup)
Change-Id: I5722fb677fcec99e0826e3dfc0b22033781b576f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32815
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
The moving average window contains previous discharging state of charge
values after state change. This change resets the index to make it
calculate only new battery readings.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13846
TEST=none
Change-Id: Ifc6c6208dea8edf262e7294972d7321501b709e2
Reviewed-on: https://gerrit.chromium.org/gerrit/32865
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This logic doesn't really belong in drivers, since to enable another
driver (like SPI) we must repeat it all. This is tricky if we enable
both I2C and SPI.
Move the logic into host_command.
BUG=chrome-os-partner:10533
BRANCH=none
TEST=manual
Use U-Boot to test comms status functionality on snow:
SMDK5250 # mkbp write rw 40000000
SMDK5250 # mkbp erase rw
SMDK5250 # mkbp erase rw
Change-Id: I3f90aada80208cd0540be14525f73f980ad33292
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32075
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Report the reason for a power on, to assist with debugging.
BUG=chrome-os-partner:11307
BRANCH=snow
TEST=manual
Build and boot on snow
See that power on reason is now reported
> 0.003508 power on 2
[0.028674 AP running ...]
...
12.163780 ending loop 2
Shutdown complete.
[batt] state discharging -> idle
17.801167 power on 4
Overriding CHARGER_INT with CHARGER_INT on EXTI4
[17.825873 AP running ...]
17.826071 XPSHOLD seen
[batt] state idle -> discharg
Change-Id: I2044419b330a74d19d8c4e63fa8853aa477b4df1
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32301
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
