mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-28 02:35:28 +00:00
f3c88fa1ab
Support the keyscan test functionality on stm32. Note: This is enabled by default so that it continues to build. But it is unlikely that we will want this in a shipping image. I suggest we add the facility for a dev build. Secondly, the stack has to be larger due to a printf (which admittedly I could just remove). Should we make the stack size conditional on the CONFIG? Seems a bit ugly, on the other hand we don't want to waste IRAM. BUG=chrome-os-partner:12179 BRANCH=none TEST=manual for now: On snow: ./ectool keyscan 20000 key_sequence.txt See that the test passes. Change-Id: Ic441ca0bde1be9589a924374605e2f146d16f423 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35118
84 lines
2.6 KiB
Plaintext
84 lines
2.6 KiB
Plaintext
- EC Lib
|
|
|
|
This wraps Blizzard driverlib and implements the EC chip interface defined
|
|
by Google. See below diagram for architecture.
|
|
|
|
|
|
+--------------------+
|
|
| Host BIOS/OS |
|
|
+--------------------+
|
|
|
|
---- host interface ----
|
|
|
|
+--------------------+
|
|
| Google EC features |
|
|
+--------------------+
|
|
|
|
---- chip interface ---- The interface is defined in
|
|
src/platform/ec/chip_interface/*.
|
|
+--------------------+ But the real implementation is in EC Lib.
|
|
| EC Lib |
|
|
+--------------------+
|
|
| Blizzard low level |
|
|
| driver, the |
|
|
| driverlib. |
|
|
+--------------------+
|
|
|
|
|
|
Build Options
|
|
=============
|
|
|
|
- CONFIG_WATCHDOG_HELP
|
|
|
|
Try to detect a watchdog that is about to fire, and print a trace.
|
|
This is needed on STM32, where the independent watchdog has no early
|
|
warning feature and the windowed watchdog has a very short period.
|
|
|
|
- CONFIG_PANIC_HELP
|
|
|
|
Report extra information about a panic, such as the fault address,
|
|
here shown as bfar. This shows the reason for the fault and may help
|
|
to determine the cause.
|
|
|
|
=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
|
|
r0 :0000000b r1 :00000047 r2 :60000000 r3 :200013dd
|
|
r4 :00000000 r5 :080053f4 r6 :200013d0 r7 :00000002
|
|
r8 :00000000 r9 :200013de r10:00000000 r11:00000000
|
|
r12:00000000 sp :200009a0 lr :08002b85 pc :08003a8a
|
|
Precise data bus error, Forced hard fault, Vector catch, bfar = 60000000
|
|
mmfs = 00008200, shcsr = 00000000, hfsr = 40000000, dfsr = 00000008
|
|
|
|
- CONFIG_ASSERT_HELP
|
|
|
|
Report assertion failures in a vebose manner to aid debugging. When
|
|
enabled an ASSERT() which fails will produce message in the form:
|
|
|
|
ASSERTION FAILURE '<expr>' in function() at file:line
|
|
|
|
- CONFIG_CONFIGURE_BOARD_LATE
|
|
|
|
Define this to call configure_board_late() after initial system init
|
|
is complete (and after GPIOs are set up).
|
|
|
|
- CONFIG_AC_POWER_STATUS
|
|
|
|
Monitor the state of the AC power input and drive out a GPIO to
|
|
the AP indicating this state. The GPIO will be driven low when
|
|
AC power is not connected, and high when it is connected. This
|
|
uses GPIO_AC_STATUS for this purpose.
|
|
|
|
- CONFIG_PMU_FORCE_FET
|
|
|
|
Force switching on and off the FETs on the PMU controlling various
|
|
power rails during AP startup and shutdown sequences.
|
|
This is mainly useful for bringup when we don't have the corresponding
|
|
sequences in the AP code.
|
|
|
|
- CONFIG_KEYBOARD_TEST
|
|
|
|
Turn on keyboard testing functionality. This enables a message which
|
|
received a list of keyscan events from the AP and processes them.
|
|
This will cause keypresses to appear on the AP through the same
|
|
mechanism as a normal keyboard press.
|
|
|