u-boot.git/include/os.h, branch v2021.01

sandbox: update function descriptions in os.h

2020-11-05T16:11:31+00:00

Use Sphinx style function descriptions.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass

sandbox: implement reset

2020-11-05T16:11:30+00:00

Up to now the sandbox would shutdown upon a cold reset request. Instead it
should be reset.

In our coding we use static variables like LIST_HEAD(efi_obj_list). A reset
can occur at any time, e.g. via an UEFI binary calling the reset service.
The only safe way to return to an initial state is to relaunch the U-Boot
binary.

The reset implementation uses execv() to relaunch U-Boot.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass

sandbox: Drop os_realloc()

2020-02-06T02:33:46+00:00

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

Signed-off-by: Simon Glass

sandbox: Improve debugging in initcall_run_list()

2019-04-24T02:26:43+00:00

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 )
    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 
   (gdb)

Signed-off-by: Simon Glass

sandbox: Add a function to read a host file

2018-11-21T02:14:22+00:00

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

sandbox: Restore blocking I/O on exit

2018-10-09T10:40:27+00:00

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

sandbox: Add a way to write data to the host filesystem

2018-10-09T10:40:26+00:00

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

sandbox: Support file truncation with os_open()

2018-10-09T10:40:26+00:00

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

Signed-off-by: Simon Glass

sandbox: Unprotect DATA regions in bus tests

2018-10-08T13:34:34+00:00

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

sandbox: Fix setjmp/longjmp

2018-09-23T19:55:30+00:00

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 
Reviewed-by: Simon Glass 
Signed-off-by: Alexander Graf