1. 12 Jan, 2023 1 commit
  2. 23 Dec, 2022 1 commit
  3. 05 Dec, 2022 1 commit
  4. 10 Nov, 2022 1 commit
    • Tom Rini's avatar
      Convert CONFIG_SYS_MONITOR_LEN to Kconfig · 08574ed3
      Tom Rini authored
      This converts the following to Kconfig:
      To do this, we set a default of 0 for everyone because there are a
      number of cases where we define CONFIG_SYS_MONITOR_LEN but the only
      impact is that we set TOTAL_MALLOC_LEN to be CONFIG_SYS_MALLOC_LEN +
      CONFIG_ENV_SIZE, so we must continue to allow all boards to set this
      value. Update the SPL code to use 200 KB as the default raw U-Boot size
      directly, if we don't have a real CONFIG_SYS_MONITOR_LEN value.
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  5. 31 Oct, 2022 5 commits
  6. 29 Sep, 2022 2 commits
  7. 14 Sep, 2022 1 commit
  8. 28 Jun, 2022 4 commits
    • Alper Nebi Yasak's avatar
      spl: binman: Check at runtime if binman symbols were filled in · 367ecbf2
      Alper Nebi Yasak authored and Simon Glass's avatar Simon Glass committed
      Binman lets us declare symbols in SPL/TPL that refer to other entries in
      the same binman image as them. These symbols are filled in with the
      correct values while binman assembles the images, but this is done
      in-memory only. Symbols marked as optional can be filled with
      BINMAN_SYM_MISSING as an error value if their referred entry is missing.
      However, the unmodified SPL/TPL binaries are still available on disk,
      and can be used by people. For these files, nothing ensures that the
      symbols are set to this error value, and they will be considered valid
      when they are not.
      Empirically, all symbols show up as zero in a sandbox_vpl build when we
      run e.g. tpl/u-boot-tpl directly. On the other hand, zero is a perfectly
      fine value for a binman-written symbol, so we cannot say the symbols
      have wrong values based on that.
      Declare a magic symbol that binman always fills in with a fixed value.
      Check this value as an indicator that symbols were filled in cor...
    • Alper Nebi Yasak's avatar
      spl: binman: Split binman symbols support from enabling binman · d8830cf8
      Alper Nebi Yasak authored and Simon Glass's avatar Simon Glass committed
      Enabling CONFIG_BINMAN makes binman run after a build to package any
      images specified in the device-tree. It also enables a mechanism for
      SPL/TPL to declare and use special linker symbols that refer to other
      entries in the same binman image. A similar feature that gets this info
      from the device-tree exists for U-Boot proper, but it is gated behind a
      CONFIG_BINMAN_FDT unlike the symbols.
      Confusingly, CONFIG_SPL/TPL_BINMAN_SYMBOLS also exist. These configs
      don't actually enable/disable the symbols mechanism as one would expect,
      but declare some symbols for U-Boot using this mechanism.
      Reuse the BINMAN_SYMBOLS configs to make them toggle the symbols
      mechanism, and declare symbols for the U-Boot phases in a dependent
      BINMAN_UBOOT_SYMBOLS config. Extend it to cover symbols of all phases.
      Update the config prompt and help message to make it clearer about this.
      Fix binman test binaries to work with CONFIG_IS_ENABLED(BINMAN_SYMBOLS).
      Co-developed-by: Peng Fan's avatarPeng Fan <peng.fan@nxp.com>
      [Alper: New config for phase symbols, update Kconfigs, commit message]
      Signed-off-by: default avatarAlper Nebi Yasak <alpernebiyasak@gmail.com>
    • Alper Nebi Yasak's avatar
      spl: binman: Fix use of undeclared u_boot_any symbols · d7f07172
      Alper Nebi Yasak authored and Simon Glass's avatar Simon Glass committed
      Some SPL functions directly use the binman 'u_boot_any' symbols to get
      U-Boot's binman image position. These symbols are declared by the
      SPL/TPL_BINMAN_SYMBOLS configs, but they are accessed by macros defined
      by just CONFIG_BINMAN. So when BINMAN is enabled and BINMAN_SYMBOLS is
      disabled, the code tries to use undeclared symbols and we get an error.
      Therefore, any use of 'u_boot_any' symbols in the code is an implicit
      dependency on SPL/TPL_BINMAN_SYMBOLS. However, in the current uses
      they are meant to be the next phase's values, where that happens to be
      U-Boot. In the meantime, helper funcions spl_get_image_pos/size() were
      introduced to get these values.
      Convert all uses of u_boot_any symbols to these functions, so we only
      access these symbols at one place. Make sure they will not use these
      symbols when the BINMAN_SYMBOLS configs are disabled, by returning early
      in those cases.
      Signed-off-by: default avatarAlper Nebi Yasak <alpernebiyasak@gmail.com>
    • Simon Glass's avatar
      dm: spl: Allow SPL to show memory usage · 4f6500aa
      Simon Glass authored
      Add an option to tell SPL to show memory usage for driver model just
      before it boots into the next phase.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  9. 06 Jun, 2022 1 commit
  10. 02 May, 2022 1 commit
  11. 09 Apr, 2022 1 commit
  12. 22 Feb, 2022 2 commits
    • Simon Glass's avatar
      spl: Allow disabling binman symbols in SPL · 38c04d8e
      Simon Glass authored
      When CONFIG_SPL_FIT is enabled we do not access U-Boot directly in
      the image, since it is embedded in a FIT which is parsed at runtime.
      Provide a CONFIG option to drop the symbols in this case.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      spl: x86: Correct the binman symbols for SPL · 00959d87
      Simon Glass authored
      These symbols are incorrect, meaning that binman cannot find the
      associated entry. This leads to errors like:
      binman: Section '/binman/simple-bin': Symbol '_binman_spl_prop_size'
         in entry '/binman/simple-bin/u-boot-spl/u-boot-spl-nodtb':
         Entry 'spl' not found in list (mkimage,u-boot-spl-nodtb,
      Fix it.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  13. 28 Jan, 2022 1 commit
  14. 20 Jan, 2022 2 commits
  15. 19 Jan, 2022 1 commit
  16. 18 Jan, 2022 1 commit
  17. 13 Jan, 2022 1 commit
  18. 05 Nov, 2021 1 commit
  19. 31 Oct, 2021 1 commit
  20. 25 Oct, 2021 1 commit
  21. 05 Oct, 2021 1 commit
    • Patrick Delaunay's avatar
      lib: optee: remove the duplicate CONFIG_OPTEE · 51827f9a
      Patrick Delaunay authored and Tom Rini's avatar Tom Rini committed
      The configuration CONFIG_OPTEE is defined 2 times:
      1- in lib/optee/Kconfig for support of OPTEE images loaded by bootm command
      2- in drivers/tee/optee/Kconfig for support of OP-TEE driver.
      It is abnormal to have the same CONFIG define for 2 purpose;
      and it is difficult to managed correctly their dependencies.
      Moreover CONFIG_SPL_OPTEE is defined in common/spl/Kconfig
      to manage OPTEE image load in SPL.
      This definition causes an issue with the macro CONFIG_IS_ENABLED(OPTEE)
      to test the availability of the OP-TEE driver.
      This patch cleans the configuration dependency with:
      - CONFIG_OPTEE_IMAGE (renamed) => support of OP-TEE image in U-Boot
      - CONFIG_SPL_OPTEE_IMAGE (renamed) => support of OP-TEE image in SPL
      - CONFIG_OPTEE (same) => support of OP-TEE driver in U-Boot
      - CONFIG_OPTEE_LIB (new) => support of OP-TEE library
      After this patch, the macro have the correct behavior:
      - CONFIG_IS_ENABLED(OPTEE_IMAGE) => Load of OP-TEE image is supported
      - CONFIG_IS_ENABLED(OPTEE) => OP-TEE driver is supported
      Signed-off-by: Patrick Delaunay's avatarPatrick Delaunay <patrick.delaunay@foss.st.com>
  22. 25 Sep, 2021 1 commit
  23. 17 Sep, 2021 1 commit
  24. 04 Sep, 2021 1 commit
  25. 31 Jul, 2021 1 commit
    • Pali Rohár's avatar
      SPL: Add support for parsing board / BootROM specific image types · 9baab60b
      Pali Rohár authored and Stefan Roese's avatar Stefan Roese committed
      Platform specific BootROM may use its own image type for loading SPL or
      U-Boot proper. In some cases it makes sense to not use BootROM supplied
      code for booting U-Boot proper but rather to use U-Boot SPL for this,
      e.g. when U-Boot SPL can load U-Boot proper faster than BootROM. In this
      case it is required for platform board code to parse and load U-Boot in
      BootROM specific image type.
      This change adds support for parsing platform / board / BootROM specific
      image types via weak function spl_parse_board_header() which is called
      before marking boot image as a raw.
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: Stefan Roese's avatarStefan Roese <sr@denx.de>
  26. 28 Jul, 2021 1 commit
  27. 27 Jul, 2021 1 commit
  28. 23 Jul, 2021 1 commit
  29. 21 Jul, 2021 1 commit
    • Simon Glass's avatar
      spl: Provide more information on boot failure · 7d84fbb5
      Simon Glass authored
      If SPL fails to boot, try to provide an error code to indicate what is
      wrong. For example, if a uclass is missing, this can return -EPFNOSUPPORT
      (-96) which provides useful information.
      Add a helper for accessing the image-loader name so we can drop the use
      of #ifdefs in this code.
      Put this feature behind a CONFIG_SHOW_ERRORS option to avoid increasing
      the code size.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  30. 07 Jul, 2021 1 commit
    • Tom Rini's avatar
      bootstage: Eliminate when not enabled · cb80ff20
      Tom Rini authored
      When we do not have bootstage enabled, rather than include an empty
      dummy function, we just don't reference it.  This saves us space in some
      tight builds.  This also shows a few cases where show_boot_progress was
      incorrectly guarded before.
      Cc: Simon Glass <sjg@chromium.org>
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>