Due to recent changes this function is no-longer used. Drop it.

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

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>

Add a way to read a file from the host filesystem. This can be useful for
reading test data, for example. Also fix up the writing function which was
not the right version, and drop the debugging lines.

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

At present sandbox sets non-blocking I/O as soon as any input is read
from the terminal. However it does not restore the previous state on
exit. Fix this and drop the old os_read_no_block() function.

This means that we always enable blocking I/O in sandbox (if input is a
terminal) whereas previously it would only happen on the first call to
tstc() or getc(). However, the difference is likely not important.

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

For debugging it is sometimes useful to write out data for inspection
using an external tool. Add a function which can write this data to a
given file.

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

At present files are not truncated on writing. This is a useful feature.
Add support for this.

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

On my Ubuntu 18.04.1 machine two driver-model bus tests have started
failing recently. The problem appears to be that the DATA region of the
executable is protected. This does not seem correct, but perhaps there
is a reason.

To work around it, unprotect the regions in these tests before accessing
them.

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

In sandbox, longjmp returns to itself in an endless loop because
os_longjmp() calls into longjmp() which is provided by U-Boot which
again calls os_longjmp().

Setjmp on the other hand must not return because otherwise the
return freees up stack elements that we need during longjmp().

The only straight forward fix that doesn't involve nasty hacks I
could find is to directly link against the system setjmp/longjmp
implementations. That means we just provide the compiler with
hints that the symbol will be available and actually fill them
out with versions from libc.

This approach should be reasonably platform agnostic

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>

This function is useful to signal that the application needs to exit
immediate. It can be caught with a debugger (e.g. gdb). Add a stub for it
so that it can be called from within sandbox when an internal error
occurs.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>

Add an implementation of setjmp() and longjmp() which rely on the
underlying host C library. Since we cannot know how large the jump buffer
needs to be, pick something that should be suitable and check it at
runtime. At present we need access to the underlying struct as well.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>