1. 29 Sep, 2020 3 commits
  2. 14 Sep, 2020 2 commits
  3. 14 Jun, 2020 4 commits
  4. 20 Apr, 2020 1 commit
  5. 04 Jun, 2019 1 commit
  6. 18 Mar, 2019 1 commit
  7. 08 Jan, 2019 2 commits
  8. 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
  9. 14 Nov, 2018 1 commit
  10. 09 Jul, 2018 9 commits
  11. 30 Nov, 2017 1 commit
  12. 06 Nov, 2017 3 commits
  13. 15 Aug, 2017 1 commit
  14. 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
  15. 31 Mar, 2017 1 commit
  16. 28 Feb, 2017 2 commits
    • Siarhei Siamashka's avatar
      fel: Enable the SMC workaround for H3/H5/A64/H64 · 275827ad
      Siarhei Siamashka authored
      
      
      Use a hardwired L.NOP instruction from the OpenRISC reset
      vector as a way to check if the workaround is necessary.
      Because these L.NOP instructions are guaranteed to be there
      and are read-only, this is the most reliable non-invasive test.
      
      Reading SID would be less reliable because it is one-time
      programmable and theoretically may be set to zero on some boards.
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      275827ad
    • 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
  17. 13 Feb, 2017 1 commit
  18. 11 Feb, 2017 4 commits
  19. 03 Feb, 2017 1 commit