Loop on FRMH bit set in the interrupt handler. This has 2 benefits:
1) FRMH is checked every LPC interrupt. So if port 80 gets stuck, any
LPC activity like keyboard or host commands will unstick it.
2) Bursts of rapid writes to port 80 are captured more accurately.
This also seems to prevent the port 80 channel from getting stuck.
There's a small drawback that if the host spams port 80 non-stop for
several seconds it can watchdog the EC, but if the host has access to
write to I/O ports it could already accomplish a similar result simply
by writing the 0xd1 reboot command to the host interface.
BUG=chrome-os-partner:12349
BRANCH=link
TEST=manual
1. From a root shell, 'ectool port80flood' repeatedly (20x or so).
2. Reboot. Port 80 codes should still be captured.
Change-Id: I7a51dfe6a384a0d08cfeb91a539217fc59488637
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33444
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This works around a LM4 bug where the LPC module stops triggering
interrupts for a channel if bytes are written too rapidly to that
channel. This should only affect port 80 because other channels use
busy-status-handshaking to avoid flooding the EC.
BUG=chrome-os-partner:12349
BRANCH=link
TEST=manual
1. From a root shell: ectool port80flood
2. Repeat until the EC console stops showing port 80 codes coming in
3. From a root shell: reboot
4. Port 80 codes should be printed by EC as the BIOS boots
Change-Id: I3b3463ce668727cad9900b576fdeb531986a415e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33142
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The old spi driver has atrophied in various ways. It doesn't support
the new protocol and does not build either.
Rewrite the driver to:
- Use dma for reception (rather than just reception)
- This makes message reception more robust and allows us to process
the new multi-byte commands
- Add timeouts for rx and tx so that we don't wait forever
- Increase buffer sizes to deal with new larger messages
- Always send a preamble byte regardless of SPI clock speed
(previously above 10MHz we sometimes miss this)
- Use the NSS line to delineate transactions. When it drops, a
transaction is starting. When it rises the transaction is immediately
terminates regardless of state. This keeps the AP and EC in sync even
in the event of timeouts, bus errors and other oddities.
- Implement the new protocol which has a checksum, version byte, etc
- Set up tx dma in advance and kick it when ready, thus ensuring that
a message body is always attached immediately after the preamble
- Use the new host_cmd_handle_args structure, which makes things much
easier for us, since we don't need globals, and can use the
send_response handler to know when a slow command is complete.
- Handle the new type of 'slow' commands properly
BUG=chrome-os-partner:10533
TEST=manual
build and boot to kernel on snow
Change-Id: I11767d1a6f045a86f6c9a0b4b1e943b660e4da33
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32076
Reviewed-by: Randall Spangler <rspangler@chromium.org>
From time to time, the next timer deadline might have just expired
aftering entering the idle loop, so the delay might be negative, it's a
bad idea to use an unsigned variable...
Now, in the uncommon case where the timer is expired, the next_delay is
negative, so we use the "normal" wfi path and as the timer interrupt is
pending in that case, we return directly.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:13364
TEST=On Snow, plug a servo on EC serial console,
shutdown the machine, unplug AC and wait for several hours.
Observe we no longer have spurious watchdog reboots.
BRANCH=snow
Change-Id: I40c7aa0fc7c1d6f9a5efaa1e7fc6615ed457196b
Reviewed-on: https://gerrit.chromium.org/gerrit/33149
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Haven't found a use for these, so remove to reduce code size (reduces
binary by 2KB) / complexity.
These are still test-compiled on BDS so they'll be ready if needed.
BUG=chrome-os-partner:11232
BRANCH=link
TEST=build and boot firmware. 'help' should not show eeread/eewrite commands
Change-Id: I0f2e41e21efcbbb0967a5b85b7c8a2ff8147460e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33112
Reviewed-by: Simon Glass <sjg@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>
The code for warm reboot is overly specialized, and makes it hard to
add other key cominations for testing.
BUG=chrome-os-partner:13763
BRANCH=link
TEST=manual
1. boot system
2. hold down (in order) R+T+alt+VolUp. System does not reboot.
3. let go of T (so only R+alt+volup are pressed). System reboots.
Change-Id: I14cdb7f790e8a772712085a77eaf4299487788db
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32439
Reviewed-by: Simon Glass <sjg@chromium.org>
This has been deprecated in favor of a host event to trigger recovery mode.
BUG=none
BRANCH=link
TEST=manual
1. Power+Esc+Refresh -> recovery mode
2. Press power -> off
3. Press power -> boots normally (NOT recovery)
Change-Id: I9288785ce1c0a446867dc54d1b6ec2f556896688
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32426
Reviewed-by: Simon Glass <sjg@chromium.org>
Instead of how it is now, where the boot key combinations are only
tested if it was a keyboard-controlled reset. This is important for
testing/debugging EC software sync, which has a tendancy to blow away
your RW EC as soon as you flash a test EC and it reboots. Now you can
hold down refresh+downarrow while flashing.
This does not affect keyboard-controlled dev switching, since that's
done in the AP after the EC boots. It also does not add any new key
combos, just makes it possible to trigger the existing ones without a
Silego reset.
BUG=chrome-os-partner:13753
BRANCH=link
TEST=manual
1. Boot normally. Works.
2. Power+Refresh. Boots normally.
3. Power+Refresh+Esc. Boots to recovery.
4. Power+Refresh+Down. EC reboots, system powers down.
5. Hold down Esc and reboot from EC console. Boots normally.
6. Hold down Refresh+Esc and reboot from EC console. Boots to recovery.
Change-Id: Iabe4fd13589428a40b83f591ea679cbc6f83959d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32425
Reviewed-by: Simon Glass <sjg@chromium.org>
Increase stack size slightly for vboot hash task since the vboot
SHA256 function allocates ~300 bytes of stack data. Reduce stack size
for watchdog, power LED, and a few other tasks with simple call trees
where we can be sure an error path isn't going to blow past the
reduced stack.
This frees up ~1KB of RAM on STM32.
BUG=chrome-os-partner:13814
BRANCH=all
TEST=boot system; shmem should show more unused RAM; taskinfo should show
tasks still have unused stack
Change-Id: I47d6b77564a0180d15d86667cc0566a8919b776e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32608
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously, the i2c init code would only preform a software reset of the
i2c peripheral it is initializing when it was already BUSY. It turns
out it's always BUSY and the init functions are now used in two other
places where they always want the software reset as well, so this pulls
out the conditional, and makes it always do it.
BUG=chrome-os-partner:13388
TEST=Standard i2c stress tests. Running a loop of i2cdumps from the AP
while looping i2c transactions on the EC run without any errors. Even
across multiple reboots, and jumping back and forth from RO to RW on the
EC via sysjump while the AP is still stressing the bus.
BRANCH=snow
Change-Id: I6b3aaae0042844033bb04cf5cb4171c8be041ad9
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32397
Reviewed-by: Simon Glass <sjg@chromium.org>
This would improve boot speed when compared to storing in eMMC because
initialing eMMC is slow.
So far other platforms do not have this need because CMOS is quite
efficient; thus it is left unimplemented in lm4.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:10660,13094
TEST=On Snow, see VbNvContext is preserved across power cycles (you have
to patch U-Boot to test this)
Change-Id: If5072c678b87bc47a3a82a1dff2afa3896304f36
Reviewed-on: https://gerrit.chromium.org/gerrit/31832
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
The I2C peripheral on the EC can get confused if there is a very
specific kind of noise introduced to the line. This can be manifested
by jiggling the battery jack. It gets the I2C into a state where
everything seems fine outwardly, but the device refuses to even transmit
START bits on the line. It appears that one of the stray pulses on the
i2c bus gets the device off set from the actual bytes, leaving it
misinterpreting everything and waiting forever. In this case, there is
only one way to recover (as you can't directly access these aspects of
the internal state) and that is to do a software reset of the i2c
peripheral.
Here I add some code to check for the condition where the EC was unable
to even send a START bit, and do a software reset of the i2c to recover.
BUG=chrome-os-partner:13161
TEST=With a faulty-battery-jack-board: Boot board, test that i2c works
by running "pmu" on the EC console. Jiggle battery jack repeatedly
until errors are displayed on console. Try to run pmu again. Make sure
that it recovers gracefully, and do this many times.
BRANCH=snow
Change-Id: I91b8ef0c6f6079bc63f4a6a1bc91f67d19db9fc0
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32286
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If the EC got reset while some device on the bus was midway
through a transaction, the bus may we wedged and all of our i2c
transactions will fail. Try our best to unwedge the bus at
bootup. Do this even if the bus doens't look wedeged because
some device on the bus may be in a quiescent state at the moment
but be waiting to pounce on the bus when it sees the clock start
running.
BUG=chrome-os-partner:13378
TEST=Capture scope trace in normal bootup
TEST=Capture scope trace in failure bootup with an extra print
statement in the code when scl/sda were not high at bootup. Forced
this case by looping i2c transactions to tpschrome and rebooting
midway through.
BRANCH=snow
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
(Note: Credit for this patch goes to Doug, I just uploaded the
initial work-in-progress version to gerrit --dhendrix)
Change-Id: I8da69b5294160048f91461159c039f8f2093e971
Reviewed-on: https://gerrit.chromium.org/gerrit/32168
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
The UART probably shouldn't have such a high priority. Reduce it to
below that of comms driver interrupts.
BUG=none
BRANCH=none
TEST=manual
Boot and see that UART console still functions
Change-Id: If906c9c4c37617d076ad8415d126b50f52d8b09e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32077
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There are a number of ways for the i2c to fail, and some are quite
rare and have thus been overlooked. It's easy enough to handle these
rationally, but we have to check for them. This checks that the i2c
peripheral is actually in slave mode when it gets a slave event firing
(stopping it from accidentally sending garbage on the tail end of
another request) and makes sure a STOP bit is sent in the event that the
BUSY signal isn't set at the moment we check it (if we check it at the
moment that it is sending a 1, it may not be set). Finally, if the i2c
can't send a STOP bit, the peripheral is reset to get it back to a sane
state, specifically it needs to not be stuck in master mode forever.
BUG=chrome-os-partner:13380
TEST=Boot machine normally, from AP run "while true; do ectool version;
done" to start a loop of the long transaction that sends lots of
spurious reads too. Then on the EC, run "pmu 10000" and then "battery
1000" to stress the bus from all sides. Once the EC is done, stop the
AP's side of the stress test, and make sure the bus is still
functioning. Tested the resetting, by making it reset the peripheral
every 150 times, and confirmed that the following transfers work just fine.
BRANCH=snow
Change-Id: I265b3cddd25e1fd6ab4e8cf9c7290c875fad89f8
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32188
Reviewed-by: Doug Anderson <dianders@chromium.org>
Added a warm reboot key combination that resets the CPU while preserving
RAM contents. This will be helpful in debugging CPU/OS hard hangs since
in conjunction with PSTORE_CONSOLE in the kernel, the kernel log
messages from the previous boot will be preserved.
BUG=chrome-os-partner:12780
TEST=reboot the system using alt-volume_up-r key combination. Upon
rebooting, check pstore contents with "cat /dev/pstore/console-ramoops"
and ensure that they are same as dmesg from the previous boot.
BRANCH=link
Change-Id: I0ec835a4646f442997c04dc3a086d4fac0cf01cf
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31992
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This re-factors i2c initialization to simplify it and make it follow
the correct order. This is intended to fix a bug where the I2C lines
could be driven low for no good reason on EC startup, potentially
causing issues with other devices.
The ordering should be:
1. Setup pins as inputs on EC startup.
2. Initialize I2C module(s)
3. Re-configure pins as alternate function.
(Thanks to dianders for pointing out this bug)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13443
TEST=Tested by examining scope traces during EC reboot
Change-Id: Ibb845f3fd538da387132b1c822929f8613de077d
Reviewed-on: https://gerrit.chromium.org/gerrit/31647
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
gpio_set_alternate_function() for STM32F is not used, and even if
it were it would be incorrect. So for now it just takes up space.
Unlike STM32L, alternate functions rely on toggling bits in AFIO
remapping registers rather than setting a simple AF number. This
would make writing a working version of this function trickier,
and it may not be worth the effort.
Signed-off-by: David Hendricks <dhendrix@chromum.org>
BRANCH=snow
BUG=none
TEST=locally compiled for snow
Change-Id: I2ce1e7aba2760a94819500af4e322812f3346ad3
Reviewed-on: https://gerrit.chromium.org/gerrit/31630
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This prevents the host from rewriting them during the checksum operation.
BUG=chrome-os-partner:13202
TEST='ectool version' should still work
BRANCH=link
Change-Id: Ib44f45b027c0a54ba40f70052728ba427dc71849
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31511
Reviewed-by: Simon Glass <sjg@chromium.org>
Added a warm reboot function that reboots the AP while preserving
RAM contents. This will be helpful in debugging AP/OS hard hangs since
in conjunction with PSTORE_CONSOLE in the kernel, the kernel log messages
from the previous boot will be preserved.
BUG=chrome-os-partner:13249
TEST=1. From EC console issue the "warm_reboot" command. Upon rebooting
"cat /dev/pstore/console-ramoops" and ensure that the contents are dmesg
of previous boot.
2. Reboot the system using alt-volume_up-r key combination. Upon
rebooting, check pstore contents in the same manner as case#1 above.
BRANCH=snow
Change-Id: Ic8f0415da6182f4c1bc2d35b91302ceda5c19569
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31523
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
At present GPIOs must be staticly defined in a table. This is efficient
but inflexible, and requires error-prone and correponding #ifdefs both
in the board's gpio.h and gpio.c files.
Create a GPIO_UNSET option for GPIOs. This allows them to be assigned
an enum value, but have the actual use under program control.
BUG=chrome-os-partner:13064
BRANCH=snow,link
TEST=manual
build and boot on snow with later changes. See the AC power GPIO does
not change when un/plugging power.
Change-Id: Iab58275923d7d6cfce62c890b5db9b6758279a4c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31302
Reviewed-by: David Hendricks <dhendrix@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>
use the watchdog instead of the hibernation mode and RTC wake-up to
accomplish the hard reset.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:13126
TEST=on Snow, in U-Boot console, type "mbkp reboot cold" and see the AP
rebooting properly.
BRANCH=snow
Change-Id: Ic8b83f033e9dd4ccf1dff664226bf0ae6b9c47e5
Reviewed-on: https://gerrit.chromium.org/gerrit/31373
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
At the moment we don't seem to have any pull downs configured,
but they wouldn't work. That's because:
* GPIO_PULL_UP => 0x0006
* GPIO_PULL_DOWN => 0x0002
...so if we've got GPIO_PULL_DOWN in flags and then we run
the test "if (flags & GPIO_PULL_UP)", we'll actually test TRUE.
Oops.
BUG=None
TEST=Code inspection.
BRANCH=snow
Change-Id: Ie46ae291fe7edfc9f5237cf8bba3791de9755c5b
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31278
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
