mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-30 10:31:02 +00:00
29af184eb7a79d2183307fbd4b685537aec3470b
Currently host_command_reboot() casts the supplied buffer and access it directly. This works until about half-way thru the function when the same buffer potentially gets overwritten when sending the response code to the host. This CL gets around that by copying the reboot parameters into a separate buffer. Signed-off-by: David Hendricks <dhendrix@chromium.org> BUG=none TEST=Tested using 'ectool reboot_ec' on Snow (see below) Before, EC console displayed "[Executing host reboot command]" and ectool showed no actual change (reboot command was being overwritten with EC_REBOOT_CANCEL): localhost ~ # ectool version | grep 'Firmware copy' Firmware copy: RO localhost ~ # ectool reboot_ec A localhost ~ # ectool version | grep 'Firmware copy' Firmware copy: RO With the patch applied, the EC console shows the EC boot-up messages and ectool confirms that the jump took place: localhost ~ # ectool version | grep 'Firmware copy' Firmware copy: RO localhost ~ # ectool reboot_ec A localhost ~ # ectool version | grep 'Firmware copy' Firmware copy: A Change-Id: I8aca8d468d1125c3fb8d320ec0fb79d2822b0b20 Reviewed-on: https://gerrit.chromium.org/gerrit/26998 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Commit-Ready: David Hendricks <dhendrix@chromium.org>
- 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_NEW_STACK
When reporting a panic, change to a completely new stack. This might
help get a useful trace out a situation where the stack or stack
pointer has been corrupted.
- 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
Description
Languages
C
64.7%
Lasso
20.7%
ASL
3.6%
JavaScript
3.2%
C#
2.9%
Other
4.6%