1. 31 Dec, 2020 3 commits
    • Andre Przywara's avatar
      fel: H616: Allow bigger SPL size · 2a2af190
      Andre Przywara authored
      
      
      The H616 has quite a large chunk of continuous SRAM, and also the BROM
      allows to load eGON images far bigger than 32KB. U-Boot's SPL is
      actually relying on this, as we need more code for the PMIC and DRAM
      driver.
      
      Move the FEL stack backup buffers and the thunk address towards the end
      of SRAM C, so that we have a larger chunk of continuous SRAM available
      for the SPL.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      2a2af190
    • 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
    • Andre Przywara's avatar
      soc_info: Introduce SRAM size · 276a97da
      Andre Przywara authored
      
      
      At the moment we assume the SPL load size to be limited to 32KB, even
      though many SoCs have more SRAM A1 or a large SRAM C directly after SRAM
      A1.
      
      To later allow to extend the SPL load size, let's introduce a SoC
      specific variable to hold the SRAM size after the SPL load address. This
      could either cover the whole of SRAM A1, or even SRAM C, if that is
      contiguous to SRAM A1.
      
      Eventually this variable is meant to hold the *usable* SRAM size, so not
      including regions that are used by the BROM code. However this value is
      very SoC specific and not documented, and the SPL size is limited by the
      thunk and stack buffers anyway at the moment, so the values used here
      right now are just taken from the respective manuals.
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      276a97da
  2. 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
  3. 23 Nov, 2020 1 commit
  4. 19 Nov, 2020 1 commit
  5. 12 Nov, 2020 1 commit
  6. 10 Nov, 2020 6 commits
  7. 08 Nov, 2020 1 commit
  8. 20 Oct, 2020 1 commit
  9. 19 Oct, 2020 1 commit
  10. 08 Oct, 2020 1 commit
  11. 06 Oct, 2020 1 commit
  12. 02 Oct, 2020 1 commit
  13. 29 Sep, 2020 7 commits
  14. 19 Sep, 2020 2 commits
    • Icenowy Zheng's avatar
      fel: SPI: add Eon support · bf02fd31
      Icenowy Zheng authored
      
      
      Add the JEDEC manufacturer ID for Eon to the list of recognized
      vendors, also add the EN25QH series to the list of supported chips.
      Those chips are used on some internal boards with V831 from Sipeed now,
      but the chips themselves are widely available on the market. Tag the
      struct definition with the member names on the way to improve readability
      of the SPI flash chip description.
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      bf02fd31
    • Icenowy Zheng's avatar
      spi: add support for V3s SoC · b330eeb8
      Icenowy Zheng authored
      
      
      The Allwinner V3s SoC have the same SPI0 pinmux configuration, SPI clock
      configuration and SPI controller (base address and the controller) with
      H3.
      
      Add spiflash support for it.
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      b330eeb8
  15. 14 Sep, 2020 2 commits
  16. 14 Jun, 2020 4 commits
  17. 20 Apr, 2020 1 commit
  18. 04 Jun, 2019 1 commit
  19. 18 Mar, 2019 1 commit
  20. 08 Jan, 2019 1 commit