When you are porting U-Boot to new hardware, or implementing extensions,
you might run into situations where U-Boot crashes and prints a register dump
and a stack trace, for example like this:
Bus Fault @ 0x00f8d70c, fixup 0x00000000
Machine check in kernel mode.
Caused by (from msr): regs 00f52cf8 Unknown values in msr
NIP: 00F8D70C XER: 0000005F LR: 00F8D6F4 REGS: 00f52cf8 TRAP: 0200 DAR: F9F68C00
MSR: 00009002 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00016ACC 00F52DE8 00000000 F9F68C00 00FA38EC 00000001 F9F68BF8 0000000B
GPR08: 00000002 00F55470 00000000 00F52D94 44004024 00000000 00FA2F00 C0F75000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00FA38EC 00F553C0 00F55480 00000000 00F52F80 00FA41C0 00000001
Call backtrace:
00000000 00F8F998 00F8FA88 00F8FAF8 00F90B5C 00F90CF8 00F8385C
00F79E6C 00F773B0
machine check
To find out what happened, you can try to decode the stack backtrace
(the list of addresses printed after the
"Call backtrace:"
line.
The
backtrace tool can be used
for this purpose. However, there is a little problem: the addresses printed
for the stack backtrace are
after relocation of the U-Boot code to RAM;
to use the
backtrace
tool you need to know U-Boot's
address offset
(the difference between the start address of U-Boot in flash and
its relocation address in RAM).
The easiest way to find out the relocation address is to enable debugging for
the U-Boot source file
lib_*/board.c
- U-Boot will then print some debug
messages
...
Now running in RAM - U-Boot at: 00f75000
...
Now you have to calculate the address offset between your link address
(The value of the
TEXT_BASE
definition in your
board/?/config.mk
file).
In our case this value is
0x40000000
, so the address offset is
0x40000000 - 0x00f75000 = 0x3f08b000
Now we use the
backtrace
script with the
System.map
file in the U-Boot source tree and this address offset:
-> backtrace System.map 0x3f08b000
Reading symbols from System.map
Using Address Offset 0x3f08b000
0x3f08b000 -- unknown address
0x4001a998 -- 0x4001a8d0 + 0x00c8 free_pipe
0x4001aa88 -- 0x4001aa2c + 0x005c free_pipe_list
0x4001aaf8 -- 0x4001aad0 + 0x0028 run_list
0x4001bb5c -- 0x4001ba68 + 0x00f4 parse_stream_outer
0x4001bcf8 -- 0x4001bcd8 + 0x0020 parse_file_outer
0x4000e85c -- 0x4000e6f8 + 0x0164 main_loop
0x40004e6c -- 0x40004b9c + 0x02d0 board_init_r
0x400023b0 -- 0x400023b0 + 0x0000 trap_init
In this case the last "good" entry on the stack was in
free_pipe
...