We map the raw DID value to chip name in EC. If the raw value is not in
the mapping table, EC just returns empty string and we lose this
information from host side. Let's return raw DID value like
"Unknown-10ea".
BUG=chrome-os-partner:15519
TEST=remove 0x10ea from the mapping and check 'mosys -k ec info' shows
'Unknown-10ea'.
BRANCH=link
Change-Id: I9399f44ab40db02202ee03ba3f988f3ece010d9f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36305
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This accidentally got disabled when printing keyboard scan state was
turned off by default.
BUG=chrome-os-partner:15466
BRANCH=link
TEST=alt+volup+R should reboot system
Then from console, ksstate on
Then press keys; KB state should print on console
Change-Id: I7d410b56210fda0c73c65d9d76ccc7b4e873516c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35971
Reviewed-by: Simon Glass <sjg@chromium.org>
This matches Silego's recommendation as of 10/18.
BUG=chrome-os-partner:14687
BRANCH=link
TEST='reboot cold' repeatedly from EC console (or 'ectool reboot_ec
cold' repeatedly from root shell), then check that Power+Esc still
reboots the system.
Change-Id: Ief2962bf66a947e83dfe934e45e18dc37d6ba326
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35968
Reviewed-by: Simon Glass <sjg@chromium.org>
This fixes a problem where flash writes would fail because the source
buffer was not 32-bit aligned.
BUG=chrome-os-partner:15435
BRANCH=link
TEST=from a root shell,
localhost ~ # echo 1234567812345678123456781234567 > /tmp/data
localhost ~ # ls -l /tmp/data
-rw-r--r-- 1 root root 32 Oct 17 17:28 /tmp/data
localhost ~ # ectool flasherase 0x3a000 0x4000
Erasing 16384 bytes at offset 237568...
done.
localhost ~ # ectool flashwrite 0x3a000 /tmp/data
Reading 32 bytes from /tmp/data...
Writing to offset 237568...
done.
If that doesn't crash, the fix works (prior to this fix, that would
reboot the system).
Change-Id: I8d197e7ef7a1c74825916bd788f7d450088a55cc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35916
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The keyboard scan module generates a lot of debug output when the user
is typing on the keyboard - enough so that switching to the console,
logging in as root, and typing 'ectool console' flushes the EC's
console output buffer of any useful data. Default printing this to
off. Add a new 'ksstate' command which will print the current
keyboard scan state or toggle printing off/on.
This is important for debugging LPC communication failures.
BUG=chrome-os-partner:13819
BRANCH=link
TEST=manual
- Boot system
- Type on keyboard. At EC console, should not see KB state: output
- Hold down space bar.
- At EC console, type 'ksstate'. Should print:
ksstate
[20.943886 KB debounced : -- -- -- -- -- -- -- -- -- -- -- 20 --]
[20.945215 KB prev : -- -- -- -- -- -- -- -- -- -- -- 20 --]
[20.945568 KB debouncing: -- -- -- -- -- -- -- -- -- -- -- -- --]
Keyboard scan state printing off
- Release space bar
- At EC console, type 'ksstate on'
- Type on keyboard. Should see KB state: output
- At EC console, type 'ksstate off'
- Type on keyboard. At EC console, should not see KB state: output
Change-Id: I4343b7b777fd13057b3222eeba77ed099c5e5a93
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35843
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This works around a potential LM4 chip problem where edges on the FRMH
status bit don't always trigger interrupts. The workaround is to look
at FRMH for each channel in the interrupt handler rather than the
interrupt status, and to trigger the interrupt every 250ms to sweep up
any missed writes. We already do this for port 80 writes; this just
extends the workaround to all channels.
BUG=chrome-os-partner:13965
BRANCH=link
TEST=manual
- boot system
- EC console should show a number of HC lines for host command
- EC console should show a number of ACPI queries
- switch to root shell; keyboard should work
- ectool version should work
Change-Id: If02d685519c69ee88c055c8374a6c655a277e637
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35871
Reviewed-by: Simon Glass <sjg@chromium.org>
During the debounce refactor we unintentionally adjusted the behavior
of special keys so that they are no longer swallowed (as per commit
9332d76). The LM4's keyboard behaves differently so this code cannot
be brought over as is.
Bring back the required behavior for STM32.
BUG=chrome-os-partner:14496
TEST=hit alt-volume_up-r keys together. See that the AP does not see
this keypress in U-Boot by checking the EC console has no 0x60 messages.
BRANCH=snow
Change-Id: I043fbba4d9be5941e550257b99bdb2137792c133
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This works around a problem where the Silego chip doesn't cleanly
reset for short hibernate durations.
BUG=chrome-os-partner:14687
BRANCH=link
TEST=ectool reboot_ec cold (~100 times), then check if power+refresh still
reboots the system
Change-Id: I14098940da9331856dd061a56a60a47c9a1cf1f8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34832
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, any command which set the fan duty manually would leave
the PWM RPM controller disabled. Setting the fan back to auto mode
via 'ectool autofanctrl' or 'autofan' or 'ectool pwmsetfanrpm'
wouldn't turn the controller back on. Now it does.
BUG=chrome-os-partner:14307
BRANCH=link
TEST=manual
- Reboot in recovery mode and wait for INSERT screen
- From EC console
fanduty 100 -> fan turns on all the way
faninfo -> mode is duty
fanset 6000 -> fan turns down to a lower level
faninfo -> mode is rpm
fanduty 0 -> fan turns off all the way
faninfo -> mode is duty
(wait a min or so for the system to heat up)
autofan -> fan turns on
faninfo -> mode is rpm
- Reboot normally
- From root shell
ectool fanduty 100 -> fan turns on all the way
ectool pwmsetfanrpm 6000 -> fan turns down to a lower level
Change-Id: I3b07e8b49500f5f8a42f20909d2869cf63987d6d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35335
Reviewed-by: Sameer Nanda <snanda@chromium.org>
The lid is flexible enough that it's possible to press keys by
squeezing the laptop. To keep this from waking the device from
suspend or powering it on, don't scan the keyboard or power button
when the lid is closed.
BUG=chrome-os-partner:15252
BRANCH=link
TEST=manual
- boot system
- use a magnet near the search key to trigger the lid-closed switch
- press space, then power. neither one should trigger resume
- remove magnet. system resumes
- space and power should work as expected again
- log out
- use magnet to trigger lid-closed switch (looking at EC console output is
handy here). system should shut down
- pressing power should not boot the system
- remove magnet; system will boot
- pressing power should work as expected again
Change-Id: I92080237b0a2f21774301df3d8e866878697b793
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35425
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Each I2C controller needs to use a fixed pair of DMA channels.
The former code was hardcoded for I2C2. We now use the board
configuration to decide between I2C1 and I2C2 DMA channels.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:15185
TEST=make BOARD=snow && make BOARD=spring && make BOARD=daisy
run on Spring and Snow and see we can communicate both with the PMU
(using "pmu" EC console command) and the AP (answering U-Boot host command)
Change-Id: Ifd6806205b443c623e3db09fb1a2d5804bb94214
Reviewed-on: https://gerrit.chromium.org/gerrit/35355
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The spring board doesn't have one and we doesn't want to mess up with
that pin.
When the POWERLED task is not present, let's de-activate cleanly that
code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14324
TEST=make BOARD=spring (no power_led.o compiled)
make BOARD=snow (power_led.o compiled)
make BOARD=link && make BOARD=bds
run on Snow and see the power LED working
Change-Id: Ib44f5df54ec4fdee1863814e6c7052fd6620fee8
Reviewed-on: https://gerrit.chromium.org/gerrit/35272
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously, if the AP took fan control, the EC would never take it
back. This meant the EC would leave the fan off even if the system
was sitting at the INSERT screen or booted an alternate OS.
BUG=chrome-os-partner:15189
BRANCH=link
TEST=manual
- boot system
- from EC console, fanset 0
- faninfo shows fan at 0rpm
- from root shell, crossystem recovery_request=123 && reboot
- wait a few mins
- faninfo should show fan spinning again
Change-Id: I534c9978194085467f1df6eae971c55d4e8083be
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35309
This prevents the fan from coming on loudly during resume.
BUG=chrome-os-partner:15187
BRANCH=link
TEST=manual
- power on system
- wait for it to heat up; type faninfo periodically from ec console
- when faninfo reports non-zero, type 'powerd_suspend' at root shell
- faninfo should now report Target: 0 rpm Enable: no
Change-Id: Ia5ee93c0f5c6626afd54a22d2996ab65cf8e3b18
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35303
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the need for a separate method to check sensor power, and
gets rid of temp_sensor.c knowledge of what powers each sensor.
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
- reboot
- within a second, type 'temps'; I2C sensors should return error 1
- type 'temps' again; all sensors should return data
- power off system
- type 'temps' again; I2C sensors and PECI should return error 8
- 'gpioset enable_vs 1'
- type 'temps' again; I2C sensors should return valid data; PECI should still
return error 8.
Change-Id: I17c353b3c483bc320769307c7715008ec729089b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35287
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This will be used in a follow-up CL to return specific error codes
(not powered, not calibrated, etc.)
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
Power on system.
'temps' should return all good temps.
Power off system (into S5)
Only ECInternal temp should work; others should return Error 1
'gpioset enable_vs 1' and wait a second
Now all the I2C temps should display good data, but PECI will still be error 1.
Change-Id: I925434e71653ad53ad76bad992a7a8fdeadb088c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35286
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, if a key was pressed after the last polling but
the interrupts were fully enabled, we were missing the edge.
So dropping the key press event and seeing only the key release.
Now we check if keys are down before waiting for the next interrupt,
if any, we re-start polling immediatly.
The row state reading code is unchanged, just moved to a function
in order to re-use it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
(Note: This patch was originally submitted in the firmware-snow-2695.B
branch, but needed some re-factoring to merge cleanly into ToT)
BRANCH=snow
BUG=chrome-os-partner:7484 chrome-os-partner:12179
TEST=type on the keyboard and do not see any missing key presses.
On instrumented board, record the the matrix scans with a logic analyzer
and stare at the waveforms.
Change-Id: I98dc4c3af9611a276b960887384a6304b91d8b30
Reviewed-on: https://gerrit.chromium.org/gerrit/35168
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is important to do because if we don't reset we could leave
the i2c bus in a wedged state (it's possible that whoever was
mastering us could have reset halfway through a transaction).
BUG=chrome-os-partner:14430
BRANCH=snow
TEST=From vt2 type: "echo bug > /proc/breakme" several times
and see good reboots. Check scope trace and see that reset of
i2c bus helped (SDA low for 100ms and then fixed).
TEST=Run hacky "repro" script from bug see that i2c doesn't get
wedged.
Change-Id: I57010dcc5f4baa63278b6a025d44f10f00eb9e9d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35115
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
This brings Randall's key debounce logic into STM32. We need to
rationalize the code, but for this morning...
This should fix problems with double keypresses and missing keypresses.
BUG=chrome-os-partner:12179
BRANCH=snow
TEST=manual
- type quickly; should work
- run your finger really quickly over the keyboard; should be able to
see keys which don't show up because you didn't press them long enough
- run your finger quickly from 1 to 0; numbers should show up in order
(some may be missing if you sweep too fast. there is a point where if
two keys are hit within 1.7ms of each other they can be swapped, but any
slower than that and they should never be out of order)
- mash your face into the keyboard to cause ghosting; should see only a few
keys pressed
Change-Id: I6b164a17de1b4dd698f9b45a3852fd3b6c084e0a
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34765
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Implement a command to allow getting and setting the keyboard
configuration.
BUG=chrome-os-partner:12179
TEST=manual
- use ectool to read all keyscan paramters
- use ectool to update flags to 0, see that keyboard stops working,
then set flags to 1 and see that it starts working again.
- use ectool to update scanning period to 100ms, see that it drops lots
of keys when typing
- use ectool to set fifo size to 1, see that the fifo no longer fills
up
Change-Id: I5afb3b48b1262a1570d7411ffd8b2e6ea3a65f6b
BRANCH=snow,link
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34635
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Experimentally it is possible to press a key on snow for only 4.8ms.
We should aim to scan more frequently to catch those who only just
touch the keys, or type very quickly.
It takes a little over 2ms to complete a keyboard scan at present.
We shold aim to reduce this, but for now, it seems safe to reduce the
default scanning frequency to 3ms.
BUG=chrome-os-partner:12179
TEST=manual
Type on keyboard on snow in browser, and see that we still get results
and the EC is stable.
Change-Id: I60827c33a58c34dd808504e58bca480bd61f5932
BRANCH=snow
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34634
Reviewed-by: Randall Spangler <rspangler@chromium.org>
At present the keyboard scan parameters are hard-coded, so changing them
requires a new EC image. This can be problematic if we want to adjust
the behavior of keyboard scanning since we must send an EC update.
Change stm32's keyboard scan to use run-time config. All parameters
and behavior should remain the same with this change.
The configuration is defined by ec_commands.h since we intend to create
a command to allow access to it. It does not seem worth defining a
separate structure within keyboard_scan at present, although if we
add a new version of the command in the future then we may want to
separate these.
BUG=chrome-os-partner:12179
BRANCH=snow
TEST=manual
Boot snow into U-Boot and Linux, try the keyboard, seeing that it seems
to work as before. This is a very subjective test.
Change-Id: Ie6160f1d73b983867b96f8ccb421853f6ec99524
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34633
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The masks were intended to be used to ignore certain keys in the matrix to
help with de-ghosting of keys. Since this is done on the AP anyway, there
really isn't any need for them. Punt.
BUG=chrome-os-partner:12179
BRANCH=snow
TEST=manual
Build and boot into kernel, see that keyboard still works.
Change-Id: I00d1b761d24ab503c66439b095a8336fff5d5db6
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34657
Previously, an edge on a keyboard row could be missed if it occurred
after the last scan, but before interrupts are enabled. Now we
explicitly check if any keys are down before waiting for an interrupt,
and if any are, we simply don't wait to scan.
BUG=chrome-os-partner:7484
BRANCH=link
TEST=the race condition's really tricky to hit
The best we can do for testing is to ensure that we ARE sleeping in
the normal case where no keys are held down. For that, don't press
any keys, and run 'taskinfo' from the EC console twice about 10 sec
apart. Both printouts should have virtually identical times for the
KEYSCAN task.
Change-Id: I4e0ef18a2d71d0a5d3655742bd49fc15afc4aaed
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34709
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
This should fix problems with double keypresses and missing keypresses.
BUG=chrome-os-partner:8826
BRANCH=link
TEST=manual
- type quickly; should work
- run your finger really quickly over the keyboard; should be able to
see keys which don't show up because you didn't press them long enough
- run your finger quickly from 1 to 0; numbers should show up in order
(some may be missing if you sweep too fast. there is a point where if
two keys are hit within 1.7ms of each other they can be swapped, but any
slower than that and they should never be out of order)
- mash your face into the keyboard to cause ghosting; should see only a few
keys pressed
Change-Id: I66e95c56d94cba16454ee2c37498deeb57f1a2c3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34697
Reviewed-by: Simon Glass <sjg@chromium.org>
This is a precursor to implementing proper keyboard debouncing, and
should have no functional effect; it's just refactoring.
BUG=chrome-os-partner:8826
BRANCH=link
TEST=manual
- power+refresh+esc -> recovery mode
- boot normally and type -> yaay, you can type
Change-Id: I828d2380c164c92330d725002379b6442894f41d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34567
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With this CL, if CONFIG_FPU is defined (only for Link, ATM), the EC task
switcher will enable CONTROL.FPCA and expect all stack contexts to include
floating point state as well as normal state (an additional 18 words).
To support this, we need to increase the allocated stack space for each
task. The stack sizes are already chosen empirically, so I'm just rounding
them up a bit.
BUG=chrome-os-partner:14766
BRANCH=Link
TEST=manual
There should be no noticeable change. If you run the EC command "taskinfo"
you'll see the increased size each thread's stack, but everything that was
working before should continue to work just fine.
The additional overhead required to load and store another 18 words on each
context switch is not really measurable (I tried).
Change-Id: Ibaca7d7a2565285f049fda6906f32761e83207af
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34391
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This fixes a problem where a very short power button press would
disable scanning, but not debounce to down so we'd never have a
debounced release to re-enable scanning.
BUG=chrome-os-partner:14678
BRANCH=link
TEST=tap power button very quickly, then see if keyboard still works
(may need to repeat that a few times to be sure it always works)
Change-Id: I3dd3d3f2d892f309a507463d7ad6accf32df30c4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34225
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
This adds basic ADC support for multiple channel conversion.
BUG=chrome-os-partner:14316
BRANCH=none
TEST=1. Boot on snow.
2. Use keyboard signal as input. Check read value changes as input
signal changes.
Change-Id: I3c15c37446fa9273d098f6d581573c11ced45b5e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33883
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We need different memory size configuration in different application.
Let's export the memory size option to DMA function parameters.
BUG=chrome-os-partner:14316
TEST=Boot on snow. Check I2C host command works.
BRANCH=none
Change-Id: I30481ddf86a1526d517961e009898642ecdd649a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If the key combination matches the warm reboot sequence
(alt-volume_up-r), do not forward these keys to the AP. If the keys do
get forwarded, the AP's key handler can race with the EC's GAIAPOWER
task and unpredicatable things may happen.
BUG=chrome-os-partner:14496
TEST=hit alt-volume_up-r keys together. This should cause the system to
reboot. If in dev mode, check the contents of /dev/pstore/console_ramoops
file -- the contents should be from the previous boot.
BRANCH=snow
Change-Id: Ida08bf10c593c75186f472721992a52015e4bf24
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33916
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This manifested as the lightbar task missing transitions between CPU states.
The underlying cause was that when a task talks over the I2C bus, the I2C
communication was using the task scheduler to wait for an interrupt to
signal completed I2C traffic without blocking the other threads, but while
doing so it was not preserving pending events. This CL seems to fix it.
BUG=chrome-os-partner:12431
BRANCH=all
TEST=manual
The original bug is tricky to reproduce without adding some delay to the I2C
task code, but you can do it. Boot the CPU, then from the EC console
repeatedly alternate these two commands:
lightbar seq s0
lightbar seq s3
You should see the lightbar pattern turn off and on, but occasionally you'll
type the command and the EC won't change the pattern.
With this change applied, it should *always* work.
Change-Id: Ie6819a4a36162a8760455c71c41ab8a468656af1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33805
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
