If a bug causes the pmic's internal registers to be overwritten with
garbage, they won't go away and can cause long lasting problems. This
change overwrites them all whenever the EC or AP turn on with known,
safe values, so if that happens, a reboot will restore them instead of
forcing the user to pull the battery. It also overwrites a few of them
when the AP shuts down, to prevent AP bugs from leaving the pmu powering
a bunch of peripherals that it doesn't need after it has turned off.
BUG=chrome-os-partner:12913
TEST=from EC console run "i2c w 0x90 0x0c 0xff" to screw up one of the
pmic registers. Reboot the EC, and the AP should be able to boot just
fine. Once the AP is booted, run that command again. This time, just
reboot the AP, it should come back on like normal. Try again with "i2c
w 0x90 0x0c 0x00". Without the change, this fails to work.
BRANCH=snow
Change-Id: If3f0764f23e0112cc11be60b413f51e1b66e54a7
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31259
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Current *_RW_NOW/RW_AT_BOOT is used to lock the entire flash. This could
lead confusion in the future. So, rename them.
Since the bit definition is unchanged, thus the callers (u-boot, flashrom)
is fine if they don't change the name.
BUG=chrome-os-partner:12951
BRANCH=snow,link
TEST=build in chroot only:daisy,snow,link,bds
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: I2395e93793f590e6fb8aae7006eb8e5c836002bc
Reviewed-on: https://gerrit.chromium.org/gerrit/31199
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The response size was wrong. It should be right.
BUG=none
BRANCH=link
TEST=none
Build the lbplay tool, copy it to the DUT.
cd src/platform/ec
make BOARD=link
scp build/link/util/lbplay root@LINKIPADDR:/tmp/
Run /tmp/lbplay on DUT. It used to print a warning message. Now it doesn't.
The lightbar will glow green, then red (that's what lbplay does).
Change-Id: Iee02a026f08b6f761e5f28f20b79bcb9f4704a43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31403
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The logic introduced by CL 28139 was incorrect
(ie it just sets to 0 the auto_power_on variable which is already 0)
For software sync, we always want to power the AP.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:13126
TEST=on Snow, cold reset the EC and see the AP firmware booting.
in U-Boot console, type "mbkp reboot cold" and see the AP rebooting
instead of shutting down.
BRANCH=snow
Change-Id: Ib88f75a8b159015df708c041cdc14153fe8736a9
Reviewed-on: https://gerrit.chromium.org/gerrit/31370
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The existing state machine does the following:
- when power button is pressed it
1. powers on the AP
2. sets a timer of 1 sec and then
3. waits for power button to be released
When the timer fires it checks xpshold is set by the AP and if so
it clears the pwron signal (which is used by the AP to detect power
button is pressed).
The problem occurs when the user holds the power button for more than a
second. The AP turns on xpshold, then notices that pwron is still on
and subsequently powers down because it thinks the power button is
pressed. When the button is finally released, since it was held down
for more than a second, the timer routine notices that xpshold is not on
and therefore shuts down the system.
Another problem found while analysing this state machine is that loop
checking for poweroff only triggers on the rising edge of xpshold. This
means that if the AP powers down the EC might miss a possible power
event.
Here is the proposed fix:
When the power button is pressed the EC will:
1. power on the AP
2. Check for xpshold to be asserted with a 1 sec timeout
3. If uboot is healthy xpshold should come on pretty quickly; the EC
then waits for the power button to be released in less than 8 seconds
4. If the power button is released then the EC waits for power off
events.
5. If the power button is not released it waits for upto 8 seconds
before turning off the AP.
The added wrinkle is how to address a borked uboot case. In the case
where xpshold doesn't come on in < 1 second, the EC will allow the AP to
stay on for upto 16 seconds so that USB boot can finish. The user must
hold the power button down until uboot boots and sets xpshold. The
assumption here is that USB boot takes < 16 seconds.
BUG=chrome-os-partner:12748
TEST="follow instructions in bug report"
Change-Id: I5b582a6c3ae3449238e2813e4a581bd8f92dd846
Signed-off-by: Puneet Kumar <puneetster@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31291
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It wastes time to erase blocks that are already erased and it is faster
on stm32 to check first. Add a check in flash_physical_erase() on all
chips, using a common flash_is_erased() function.
BUG=none
BRANCH=snow,link
TEST=manual
Do software sync in U-Boot and see that it succeeds. This tests that
we can still erase and then boot a written image. It typically saves
a second on a full sync over i2c.
SMDK5250 # cros_test swsync -f
SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
Flashing RW EC image: erasing, writing, done
Flashing RO EC image: erasing, writing, done
Full software sync completed in 22.949s
SMDK5250 #
Also see that second erase is faster:
SMDK5250 # time mkbp erase rw
time: 0.952 seconds, 952 ticks
SMDK5250 # time mkbp erase rw
time: 0.054 seconds, 54 ticks
SMDK5250 #
Change-Id: I3699577217fdbb2f212d20d150d3ca15fdff03eb
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30851
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Charger LED is controlled by TPSCHROME chip. And it blinks only when
hardware detected charging error. On other charging error conditions
not detected by TPSCHROME, we set the temperature thresholds to make
charger generate the error blink.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12224
TEST=manual
Plug AC power, heat up battery to 65 C. The charging LED should
start blinking instead of green.
Change-Id: Ib1c38a88c026471a52fbbb4f803e3b2aba93ab40
Reviewed-on: https://gerrit.chromium.org/gerrit/31139
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
The AC status GPIO also indicates power button. When power button is
pressed, EC should return VACG in pmu_get_ac() funtion. If this function
is called in interrupt context with power button pressed, return 1.
Charging task will play nicely in charging mode without real AC. But in
discharging mode, it will shutdown application processor if battery
remaining capacity is too low.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12738
TEST=manual
With AC plugged, press and hold power button.
Run uart console command "pmu" and check output, "ac gpio" should be 1.
Change-Id: I26d1a5a7a4ed2ff26a35e965a3ca2307a9c231e9
Reviewed-on: https://gerrit.chromium.org/gerrit/31112
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This is intended to prevent accidental AP reboot when soft rebooting
the EC, e.g. via sysjump during firmware updates. For our platforms,
the PMIC_PWRON_L causes the AP to see a keyboard power button press.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12650
TEST=sysjump via "ectool reboot_ec RW" or firmware update no longer
causes AP to reboot,
Change-Id: Ife227285499d5cd52d6a0cb0ebe5df2f51d706d4
Reviewed-on: https://gerrit.chromium.org/gerrit/30291
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
I keep getting asked to build an EC image to manually control the lightbar
patterns so that the Powers That Be can look at it. This change just makes
it possible to turn that mode on and off for yourself. You'll need a root
shell or the EC console to do it, though.
BUG=chrome-os-partner:8039
BRANCH=link
TEST=manual
From the EC console, type
lightbar demo 1
OR from the root shell run
ectool lightbar demo 1
After that, these keys should change the lightbar appearance (transitions
may be slow and subtle - that's intended):
UP = battery is more fully charged
DOWN = battery is less fully charged
RIGHT = battery is charging
LEFT = battery is discharging
BRIGHT = increase lightbar brightness
DIM = decrase lightbar brightness
Note that this does not interfere with the normal function of any keys. It
only adds some additional EC behavior.
Change-Id: Ia1a9855188244d74b670f9dbfdf60e3ac0343460
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30899
When AC power is not connected, EC doesn't update battery information in
mapped memory. This makes battery information unavailable is AC is not
present when EC boots.
BUG=chrome-os-partner:12858
TEST=Unplug AC and reset EC. Run ectool and check we can see battery
info.
BRANCH=link
Change-Id: I23339962a6aa1bbbf6806c1184b96e949466208f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30820
Reviewed-by: Rong Chang <rongchang@chromium.org>
Erasing the flash can take a while, by which time the host may have timed
out. So pass an in-progress message back to the host before starting, and
when done, stash the result for later collection.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Change-Id: I5566a5519a1c8b320573b20e1ea7660217b32a5e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30471
To reflect the CL 00799d5 that moves the pstate to 0xf000.
BUG=chrome-os-partner:12799
TEST=Build in chroot.
snow: WP_RO is changed from 0:0xf000 --> 0:0x10000.
daisy: WP_RO is unchanged.
link: WP_RO is unchanged.
Change-Id: I572bae3f624744e60d13a762875211beffc6c516
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30670
Reviewed-by: Vic Yang <victoryang@chromium.org>
The serial console was showing that the CPU was being forcefully shut down,
but I couldn't figure out why. Add a debug message so I'll know next time.
BUG=none
TEST=none
BRANCH=none
Change-Id: I6216711d03fd5e08190b9f0528a4bd8948b74dd8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30606
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the AP is suspended, we are using the timer TMR2 to do the power
led "breathing", so we cannot cut the clocks as they are used for this
PWM.
The EC will be in idle mode instead of stop mode during S3.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, suspend the AP and see you can still type in the EC
console and the power led is "breathing".
Change-Id: Ib4cce36c5a9bf649996bf627baeb30ef2a3221a8
Reviewed-on: https://gerrit.chromium.org/gerrit/30057
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: <arscott@google.com>
Rather than have the send_response() handler called willy nilly from
around the EC code, provide an official function for doing this step.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Tried 'mkbp reset' command on snow but it did not seem to work properly
Unable to test on link at present
Change-Id: I8d9146639efb2af482d80563b403771cee961942
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30468
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change corrects charger interrupt event handling, charger enable
gpio, battery full condition, EC deep sleep mode support when AC
unplugged, and lid controlled power off.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12573,12574,12575
TEST=manual
- ec console command 'gpioget':
- SPI1_MISO should be 0 when AP off
- CHARGER_EN should be 0 after AC unplugged
- charging led should be off after AC unplugged
- when battery remaining charge < 3%, system should be powered off
without AC.
- ec console command 'sleepmask 0', turn off AP:
- deep sleep only when AC unplugged
Change-Id: I0f63835dae67d90de7a8c8c6c3537ca9a16faed4
Reviewed-on: https://gerrit.chromium.org/gerrit/30316
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This is better than having the 0xea byte only appended in ec.bin,
since now the byte is present in ec.RW.flat and ec.RO.flat. Needed
for EC software sync.
BUG=chrome-os-partner:12412
BRANCH=link,snow
CQ-DEPEND=30305
TEST=manual
1. xxd ec.RW.bin | tail; should end with 0xea
2. xxd -g4 build/link/ec.bin | grep -C3 454e44ea
That word should be the last one before a bunch of 0xfffffff bytes.
There should be 2 matches (since there's RO and RW firmware)
Change-Id: I0de5cc78083f1a9b49202fbe2305a3101f401db3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30303
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Changes made by this patch:
1. Create IRQ handler for the TPS65090 IRQ. IRQ wakes up charger task.
2. Charger task sets the AC_STATUS GPIO based on the AC status.
3. Initialize PMU at power-on.
BRANCH=snow
BUG=chrome-os-partner:11739
TEST=Power on the system, with servo v2 connected to EC console. Plug
and unplug AC. The IRQ handler should be triggered.
Change-Id: Ice23411c275111fdb56d2c47ba28c3c44dee4d71
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29914
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This is to prevent temperature value being read before the first time we
poll sensors causes unexpected error.
BUG=chrome-os-partner:12614
TEST="sysjump RW" and then "temps" immediately. Check all temperature
readings are near 300 K.
Change-Id: I5c84d9696b4876fdfcf14c3a416cbc09c040d4ee
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30138
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- Add a special port80 event for LPC reset assertion and use that event
to store the previous post code.
- Add a new command to retrive the last saved post code so I can easily
query it at boot/resume and log unusual codes.
BUG=none
TEST=manual (with additional coreboot/mosys changes)
- interrupt boot process by issuing x86reset on EC console or
by using warm reset button on servo
- read event log with mosys on next boot
78 | 2012-08-13 09:24:04 | System boot | 262
79 | 2012-08-13 09:24:04 | Last post code in previous boot | 0x9e
80 | 2012-08-13 09:24:04 | System Reset
Change-Id: I7b9f10442b9c468d89fde4e75adb94b0c07c2c8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29995
Reviewed-by: Randall Spangler <rspangler@chromium.org>
system_hibernate(0, 0) now hibernates until a wake pin assert, with no
RTC wake.
BUG=none
TEST=manual
command -> expected reset flags from 'sysinfo'
1. reboot -> soft
2. reboot hard -> power-on hard
3. hibernate (and press power button) -> power-on wake-pin
4. hibernate 3 (and wait for timeout) -> power-on rtc-alarm
5. hibernate 10 (and press power button before 10 sec) -> power-on wake-pin
hibdelay 10
then shut system down and run on battery
10 sec later, system should hibernate.
Change-Id: I399413d265f6fcf808adf9ed1db7b812a1b12fc2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29923
Reviewed-by: Vic Yang <victoryang@chromium.org>
update settings according to IR3570Axxxx_REV5_DRC_7-27-12.
This should fix the spurious UVLO during reboot,
so it re-activates the fault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:11947
TEST=on Link EVT reworked with IR3570A, run software and check we can
reboot normally and we have no GPU warning.
Change-Id: I5882f1d25a65c81fdaa4326ead913bc080b71ee9
Reviewed-on: https://gerrit.chromium.org/gerrit/28650
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:12483
TEST=from root shell, 'ectool console', then on the ec console, type
'help list' a few times to generate lots of debug output, then repeat
'ectool console'. Then on EC console, 'syslock', and then 'ectool
console' should fail.
Change-Id: Ie1c74c7e35d6b8228615d20192fd90093977de64
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29825
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Adds shmem command to print amount of shared memory. This is also a
useful indicator of how much IRAM is left, since shared memory will
expand to fill all unused IRAM.
Removes never-implemented wait param to shared_mem_acquire().
BUG=none
TEST=shmem
Change-Id: I798ff644d701dcba52219b70bec99c06a23d03ec
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29809
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
It was previously only enabled for 1500us during boot, but in a way
that triggered a needless round of notifications to other modules.
This is cleaner.
This also fixes adc_init() not initializing the task IDs to wake when
interrupts come in, and removes some unneeded code from other init
functions.
BUG=chrome-os-partner:12472
TEST=boot system and run adc command. Should still provide reasonable data.
Change-Id: I9ae5857d988c727caf5d53f551a2f12b30974c0f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29806
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the AP is not running and we have enough time go to STOP mode
instead of simple idle.
The EC consumption should drop from 12mW to a few mW.
This is currently not activated by default, you need to type "sleepmask
0" in the EC console to activate it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, check the software is still working properly when STOP
mode is activated and measure power consumption on 3v_alw rail.
Change-Id: I231d76fe6494c07b198c41694755b82d87c00e75
Reviewed-on: https://gerrit.chromium.org/gerrit/29315
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Superseded by EC software sync (hash-based).
Sig-based vboot was correctly implemented, but ended up being too slow
to be useful given the limited processing power of the EC chips, and
we also couldn't come up with a manageable way to handle A/B
autoupdate of signed EC firmware.
This change and an associated vboot_reference change shrinks the EC
binary by ~2KB.
BUG=chrome-os-partner:11232
TEST=build link,snow; boot link and check that 'hash' command still works.
Change-Id: I3f03ae2d0a4030977826980d6ec5613181e154c2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29496
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:12353
TEST=hack the thermal monitoring and/or battery code to trigger a shutdown
then see that the events get set
Change-Id: I5ef2ac03cdd793ab0c50c0db518cba1ede3ea036
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29429
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
- 'port80 intprint' toggles printing port 80 codes in interrupt
handler (turning that off speeds up port 80 capture a bit, if you're
sending port 80 codes very rapidly)
- 'port80 flush' flushes the log buffer
- log buffer expanded to 256 entries
- log buffer tracks S3->S0 power state transitions, so you can tell
where each boot starts
This uses ~500 bytes more RAM on the EC, but we've got piles of RAM
(with this change we're using 17KB out of 32KB).
BUG=none
TEST=manual
- boot system
- port80 -> prints data
- port80 intprint -> now disabled
- reboot; wait for reboot; no port80 debug output during boot
- port80 -> prints data from previous boot AND this one
- port80 flush
- port80 -> nothing in log
Change-Id: I64ee72fb13ab0fdd85d04b9640b5390fdac31400
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29420
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
To save power, make the EC hibernate after we go into G3 for 24 hours.
BUG=chrome-os-partner:9386
TEST=Use "hibdelay 5" to change the delay to 5 seconds.
Remove AC power, power down and check device hibernates after 5
seconds in G3.
Connect AC power, power down, wait for G3. Remove AC power and
check device hibernates after 5 seconds.
Change-Id: I6fb907c904798076a763f22bd35f53f7424d6200
Reviewed-on: https://gerrit.chromium.org/gerrit/29400
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
It is possible that power LED goes off while AC still connected. Let's
set power LED periodically to aviod this problem.
BUG=chrome-os-partner:10386
TEST=Disconnect power LED while leave AC connected. Check LED goes off.
Connect LED again and check it comes back after few seconds.
Change-Id: I2a199446be5da772af8027b735b9f431f697bacd
Reviewed-on: https://gerrit.chromium.org/gerrit/29403
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
CONFIG_FW_RW_OFF is already relative to the base address of the flash,
we don't need to substract it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=on Snow, run with CONFIG_VBOOT and CONFIG_VBOOT_HASH activated and
see the hash is correctly computed and display.
Change-Id: I1643b07a59459baa973bfd7ee80cbf98963a85d4
Reviewed-on: https://gerrit.chromium.org/gerrit/29276
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Prints all x86 signal power state transitions at interrupt level, so
we can see lines toggle more precisely.
BUG=chrome-os-partner:12229
TEST=manual
1. power on system
2. no debug output that looks like [501.001742 x86 in 0x563f]
3. reboot
4. x86indebug 0xffff
5. power on system
6. should see lots of lines that look like [501.001742 x86 in 0x563f]
Change-Id: Ie3b346ee4d4beee3f13ac1245f1eb022b48dabf4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29192
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the user is logged in a closes/opens the lid of the laptop the
lid_changed flag gets set, but never cleared. Normally, it would get
cleared when it powered back on from being opened, but without powerm
running or is the machine is only suspended, then that never happens.
This fixes the problem by additionally clearing the flag whenever the
computer is powered down. This forces the computer to not turn on
based on anything that happened to its lid before it was turned off,
which is the behavior you'd expect.
BUG=chrome-os-partner:12189
TEST=Log in to your Chomebook completely. Close, then open the lid.
Shut the computer down. It should stay off now. Once it's back on
close the lid and confirm that it still suspends correctly. Now
open the lid and make sure it turns back on. Repeat these steps, but
kill powerm first.
Change-Id: I2275b3125115b4eacc6a5d074978d7a1d51b0695
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29111
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Prints when a host command returns an error code.
When 'hcdebug on', hex-dumps the host command params and response.
BUG=none
TEST=manual (> is ec console, $ is root shell)
$ ectool gpioget foobar --> EC console shows error 2 returned
> hcdebug on
$ ectool hello --> EC console shows params and response as hex
> hcdebug off
$ ectool hello --> no extra output on EC debug console
Change-Id: I2dbc77be5b59125f394d970cf1c83c2a976e926e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28948
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The EC was not re-enabling keyboard scanning on boot if the power button
was released. This works fine if the power button is released before
the shutdown is complete, but if the user holds it down until the device
is completed powered down the lock will never be released, and the next
time they turn on the computer, the keyboard won't work.
To fix this, all that is needed is to make the power event task keep
unlocking it whenever the power button isn't pressed down. There's
no problem with unlocking multiple times, so it's not dangerous to do
this.
BUG=chrome-os-partner:12070
TEST=Boot the machine normally, then press and hold the power button
until the machine is entirely powered down before releasing it. Press
the power button a second time to turn on the machine. You should be
able to type as normal.
Change-Id: I88852ed228bd8f6a9446406bab642812ef1327db
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28871
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Make sure we don't roll over when rounding up to align the requested size.
BUG=chrome-os-partner:11642
TEST=none
No test; if security guys approve code change, it's fixed.
Change-Id: I2e915a6e6b37fc315ab7adb435e2fce4eed670ba
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28729
Reviewed-by: Sumit Gwalani <sumitg@google.com>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
