All of these were defined on all but a few platforms, and those
explicitly #undef them. So define them as enabled by default in
config.h so the board.h files are cleaner.
No functional changes; just rearranging/renaming config constants.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; FEATURES=test emerge-falco chromeos-ec
Change-Id: I1201a1472ae29641e9e219c2a0347691ca64cd28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63102
Reviewed-by: Vic Yang <victoryang@chromium.org>
The struct was changed in commit 74c34bbad, but the struct version was
left as 1. We need to uprev this so the data returned by host command is
useful.
BUG=chrome-os-partner:16901 chrome-os-partner:20548
TEST='ectool panicinfo' with new and old struct. Compare output with
output from console command 'panicinfo'.
BRANCH=None
Change-Id: I4df3142497dc5ee21d100c4cb8118fb7a0ce7a7e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60314
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
When it was a naked call, if it doesn't jump somewhere, it just
falls through to whatever code happens to be next. Which happened to
re-enable bus faults - meaning that only the first fault was being
ignored. That's a problem for flash protection on STM32, where writes
to potentially-locked key registers come in pairs.
BUG=chrome-os-partner:19564
BRANCH=spring
TEST=manual, on pit:
1. Hack in a igbusfault console command to call ignore_bus_fault()
2. igbusfault 1
3. ww 0x40023c0c 0xdeadbeef -> no fault
4. ww 0x40023c0c 0xdeadbeef -> still no fault
5. igbusfault 0
6. ww 0x40023c0c 0xdeadbeef -> exception and reboot
Change-Id: I5cf74b06a76ebf0176a2905924be87b3d1c825ce
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55572
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CPU creates an exception frame on the main stack instead of the process
stack when the exception happens in a handler's context. So, we need to
save both msp and psp, and pick the right one to locate the exception frame.
Tested by marking the stack (as you see in the dump below) then triggering
divzero in svc_handler.
> crash svc
=== HANDLER EXCEPTION: 03 ====== xPSR: 6100000b ===
r0 :00000000 r1 :0000e237 r2 :000015cf r3 :000015cf
r4 :00000001 r5 :22222222 r6 :11111111 r7 :0000df01
r8 :00000000 r9 :2000545e r10:00000000 r11:00000000
r12:0000000d sp :20000fb8 lr :000055d7 pc :00000b40
Divide by 0, Forced hard fault
mmfs = 2000000, shcsr = 70080, hfsr = 40000000, dfsr = 0
=========== Process Stack Contents ===========
20002738: 11111111 22222222 33333333 44444444
20002748: 00000000 000003ad 000003c0 81000000
20002758: 00000000 0000557d 0000557c 21000000
20002768: 00000000 00000000 00000000 00000000
Rebooting...
BUG=chrome-os-partner:16901
BRANCH=none
TEST=mentioned above
Change-Id: I3ca08a1df20375953552b3dc926350e262b78b2a
Signed-off-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47495
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This removes the duplicate uart_emergency_printf() vs. panic_printf()
/ uart_emergency_puts() vs. panic_puts() implementation and saves
~0.5kb of code size.
The other significant change is that uart_flush_output() is now smart
enough to determine if it's in an interrupt; if so, it will spin-flush
the output buffer instead of waiting on the uart interrupt. This
removes the need for a separate panic_flush().
BUG=chrome-os-partner:15579
BRANCH=none
TEST=crash unaligned; should print well-formatted crash dump
Change-Id: Ifae756203dd1881806be563308077c1d68302e1f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36695
This only adds support in the EC; it doesn't add an ectool command.
We'll add that later. This also fixes a bug where the reserved byte
in the panic data structure wasn't being set to 0.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. crash unaligned -> system crashes
2. hostcmd 0xd3 -> returns a hex string 01010100...506e6321
3. hostcmd 0xd3 -> returns a hex string 01010500...506e6321
Change-Id: I1de8e19c44c835055d893986b42d152dc704c35f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32183
Reviewed-by: Simon Glass <sjg@chromium.org>
Jump data now precedes the panic data, if any, in memory.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. boot system
2. sysjump rw --> display should stay on and keyboard should still work
(this verifies jump data is properly read across sysjump still)
3. crash unaligned --> system should reboot
4. panicinfo --> should print the same crash dump as before, with (NEW)
5. panicinfo --> ditto, without (NEW)
6. sysjump rw
7. panicinfo --> ditto, without (NEW)
Change-Id: I88285724e82a15553ab25877e3d8ec4c74a4dd5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32051
Now that the panic stack goes at the end of RAM, there's no overhead
to using it on all platforms. When it was a dedicated block of
memory, we needed to turn it off on some low-RAM platforms
(e.g. Snow).
BUG=chrome-os-partner:7466
TEST='crash divzero' or 'crash unaligned'; should print dump and reboot
BRANCH=all
Change-Id: Iddfeb134e237538215df51abe4e16ee831b3ae2d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32037
Reviewed-by: Simon Glass <sjg@chromium.org>
This is in preparation for saving panic data across reboots for later
retrieval.
BUG=chrome-os-partner:7466
TEST='crash divzero' or 'crash unaligned'; should print dump and reboot
BRANCH=all
Change-Id: I997d160b00d03759eb9c69b53ab0f7a5ae144183
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31951
Reviewed-by: Simon Glass <sjg@chromium.org>
panic_putc was doing an infinite loop on platforms with a UART FIFO.
(e.g. LM4F)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:10825
TEST=on Link EVT and Lucas DVT, type "rw 1" in the EC serial console and
see the panic trace.
Change-Id: I47f43183e6e938b88874c80244430ddf88c5a567
Reviewed-on: https://gerrit.chromium.org/gerrit/26052
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
In addition to ASSERT(), it might be useful to panic() sometimes, so add
a tidy way of doing it which will print a message and reset.
BUG=chrome-os-partner:10149
TEST=manual
Build a special version for snow where the 'rw' command calls panic()
See that a message is produced:
> rw 0
read 0x0 = 0x20001048
** PANIC: Address is 0
Change-Id: I4512c0193f4c1d52d0c256b2deefacf551056fd9
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25413
Rather than just reset the board, report assertion failures to aid
debugging. To enable this, use CONFIG_ASSERT_HELP.
BUG=chrome-os-partner:10149
TEST=manual
Enable the option for snow, add a failing ASSERT() to the rw command
and see the a nice message is printed now.
ASSERTION FAILURE 'address' in command_read_word() at common/memory_commands.c:00000037
Change-Id: Ice59434c5daf610832dd0e1fcfa5630dc847bb67
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25411
The fault status registers sometimes have useful information, so provide
an option to display these.
This adds about 1KB to the code size.
BUG=chrome-os-partner:10146
TEST=manual:
build for all boards
On snow, cause a panic and see that it is reported correctly.
=== 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
Change-Id: I1a18c85ee63760502c92b300f5a87e57468469a5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24505
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For particularly nasty errors the stack or stack pointer may be corrupt,
or in a place that we do not want overwritten. Provide and option to
place the stack in a fresh place, assuming you can reach exception_panic().
Note that exception_panic() does not write anything to stack itself.
BUG=chrome-os-partner:10146
TEST=manual:
build for all boards
On snow, cause a panic and see that it is reported correctly.
Change-Id: I21d8b9bb12455758309d54ef20de66640d8a2df6
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24504
Move the implementation of panic into C code. Only a very small part
needs to be in assembler, and the reset is easier to maintain as C.
As part of this, define panic_putc() and panic_puts() which directly
wite to the UART.
To make things more convenience for the future, add a simple printf()
implementation in the panic path. This is not reliant on the uart
buffering system being in a happy state. However, we do call the
emergency flush so that our panic message will appear after previous
output rather that surpressing it (which would be extremely confusing).
Code/data size for panic.o grows by about 200 bytes, but this is mostly
due to the increased flexibility.
text data bss dec hex filename
292 272 0 564 234 old panic.S
692 3 48 743 2e7 new panic.c
BUG=chrome-os-partner:10146
TEST=manual:
build and boot on snow:
> rw 0x06000000
=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
r0 :0000000b r1 :00000047 r2 :06000000 r3 :200013dd
r4 :00000000 r5 :080052cc r6 :200013d0 r7 :00000002
r8 :00000000 r9 :200013de r10:00000000 r11:00000000
r12:00000000 sp :200009a0 lr :08002a5d pc :08003962
Rebooting...
Change-Id: If3e3f572e0f32af780b6ebda235b1b3cde4de5e4
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24503
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
