On snow, there are reports of the following warning in the i2c master
reciever code:
Stop event deadline passed: CR1=0000001000000001
I've been running this torture test, and even with the timeout feature
completely removed, it never hangs. The stop bit is always sent
eventually, even through thousands and thousands of transactions (of which
a couple take too long for the current timeout).
I timed a lot of these and it looks like the vast majority are fine but
just a few are really really slow. To this end, I'm increasing the
timeout. It seems that the wait loop is getting preempted for a while
before it can go back and check, causing these timeout messages. So every
now and then the process get pre-empted for a long time causing what
looks like a long timeout. The thing is, the stop bit is always getting
sent, we're just not noticing for a while. So even in the really slow
cases, everything should be fine.
Since the bit's getting sent either way, it seems like increasing the
timeout all but fixes the problem where the EC thinks it didn't send.
However, since the timeout is quite high now, I added a sleep
in the busy loop so that if a message is messed up and the stop bit doesn't
send, the task won't steal the cpu for the entire time.
Note: This also fixes a bug in the i2c error handler where it was trying
to print ints and strings and ads a little more information to the
timeout warning in case it starts showing up again.
BUG=chrome-os-partner:12742
TEST=From the EC console run "battery 100000" while running
"while true; do /usr/local/sbin/i2cdump -f -y 4 0x48; done" to seriously
stress test the i2c bus. Then reboot the machine several times. There
should be no Stop bit warnings, or failed i2c transfers
BRANCH=snow
Change-Id: I590a9458783d16e57987102b1ec1299d5ddb0fa2
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31024
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>
When we set the TIM3 hardware timer match interrupt (used for 16-bit MSB
of the 32-bit microsecond counter), as the STM32 hardware block is not
triggering an interrupt on an exact match (only on the transition from
N-1 to match value N), we need to check whether the counter has been
incremented to the match value before we set the interrupt enable bit.
In that case, we simply fallback to the existing code to set the LSB
match interrupt.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:12715
TEST=use Snow board and see we are no longer getting EC watchdog in the
idle task.
BRANCH=snow
Change-Id: I4ceeb46425c799e328603ae0e99b678547d88fbe
Reviewed-on: https://gerrit.chromium.org/gerrit/31228
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The i2c driver was returning the result from task_wait_event() as an
error code when it failed. However, this function returns an event
mask, not a valid error code. It has been replaced to return
EC_ERROR_TIMEOUT instead when the even times out.
BUG=chrome-os-partner:13057
TEST=Booting the machine, and normal use works fine. Running i2c stress
tests also work without error. No functional changes were made, only
the error codes for debugging.
BRANCH=snow
Change-Id: I3e48f97c08c82fd50b811e8289f3bd378ecb3171
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31214
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:12412
BRANCH=snow
TEST=none
The current constant is wrong. It was broken before, now it still may be
broken but hopefully less so.
Change-Id: Ia425bc45c4ccb0b4623fa802d4e5913389cb9d22
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31190
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
USART1 has always had its Tx and Rx pins configured as "alternate
function output". However, this turns out to be incorrect since
there is no concept of an AF input on the STM32F. Instead, the
Rx pin should be configured as an input (and the Tx remains an
AF output).
This also simplifies the console resume code since we only need to
enable/disable the interrupt rather than reconfiguring the GPIO.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12223
TEST=flashed on snow, EC console works
Change-Id: Ia92dbbac16fc55d0db62381dfb487aeb4f4121b4
Reviewed-on: https://gerrit.chromium.org/gerrit/30941
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This also moves flash related tests to use new 'hostcmd' console command.
BUG=chrome-os-partner:10262
TEST=Test passed
BRANCH=none
Change-Id: I5616bfa93bcde0beb4cb2baf2d38e8b5d827c275
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30665
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Usually the power LED is driven by the PWM mode so that its nominal
brightness can be set to a "soft" on value. However, when
the LED is to remain off the LED should be switched to floating
input mode. This reduces voltage leakage.
This CL updates the power_led_task to configure the LED however is
appropriate and adds board functions to re-configure the GPIO.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12381
TEST=LED responds as expected in suspend and on/off states, also
tested that leakage is reduced with multimeter
Change-Id: If90ac78aaffe7358cce80dd02ec1423c2cb4f664
Reviewed-on: https://gerrit.chromium.org/gerrit/29705
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This splits out the GPIO config logic from gpio_pre_init() into its
own function so that it may be used by code elsewhere.
TODO: Improve alternate function setting, and clean up Snow's board.c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=none
TEST=flashed onto Snow, everything came up as expected
Change-Id: I47888c89d4d2bedd0c37b95406a64f024f1ec354
Reviewed-on: https://gerrit.chromium.org/gerrit/30762
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
There was a usleep put into a function that can be called from in an
interrupt context, which doesn't work. This just switches it over to
udelay which will work in an interrupt.
Also flips the condition on the i2c if/else that might send it there.
It was backwards before
BUG=chrome-os-partner:12688
TEST=Run "battery" "pmu" boot the machine and use the keyboard. Then
replace the in_interrupt_context() function with "1" to force it to use
polling and repeat the test. Everything should work in both cases.
BOARD=snow
Change-Id: Ib2a8c7f9e5e2eb3f6b00678d6307afc9dd5f0518
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30575
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
When a command is marked as in-progress, provide an interim EC_RES_IN_PROGRESS
response and then stash the real response (when available) ready for a
EC_CMD_RESEND_RESPONSE message.
Track whether the host_command processor is busy internally within this
driver. Provide this information through an EC_CMD_GET_STATUS message.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Change-Id: I5acece074ad8408c978ca36b73d1330fa51575ae
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30470
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some commands take a long time. For interfaces which are not synchronous the
host wants an immediate response to know that the command is in progress.
Provide this new result code, and set LPC to ignore it.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Change-Id: If801c21e6cf96746858dfa64f6ce1f1631d3e6e5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30469
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Fixing a couple problems in the error handling for i2c interrupts. The
code could fail and not notice if master_start() returned an error code
with the TASK_EVEN_WAKE bit set. Now it stores the return values
separately to prevent this.
Also, the task id's that the ISR's use to wake up the i2c task after the
transfer is complete were uninitialized. They should always be
initialized by a call to dma_enable_tc_interrupt() but just in case, now
they all get a default value in dma_init() which is called on startup in
board.c
BUG=chrome-os-partner:12405
TEST=confirm that i2c is still working in both slave and master mode by
using the battery and pmu commands from the EC console, then booting up
the machine and using the keyboard. Confirm there are no error messages
on the cpu console.
Change-Id: I49c3da0bf17d0853247a37131cac9719face7ed4
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30417
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
To make software Sync work, they need to be able to call
i2c_send_response() from within host_command_received() while still in
an interrupt context. This won't work if you're using interrupts to
know when the dma transfer has completed. This puts a switch in that
will toggle between interrupts and polling the interrupt flag based on
if the program in in an interrupt context or not.
BUG=chrome-os-partner:12688
TEST=Run "battery" "pmu" boot the machine and use the keyboard. Then
replace the in_interrupt_context() function with "0" to force it to use
polling and repeat the test. Everything should work in both cases.
Change-Id: Ie989c1a6ad29529a7ec390065b310ad4af8cf0bf
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30483
Reviewed-by: Simon Glass <sjg@chromium.org>
To reduce the amount of time spent polling to see if the i2c bus has
completed its transfer, I'm converting it over to interrupts. Before
starting a dma transfer, the i2c code now enables dma interrupts with an
ISR that will just wake up the i2c task when the transfer is complete.
This leaves the cpu free while the dma is handling all the i2c work.
The slave-receiver didn't require any updates as it is already interrupt
driven, via the i2c events. The other three cases: master-receiver,
master-transmitter, and slave-transmitter, have all been converted over
to use the dma interrupts. With these changes, the cpu should spend
very little time waiting for i2c transfers to complete.
BUG=chrome-os-partner:12405
TEST=To test the master modes, from the EC console run "battery" and
"pmu." If those work, then master mode is functioning. For slave
modes, power on the machine and monitor the cpu console for errors.
When it's on, try typing and confirm there are no errors there either.
Change-Id: I1ca020911b7be6762389ca2b858b2b973f8754bc
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30229
Reviewed-by: David Hendricks <dhendrix@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>
There was an errata issued for the i2c on STMF100xx. It specified that
not all guarantees apply to i2c on these chips if you are not using DMA
to load the data. To prevent problems, I am converting the i2c code on
the EC for Lucas over to DMA.
The master functionality was already converted over in change I2fb80dcb,
this change switches over the slave-mode i2c code to also use dma now,
instead of polling, as per the errata.
BUG=chrome-os-partner:10901
TEST=The slave mode i2c code is used heavily during normal use of the
Chromebook, including boot up and using the keyboard. Start up the cpu
uart console, and boot the system. Then once it's fulling started, make
sure that pressing keys does not cause any errors and that the key presses
are working.
Change-Id: I8d665054bccbd3ca9b8dcc5e0fa74b2fbe49f52d
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30024
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@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>
There was an errata issues for the i2c on STMF100xx. It specified that
not all guarantees apply to i2c on these chips if you are not using DMA
to load the data. To prevent problems, I am converting the i2c code on
the EC for Lucas over to DMA.
Here the i2c's master functionality is retrofitted to use DMA
instead of polling to fill the i2c buffer. The slave functionality
is still left in the old style for the time being, but will also be
converted soon.
BUG=chrome-os-partner:10901
TEST=From EC console, make sure that "battery" and "pmu" commands work.
They both use i2c, so if i2c had been broken they would fail.
Change-Id: I2fb80dcb68632938df1c9165ebd5a67cb5194451
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29811
Reviewed-by: Simon Glass <sjg@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>
When STOP mode is activated, the UART is not able to wakeup the EC when
sleeping, preventing to enter commands on the EC serial console.
Allow to switch the UART RX line as a GPIO connected to EXTINT10 to
wakeup the system on incoming character.
This is just a debug feature since EXTINT10 is normally used to scan the
keyboard.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, enable CONFIG_FORCE_CONSOLE_RESUME at build time and type
"sleepmask 0" on the EC console, see I can get the serial console back
by typing a character on the serial console.
Change-Id: I936cbf13707ef8cde277f1053a4d35d23ff06511
Reviewed-on: https://gerrit.chromium.org/gerrit/29776
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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>
This ensures it comes up in a known-good state.
BUG=none
TEST=manual
scratchpad write 0x12345
hibernate 1
scratchpad -> still 0x12345
keyboard reset
scratchpad -> still 0x12345
pull power and battery, then plug back in
scratchpad -> now 0
Change-Id: I2c205f53e03eefe915260b9be39c809ea7d69293
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29500
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>
We have seen instances where the AP has interrupts disabled for a long
period of time (specifically when doing a lot of printk messages to
the console). When this happens the host can't service i2c in < 10ms
(it needs an interrupt per byte) and we were getting a timeout. We'll
increase the timeout to 100ms to avoid these problems. Better to be
safe than sorry.
This timeout runs from the host command task so having the delay
shouldn't be a terrible thing (we're not running from an IRQ handler
or anything).
Only affected the timeout for slave mode specifically so as not to
affect any untested behavior.
BUG=chrome-os-partner:12123
TEST=With serial console enabled, run this in two different ssh
sessions:
a) while true; do flashrom -p internal:bus=i2c -r /tmp/ec.bin; done
b) while true; do /usr/local/lib/flimflam/test/connect-wifi GoogleGuest; done
...if flashrom reports success over and over again then this is good.
Change-Id: I7f32d5f1e4134896c857ee26f449a1fdd579d589
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29621
BUG=chrome-os-partner:12290
TEST=manual
From EC console,
rtcget
(wait a few sec)
rtcget
hibernate 3
(wait for wake)
rtcget
(hold power+refresh; wait for reboot)
rtcget
rtcset 20000
rtcget
(wait a few sec)
rtcget
Each rtcget should be a few seconds after the previous one.
Pull the battery and remove AC power. Then restore AC power and
rtcget
(wait a few sec)
rtcget
Should be close to 0. That is, it should have reset to 0 when power
was lost.
From root shell,
ectool rtcget
should match the time from rtcget, truncated to the nearest second.
ectool rtcset 30000
should set the time (do a rtcget to check).
Change-Id: I535097feb7af8aa6583c8ef50ade66bb19bdff8f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29349
Reviewed-by: Bill Richardson <wfrichar@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>
There were a number of problems resulting from i2c crashes,
particularly when trying to access the battery. The problem is that
the stack was overflowing on this particularly deep path, all the way
down to wait_status. This in itself was fine, but if there was a
timeout, debugging information would be printed to the uart, and that
function would cause an exception and restart the EC.
To fix it, I stripped the debugging CPRINTFs from wait_status. This
allows everything to work fine, but looses some information for
debugging. To allow future developers to still see what event the i2c
was waiting for, I added an additional variable to store it in, so that
it can be displayed/handled further up the stack.
BUG=chrome-os-partner:12245
TEST=Boot the machine using a Servo. On the AP's UART, run
"cros_test i2c" to start pounding the i2c bus. Then from the EC, run
"pmu 1000" and then "battery 1000" there should be no error messages,
exceptions, and the EC should not restart. Repeat this process with i2c
arbitration disabled (remove the flag in ./board/snow/board.h). You
should suffer no fatal errors. cros_test may report errors detected,
but the EC will never crash, restart, or throw exceptions. These other
errors are the EC and the AP stepping on each other's toes now that you
have disabled arbitration.
Change-Id: Idd2f017d3557652bf3e8536c4ac776c1f70319cb
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29351
Reviewed-by: Simon Glass <sjg@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>
When we wake up from a deep sleep mode, the system timer clock might
have been stopped. We need to be able to set using another time source
(e.g. the RTC).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=make BOARD=snow && make BOARD=link
on Snow, on a software implementing STOP mode, check the system time is
still accurate by comparing it to the wall clock.
Change-Id: Ieddbb423d052c7aceb398470866b25b25a74c0a0
Reviewed-on: https://gerrit.chromium.org/gerrit/29314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The i2c timeout error message is false positive warning. It happened
when wait_status() function got a good result, but took too long to
complete (> 1ms).
This warning message can be removed safely.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:9759,12222
TEST=none
Change-Id: I2a670b76a5d741dc82ea59eacc233c4719eb3263
Reviewed-on: https://gerrit.chromium.org/gerrit/29254
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
If it's pressed, need to track that or we'll ignore the release. And
then we'll leave the power button signal asserted to the PCH, and
it'll shut down 4 seconds after the power button was pressed.
BUG=chrome-os-partner:11971
TEST=hibernate 10, then press power button for ~0.5 sec, then release
system should boot normally
Change-Id: Ibb9b8a8827cca6c81bac06dc9543de1a76fa5aad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28863
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, if you used Esc + Reload + Power to reboot into recovery
mode, you would be stuck in it until you manually rebooted the EC with
"Reload + Power." This was because the button combo set a switch that
was never un-set. To fix it, the keyboard_scan function now sets a host
event, that is serviced once, and then cleared. As a result, the next
time you reboot after triggering recovery mode, it should boot as before
you triggered recovery mode.
BUG=chrome-os-partner:10889
TEST=Boot device in normal mode. Press Esc + Reload + Power, and boot
from usb. Power off the device and remove the usb media. Power on the
device again, and there should be no recovery screens during the boot
process. Next, repeat these same steps, but from starting in developer
mode. After recovery, when you reboot, the device should return to
developer mode.
Change-Id: Idcb8dde6f8ba5f680f4d34e61ae0d12992281cbb
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28710
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ARM EC was being rebooted when both the power and one of several other keys
were pressed. (LCtrl, Tab, Reload, t, [, ], y, Dim Screen and Mute) It should
only do this when the key combo PWR + Reload is pressed.
To fix it, keyboard scanning is disabled whenever the power button is
pressed. It locks a mutex indicating that scanning should be disabled,
and the main keyboard scanning task blocks on the step where it sets up
the keyboard and waits for the mutex to unlock.
BUG=chrome-os-partner:10889
TEST=Pick one of the troublesome keys. First press it, then quickly
press the power button. Then press the power button followed
by the troublesome key. Repeat this process several times for each key,
it should not reset the system.
Press power + reload, this should still reset the system.
Pressing and holding power should initiate a shutdown.
Change-Id: Ib60d2ebbb57eb8a3c135662514ec622c37a7eb07
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28402
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This removes a bunch of unnecessary typecasts, since you can assign
to/from void * without them. This also uncovered a few cases where
const was being cast away for the input params; now fixed.
BUG=none
TEST=mkbp hash from u-boot console, and/or system boots ok
Change-Id: Ic314b9d2ca06226ea8a09703ef5c1a912eb7146d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28500
Otherwise, EC software sync protects the entire firmware except in recovery mode, regardless of the WP pin.
BUG=chrome-os-partner:11847
TEST=boot with WP enabled but RO-at-boot disabled; flashinfo should show
entire flash still writable
CQ-DEPEND=28444
Change-Id: I58d60adfaa952b127e8695213f95f6da0e34821d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28445
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When updating the EC and BIOS, we have to run for some times the new EC
with the old BIOS (after we have upgraded the first half of the EC and
before rebooting the machine), let's handle the ACPI request so the
kernel is not sending them into a loop triggering a reboot of the
machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:11821
TEST=update a Link EVT using "chromeos-firmware --mode=factory" from
current BCS binaries (EC v1.1.104-b8d7d8f / Firmware 2476) to next
candidates ( EC v1.1.301 / Firmware 2657).
Change-Id: I115a42e6c33c143cbdc38341dcf7e0f61a8bd771
Reviewed-on: https://gerrit.chromium.org/gerrit/28409
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
