sandbox: Improve debugging in initcall_run_list()

At present if one of the initcalls fails on sandbox the address printing
is not help, e.g.:

  initcall sequence 0000557678967c80 failed at call 00005576709dfe1f (err=-96)

This is because U-Boot gets relocated high into memory and the relocation
offset (gd->reloc_off) does not work correctly for sandbox.

Add support for finding the base address of the text region (at least on
Linux) and use that to set the relocation offset. This makes the output
better:

  initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96)

Then you use can use grep to see which init call failed, e.g.:

   $ grep 0000000000048134 u-boot.map
   stdio_add_devices

Of course another option is to run it with a debugger such as gdb:

   $ gdb u-boot
   ...
   (gdb) br initcall.h:41
   Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations)

Note that two locations are reported, since this function is used in both
board_init_f() and board_init_r().

   (gdb) r
   Starting program: /tmp/b/sandbox/u-boot
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

   U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600)

   DRAM:  128 MiB
   MMC:

Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>)
    at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41
41				printf("initcall sequence %p failed at call %p (err=%d)\n",
   (gdb) print *init_fnc_ptr
   $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices>
   (gdb)

Signed-off-by: Simon Glass <sjg@chromium.org>

1 files changed, 43 insertions, 0 deletions

diff --git a/board/sandbox/README.sandbox b/board/sandbox/README.sandbox
index 9b094042943..ed8fac6f786 100644
--- a/board/sandbox/README.sandbox
+++ b/board/sandbox/README.sandbox
@@ -392,6 +392,49 @@ state_setprop() which does this automatically and avoids running out of
 space. See existing code for examples.
 
 
+Debugging the init sequence
+---------------------------
+
+If you get a failure in the initcall sequence, like this:
+
+   initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96)
+
+Then you use can use grep to see which init call failed, e.g.:
+
+   $ grep 0000000000048134 u-boot.map
+   stdio_add_devices
+
+Of course another option is to run it with a debugger such as gdb:
+
+   $ gdb u-boot
+   ...
+   (gdb) br initcall.h:41
+   Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations)
+
+Note that two locations are reported, since this function is used in both
+board_init_f() and board_init_r().
+
+   (gdb) r
+   Starting program: /tmp/b/sandbox/u-boot
+   [Thread debugging using libthread_db enabled]
+   Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+   U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600)
+
+   DRAM:  128 MiB
+   MMC:
+
+   Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>)
+       at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41
+   41                              printf("initcall sequence %p failed at call %p (err=%d)\n",
+   (gdb) print *init_fnc_ptr
+   $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices>
+   (gdb)
+
+
+This approach can be used on normal boards as well as sandbox.
+
+
 Testing
 -------