1. 11 Jan, 2021 2 commits
    • Andre Przywara's avatar
      fel: Parse SPL DT name · 5541673d
      Andre Przywara authored
      
      
      A while ago the SPL header was extended to hold the name of the DTB file
      that shall be used for the board a firmware image is made for.
      
      Add some code to extract that name from the SPL header. This will be
      used in later patches to load the proper DTB file.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      5541673d
    • Andre Przywara's avatar
      fel: autoboot: Support entering in AArch64 · 059b8311
      Andre Przywara authored
      
      
      So far FEL was limited to 32-bit payloads only, but this will change.
      To accomodate 64-bit entry points, introduce a corresponding flag and
      use either the normal FEL execute call or the RMR request to kick off
      execution.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      059b8311
  2. 31 Dec, 2020 1 commit
    • Andre Przywara's avatar
      fel: Observe SRAM size to extend SPL load size · 4c6a1a01
      Andre Przywara authored
      
      
      At the moment we limit the maximum SPL load size to 32 KB, because this
      was a BROM limit in previous SoCs.
      Newer SoCs (H6 and later) lift this limit, but also this tool is not
      bound by the BROM limit, since we can load any size.
      
      Use the just introduced SRAM size to establish an upper limit for the
      SPL size, then limit this as we go if any part of the memory is used for
      the FEL backup buffers.
      
      Given the buffer addresses chosen wisely, this can drastically increase
      the maximum SPL load size, even on those SoCs with a 32KB BROM limit.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      4c6a1a01
  3. 29 Dec, 2020 3 commits
    • Andre Przywara's avatar
      fel: Check actual SPL size before considering U-Boot proper · 75960dd2
      Andre Przywara authored
      
      
      At the moment we always use a 32KB offset to place the U-Boot image
      after the SPL.
      Newer SoCs can (and will) have bigger SPLs, so we need to become more
      flexible with this offset.
      
      Read the actual SPL size, and assume the U-Boot payload is located right
      behind the SPL, if the SPL size is bigger than 32KB.
      We use at least 32KB, because this is how U-Boot is doing it today, even
      when the SPL size is actually smaller than that.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      75960dd2
    • Andre Przywara's avatar
      fel: Fix SPL size check against thunk addr · 2b67b2d7
      Andre Przywara authored
      
      
      We have a check to avoid that the SPL accidentally overwrites the thunk
      buffer we use to execute code on the board.
      
      Unfortunately this compares the SPL *size* against the thunk *address*,
      which is only valid when the SPL starts at 0 (older 32-bit SoCs).
      
      Factor in the SoC dependent SPL start address, to make this check work
      properly on newer (64-bit) SoCs.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      2b67b2d7
    • Andre Przywara's avatar
      fel: Check for U-Boot image before considering checksum · 8af203ec
      Andre Przywara authored
      
      
      Currently we check the U-Boot (legacy!) image header checksum very early
      and bail out with an error message if it does not match.
      
      Move that check later into the function, *after* we have established
      that we are actually dealing with such an U-Boot image.
      
      This avoids confusing error messages in case there is no U-Boot image
      used at all.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      8af203ec
  4. 14 Jun, 2020 1 commit
  5. 20 Apr, 2020 1 commit
  6. 02 Dec, 2018 1 commit
    • Andre Przywara's avatar
      FEL: introduce semantic versioning for SPL header · 8fa2f24d
      Andre Przywara authored
      Every addition of a new feature to the SPL header currently requires us
      to update the FEL tool, to teach it about the new supported maximum
      value. Many times the FEL tool doesn't really care, but complains
      anyway - and refuses to load.
      Let's introduce semantic versioning [1] for this field, where backwards
      compatible additions just increase a minor number, but incompatible
      changes require bumping the major version.
      We have 8 bits for the SPL header version, let's split this to have 3 bits
      for the major and 5 bit for the minor version number.
      
      [1] https://semver.org
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      8fa2f24d
  7. 09 Jul, 2018 2 commits
  8. 06 Nov, 2017 3 commits
  9. 29 Apr, 2017 1 commit
    • Icenowy Zheng's avatar
      fel: enable support for v2 SPL · c8ada384
      Icenowy Zheng authored
      
      
      The version 2 of SPL added the possibility to add a device tree name in
      the header, with adding some pad and using a reserved word.
      
      As FEL boot currently doesn't need the device tree name, directly raise
      the maximum supported version number to 2.
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      c8ada384
  10. 28 Feb, 2017 1 commit
    • Andre Przywara's avatar
      fel: SMC workaround to enter "secure boot" FEL mode on some SoCs · 8c45b33e
      Andre Przywara authored
      
      
      If an SoC has the "secure boot" fuse burned, it will enter FEL mode in
      non-secure state, so with the SCR.NS bit set. Since in this mode the
      secure/non-secure state restrictions are actually observed, we suffer
      from several restrictions:
      - No access to the SID information (both via memory mapped and "register").
      - No access to secure SRAM (SRAM A2 on H3/A64/H5).
      - No access to the secure side of the GIC, so it can't be configured to
        be accessible from non-secure world.
      - No RMR trigger on ARMv8 cores to bring the core into AArch64.
      Those limitations make a board pretty useless for many applications.
      
      However it has been found out that a simple "smc" call will immediately
      return from monitor mode, but with the NS bit cleared, so access to all
      secure peripherals is suddenly possible.
      
      Add all the necessary support code for doing a runtime check and
      activating this workaround. Affected SoCs need to have the "smc"
      workaround enabled in their soc_info struct.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      ["sunxi-fel smc" command changed to automatic detection by Siarhei]
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      8c45b33e
  11. 13 Feb, 2017 1 commit
  12. 11 Feb, 2017 1 commit
  13. 27 Jan, 2017 1 commit
  14. 28 Dec, 2016 4 commits
  15. 13 Dec, 2016 1 commit
    • Bernhard Nortmann's avatar
      fel: Improve on handling invalid options · 1d2182c4
      Bernhard Nortmann authored
      
      
      For unknown option-style arguments (starting with '-'), exit after
      printing an error message.
      
      This avoids situations where sunxi-fel would not report incorrect
      options (with no FEL device attached/detected) and fail with
      "Allwinner USB FEL device not found" instead, which is undesirable.
      
      TODO: Might have to eventually migrate this to some better argument
      parsing, e.g. getopt(3) or something similar.
      Signed-off-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>
      1d2182c4
  16. 07 Dec, 2016 2 commits
  17. 01 Dec, 2016 2 commits
  18. 29 Nov, 2016 9 commits
  19. 19 Nov, 2016 2 commits
  20. 13 Nov, 2016 1 commit