Factor out fan speed control for easier adjusting fan speed stepping.
Also increase number of fan speed steps from 2 to 5.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8466
TEST=Manual test.
Change-Id: I0ff601c0a4f2ed2a4867bdc6e550eb2827404754
On Power+ESC -> ignore the power button being down until it's
released; system stays powered down.
On Power+ESC+Refresh -> send a power button pulse to the PCH. Ignore
the power button until after both the pulse has finished and the power
button is released.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8723
TEST=manual
Reboot system.
Press power.
System powers on normally.
Hold down ESC, tap power very quickly.
System resets and stays off.
Hold down ESC and power for several seconds.
System resets and stays off.
Hold down ESC and refresh and tap power very quickly.
System powers on; EC console indicates it's in RO.
Hold down ESC and refresh and press power for ~100ms
System powers on; EC console indicates it's in RO.
Hold down ESC and refresh and press power for several seconds.
System powers on; EC console indicates it's in RO.
Hold down ESC and refresh and press power for at least 10 seconds.
System powers on; EC console indicates it's in RO.
Change-Id: Idf9619da54ab299b0c65e6d68abb5e35e2ce9c79
BUG=chrome-os-partner:8728
TEST=manual
I don't have a system that has both an EC and a lightsaber, so I can't be
certain this works, but I *think* it will.
I do have a Link proto 0.5. With that, you can say
ectool lightbar test
and the EC console says it's poking at the lightbar, but of course there's
nothing there. If there was, it *should* flash in pretty colors. I have a
lightsaber attached to a BDS, and from the EC console running "lightsaber
test" does make it blink.
Change-Id: Ib6021ad8e53959de52b12efda376254071e5fb4b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8573
TEST=manual
1) Hold down refresh key and type 'reboot' from EC console. Console
should not show "[KB recovery key pressed at init!]"
2) Press power+esc+refresh. Console SHOULD show the message.
3) Press power+esc. Console should NOT show the message.
Change-Id: I642a7667b81c8d90c9490b23ce0f3519364427e4
This reverts commit dfe22b2b1e.
We seem to have solved I2C block issue. Reverting the workaround LPC
command and ectool command.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8239
TEST=Compilation succeed. Manually tested temperature polling still
works.
Change-Id: I0acb567a138282479c7cc07cbfa723c439d04cd7
De-assert the lightbar reset GPIO to be able to access its registers.
According to the HW guys, it will consume less power in standby than in
reset due the pull-up on the reset line.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
BUG=None
TEST=manual
On Link proto-1, type "lightbar test" in the EC console and see it blink.
On BDS, just build it. Nothing actually changes for BDS.
Change-Id: I9ec612c80f48d41ccf779f0962fc047966d4b7ba
Servo2 can set the write protect signal
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8580
TEST=manual
From chroot:
dut-control fw_wp_en:on
dut-control mfg_mode:on
Then from EC console:
gpioget WRITE_PROTECTn
0 WRITE_PROTECTn
From chroot:
dut-control fw_wp_en:on
dut-control mfg_mode:off
Then from EC console:
gpioget WRITE_PROTECTn
1* WRITE_PROTECTn
Change-Id: I9976cd6f114c8dae75434adf99d9409107b6ada0
In addition, it's not necessary for VGFX_CORE to be enabled for the
system to be in S0; just CPU_CORE is sufficient.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8725
TEST=boot system via power button; should boot normally
Change-Id: Iea32837b698845355f7fa6bd2eaca9fd95f6726b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8724
TEST=if timestamps show up in the debug output, it works
Change-Id: I5264a3a40a07a824cc15b39a7bd81f2db02a3c13
After commit 84a286b1, the watchdog handler was no longer properly
connected to the interrupt vector.
Also add a couple of flushes to get all the traces.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8721
TEST=type "waitms 5000" in the EC console to trigger the watchdog and
check we get the right serial trace.
Change-Id: I5a4dcdbc9000e7caeb5361d196c1f737a477c353
BUG=chrome-os-partner:8718
TEST=manual
1) Use 'reboot' command from console to boot image. Should end up in
image A, with last reset reason soft cold. 'sysinfo' should show we
jumped to this image.
2) sysjump RO. Should end up in RO; otherwise same as 1)
3) reboot using Power+Esc+Reload. Should end up in image RO, with last
reset reason reset pin. 'sysinfo' should show we did not jump to this
image.
4) sysjump A. Should end up in A with reset reason reset pin.
'sysinfo' should show we jumped here.
Change-Id: I2dd5595eab4ba2c91bfe8b2b2e9677d7732aca63
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original code doesn't handle those 2 commands well. SETREP needs a new
state for incoming data byte. EX_SETLED expects 2-byte parameter instead
of 1-byte.
Also enclose all asynchronous debug output in [] for servo-based testing.
BUG=chrome-os-partner:8674
TEST=on the target board. No "Unsupported data 0x00" message is seen.
Change-Id: Icb8e592fe54620677878ee15ef8a781c8906063e
This uses the last bank of flash to hold persistent settings, and
looks at the write protect GPIO to decide whether to protect the chip
at boot (chrome-os-partner:7453).
For ease of debugging, I've temporarily hacked this so flash uses the
RECOVERYn signal (dut-control goog_rec_mode:on) to enable WP instead
of the write protect signal; this works around chrome-os-partner:8580.
Also note that if you write protect any blocks even temporarily,
you'll need to do a power-on reset to clear them before you can
reprogram the flash. See chrome-os-partner:8632. At the EC console,
"hibernate 1" will do that, or you can just yank the power.
This also fixes a bug in the flash write and erase commands, where
they weren't properly detecting failure if you attempted to modify a
protected block (missed an interrupt reason...)
New "flashwp" console commands work. LPC commands need reworking.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8448
TEST=manual
Change-Id: I49c38cc25c793094ae3331a4586fda0761b4bac6
No point in saying "edit the file if it doesn't work", when we could just
provide a slow version instead.
BUG=none
TEST=none
Change-Id: I94731495635e4dc6d0aa6e3f577cb727af92894a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Comapre the range to be write (erase) with the range of active image.
If overlap, return error to indicate the access denied.
Note that we actually protect only runtime code and ro data.
FMAP is intentional unprotected so that flashrom can update to new map
before jumping. Since the vector table and init code are in the same
erase page, they are unprotected as well.
BUG=chrome-os-partner:7478
TEST=
Change-Id: Icb5cc89836432a11cef80e18eb66bb39a6c9b1d9
BUG=chrome-os-partner:7839
TEST=none
Signed-off-by: Bill Richardson <wfrichar@google.com>
Only tested on BDS at the moment, because that's all I have.
Change-Id: I30c7202856a272953bf7170c6786999378984329
Now that we can jump directly to other images, we don't need this.
We jump to image A by default, unless the recovery button or signal is asserted.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8562
TEST=manual
Reboot -> runs image A
Reboot with reload (F3) held down -> runs RO
Reboot with 'dut-control goog_rec_mode:on' -> runs RO
Change-Id: I8259fe0d738ce0ca897d2f4427d8cf61858b8901
The final piece links the keyboard press and x86_power module.
BUG=chrome-os-partner:8523
TEST=on the link board.
wait for 15 minutes to make host suspend. touch any key to wake up host.
Change-Id: Ie6ae840ae546731daea48ab457fdc056feb5a685
This is necessary at init-time for verified boot to jump from RO to
one of the RW images.
It's also used by factory EC update to update one image and then jump
to the updated image to finish the update. In this case, the x86 does
NOT reboot.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8449
TEST=manual
1) power on x86 and log in
2) sysjump a --> system is in a; x86 has not rebooted
3) sysjump ro --> system is back in RO; x86 has not rebooted
4) reboot -> system is in RO; x86 HAS rebooted
Change-Id: I9dbadcf9775e146a0718abfd4ee0758b65350a87
We moved a while ago to a table of ADC channels, so having a
meaningless constant defined in board.h is more harmful than helpful.
BUG=none
TEST=build link, bds
Change-Id: I651a609c9ed13f879bb943c90731275407d77e50
Signed-off-by: Randall Spangler <rspangler@chromium.org>
The kernel no longer uses port 80 as a delay mechanism, so we don't
need to detect the no-longer-present spammy writes.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7972
TEST=port80 scroll, then boot the system. see a few repeated bytes,
but not piles of 00 and ff's.
Change-Id: Id14dc43ab4e1b15c6bab99a17c062f295a59e7e6
More modules can be disabled individually through CONFIG_ defines.
Reordered early module pre-init and init, and added comments to
explain why things are ordered in main() the way they are.
Fixed a few assorted init-related bugs along the way, like st32m
keyboard scan double-initializing.
BUG=none
TEST=build link, bds, daisy
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I04a7fa51d743adfab4be4bdddaeef68943b96dec
This CL adds battery SMI events. And refactors the charging state
machine by adding share state context for all handlers.
Power events are moved to common handler. Minor clean up on console
output messages.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:7526,7937,8450
TEST=manual:
Watch console message when connecting/disconnecting AC adapter and
battery. Check the state transition.
Change-Id: I42eec4f87a9d49bd193cb9dde9080e3dfccbb77c
Board-specific features like lightbar should be config'd at the board
level, not at the chip level.
BUG=none
TEST=build link, bds, daisy
Change-Id: If1df2ca0422f7b8bdc172d0df7bd9f6a1af6a9d2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Group temperature sensors into different types so we only have to set
temperature threshold for each type instead of each sensor.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8466
TEST=Fan control still works.
Change-Id: I7acc714c32f282cec490b9e02d402ab91a53becf
Modify thermal engine to treat temperature threshold as a 3-degree range
instead of a certain value. This way the fan do not keep turning on and
off, while the temperature floating around the threshold value.
Signed-off-by: Vic Yang <victoryang@google.com>
BUG=chrome-os-partner:8466
TEST=Set threshold to current temperature. The fan turns on and does not
immediately turns off.
Change-Id: Iad1de05a409dbbc573a8ffd0ece0dc7961b20806
Update test python scripts for recent trace modifications :
- lack of firmware B
- updated motd
Update QEMU to deal gracefully with various new registers accesses.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=make qemu-tests
Change-Id: I59a53822193b7377fe5f61f75c951b6cd24fc54b
Allow to build without the power button task.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=make qemu-tests
Change-Id: Ibc757a6641f195f0d10e6a673792b996694f8cec
