1. 03 3月, 2021 2 次提交
    • S
      sandbox: Avoid using malloc() for system state · b308d9fd
      Simon Glass 提交于
      This state is not accessible to the running U-Boot but at present it is
      allocated in the emulated SDRAM. This doesn't seem very useful. Adjust
      it to allocate from the OS instead.
      
      The RAM buffer is currently not freed, but should be, so add that into
      state_uninit(). Update the comment for os_free() to indicate that NULL is
      a valid parameter value.
      
      Note that the strdup() in spl_board_load_image() is changed as well, since
      strdup() allocates memory in the RAM buffer.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      b308d9fd
    • S
      sandbox: Add os_realloc() · 14e46dfb
      Simon Glass 提交于
      We provide os_malloc() and os_free() but not os_realloc(). Add this,
      following the usual semantics. Also update os_malloc() to behave correctly
      when passed a zero size.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      14e46dfb
  2. 31 1月, 2021 1 次提交
  3. 06 1月, 2021 1 次提交
    • P
      sandbox: remove ram buffer file when U-Boot is loaded by SPL · 10bb90fa
      Patrick Delaunay 提交于
      Update management of "--rm_memory" sandbox's option and force
      this option when U-Boot is loaded by SPL in os_spl_to_uboot()
      and remove the ram file after reading in main() as described
      in option help message: "Remove memory file after reading".
      
      This patch avoids that the file "/tmp/u-boot.mem.XXXXXX" [created in
      os_jump_to_file() when U-Boot is loaded by SPL] is never deleted
      because state_uninit() is not called after U-Boot execution
      (CtrlC or with running pytest for example).
      
      This issue is reproduced by
      > build-sandbox_spl/spl/u-boot-spl
        and CtrlC in U-Bot console
      
      > make qcheck
      
      One temp file is created after each SPL and U-Boot execution
      (7 tims in qcheck after test_handoff.py, test_ofplatdata.py,
       test_spl.py execution).
      Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      10bb90fa
  4. 13 12月, 2020 1 次提交
  5. 06 11月, 2020 3 次提交
  6. 16 4月, 2020 1 次提交
    • R
      sandbox: also restore terminal settings when killed by SIGINT · 2960107a
      Rasmus Villemoes 提交于
      Hitting Ctrl-C is a documented way to exit the sandbox, but it is not
      actually equivalent to the reset command. The latter, since it follows
      normal process exit, takes care to reset terminal settings and
      restoring the O_NONBLOCK behaviour of stdin (and, in a terminal, that
      is usually the same file description as stdout and stderr, i.e. some
      /dev/pts/NN).
      
      Failure to restore (remove) O_NONBLOCK from stdout/stderr can cause
      very surprising and hard to debug problems back in the terminal. For
      example, I had "make -j8" consistently failing without much
      information about just exactly what went wrong, but sometimes I did
      get a "echo: write error". I was at first afraid my disk was getting
      bad, but then a simple "dmesg" _also_ failed with write error - so it
      was writing to the terminal that was buggered. And both "make -j8" and
      dmesg in another terminal window worked just fine.
      
      So install a SIGINT handler so that if the chosen terminal
      mode (cooked or raw-with-sigs) means Ctrl-C sends a SIGINT, we will
      still call os_fd_restore(), then reraise the signal and die as usual
      from SIGINT.
      
      Before:
      
      $ grep flags /proc/$$/fdinfo/1
      flags:  0102002
      $ ./u-boot
      # hit Ctrl-C
      $ grep flags /proc/$$/fdinfo/1
      flags:  0106002
      
      After:
      
      $ grep flags /proc/$$/fdinfo/1
      flags:  0102002
      $ ./u-boot
      # hit Ctrl-C
      $ grep flags /proc/$$/fdinfo/1
      flags:  0102002
      Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      2960107a
  7. 06 2月, 2020 3 次提交
  8. 14 11月, 2019 1 次提交
  9. 24 4月, 2019 2 次提交
    • S
      sandbox: Correct maths in allocation routines · 4a6409b7
      Simon Glass 提交于
      Allocation routines were adjusted to ensure that the returned addresses
      are a multiple of the page size, but the header code was not updated to
      take account of this. These routines assume that the header size is the
      same as the page size which is unlikely.
      
      At present os_realloc() does not work correctly due to this bug. The only
      user is the hostfs 'ls' command, and only if the directory contains a
      unusually long filename, which likely explains why this bug was not
      caught earlier.
      
      Fix this by doing the calculations using the obtained page size.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      4a6409b7
    • S
      sandbox: Improve debugging in initcall_run_list() · 001d1885
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      001d1885
  10. 05 12月, 2018 1 次提交
  11. 30 11月, 2018 1 次提交
  12. 26 11月, 2018 4 次提交
    • S
      sandbox: Boot in U-Boot through the standard call · 27028f18
      Simon Glass 提交于
      Most architectures use jump_to_image_no_args() to jump from SPL to U-Boot.
      At present sandbox is special in that it jumps in its
      spl_board_load_image() call. This is not strictly correct, and means that
      sandbox misses out some parts of board_init_r(), just as calling
      bloblist_finish(), for example.
      
      Change spl_board_load_image() to just identify the filename to boot, and
      implement jump_to_image_no_args() to actually jump to it.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      27028f18
    • S
      sandbox: Filter arguments when starting U-Boot · 65f3b1f9
      Simon Glass 提交于
      The current method of starting U-Boot from U-Boot adds arguments to pass
      the memory file through, so that memory is preserved. This is fine for a
      single call, but if we call from TPL -> SPL -> U-Boot the arguments build
      up and we have several memory files in the argument list.
      
      Adjust the implementation to filter out arguments that we want to replace
      with new ones. Also print a useful error if the exec() call fails.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      65f3b1f9
    • S
      sandbox: Use malloc() and free() from os layer · fc1f58a4
      Simon Glass 提交于
      At present sandbox calls malloc() from various places in the OS layer and
      this results in calls to U-Boot's malloc() implementation. It is better to
      use the on in the OS layer, since it does not mix allocations with the
      main U-Boot code.
      
      Fix this by replacing calls with malloc() to os_malloc(), etc.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Reviewed-by: NJoe Hershberger <joe.hershberger@ni.com>
      fc1f58a4
    • S
      sandbox: Refactor code to create os_jump_to_file() · 7b5ea145
      Simon Glass 提交于
      At present os_jump_to_image() jumps to a given image, and this is written
      to a file. But it is useful to be able to jump to a file also.
      
      To avoid duplicating code, split out the implementation of
      os_jump_to_image() into a new function that jumps to a file.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      7b5ea145
  13. 21 11月, 2018 1 次提交
  14. 15 11月, 2018 1 次提交
  15. 09 10月, 2018 4 次提交
  16. 08 10月, 2018 1 次提交
    • S
      sandbox: Unprotect DATA regions in bus tests · 9f8037ea
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      9f8037ea
  17. 24 9月, 2018 4 次提交
    • A
      sandbox: Allow to execute from RAM · 6e6e4b2f
      Alexander Graf 提交于
      With efi_loader, we may want to execute payloads from RAM. By default,
      permissions on the RAM region don't allow us to execute from there though.
      
      So let's change the default allocation scheme for RAM to also allow
      execution from it. That way payloads that live in U-Boot RAM can be
      directly executed.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      6e6e4b2f
    • A
      sandbox: Fix setjmp/longjmp · 3fcb7147
      Alexander Graf 提交于
      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: NAlexander Graf <agraf@suse.de>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      3fcb7147
    • S
      sandbox: Add support for calling abort() · fe938fb0
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      fe938fb0
    • S
      sandbox: Align RAM buffer to the machine page size · 61318502
      Simon Glass 提交于
      At present the sandbox RAM buffer is not aligned to any particular
      address boundary. This makes the internal pointers somewhat random with
      respect to the associated RAM buffer addresses.
      
      Align the buffer to the page size of the machine to help with this. Note
      that there is a header at the start of the allocated pointer. To avoid
      returning a pointer which is not aligned to a page boundary, we waste
      almost an entire page of memory for each allocation.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      61318502
  18. 03 6月, 2018 1 次提交
  19. 07 5月, 2018 1 次提交
    • T
      SPDX: Convert all of our single license tags to Linux Kernel style · 83d290c5
      Tom Rini 提交于
      When U-Boot started using SPDX tags we were among the early adopters and
      there weren't a lot of other examples to borrow from.  So we picked the
      area of the file that usually had a full license text and replaced it
      with an appropriate SPDX-License-Identifier: entry.  Since then, the
      Linux Kernel has adopted SPDX tags and they place it as the very first
      line in a file (except where shebangs are used, then it's second line)
      and with slightly different comment styles than us.
      
      In part due to community overlap, in part due to better tag visibility
      and in part for other minor reasons, switch over to that style.
      
      This commit changes all instances where we have a single declared
      license in the tag as both the before and after are identical in tag
      contents.  There's also a few places where I found we did not have a tag
      and have introduced one.
      Signed-off-by: NTom Rini <trini@konsulko.com>
      83d290c5
  20. 08 12月, 2017 1 次提交
    • S
      Revert "sandbox: remove os_putc() and os_puts()" · 0b189b6c
      Simon Glass 提交于
      While sandbox works OK without the special-case code, it does result in
      console output being stored in the pre-console buffer while sandbox starts
      up. If there is a crash or a problem then there is no indication of what
      is going on.
      
      For ease of debugging it seems better to revert this change.
      
      This reverts commit 47b98ad0.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      0b189b6c
  21. 09 10月, 2017 1 次提交
  22. 29 7月, 2017 1 次提交
  23. 09 6月, 2017 1 次提交
    • T
      sandbox: Fix comparison of unsigned enum expression warning · e2bc87d4
      Tom Rini 提交于
      In os_dirent_get_typename() we are checking that type falls within the
      known values of the enum os_dirent_t.  With clang-3.8 testing this value
      as being >= 0 results in a warning as it will always be true.  This
      assumes of course that we are only given valid data.  Given that we want
      to sanity check the input, we change this to check that it falls within
      the range of the first to the last entry in the given enum.
      
      Cc: Simon Glass <sjg@chromium.org>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      e2bc87d4
  24. 12 10月, 2016 2 次提交