1. 27 Nov, 2018 1 commit
    • Chandni Cherukuri's avatar
      plat/css: allow platforms to define the system power domain level · eff2f444
      Chandni Cherukuri authored
      
      
      The CSS_SYSTEM_PWR_DMN_LVL macro that defines the system power domain
      level is fixed at ARM_PWR_LVL2 for all CSS platforms. However, the
      system power domain level can be different for CSS platforms that
      use multi-threaded CPUs.
      
      So, in preparation towards adding support for platforms that use
      multi-threaded CPUs, refactor the definition of CSS_SYSTEM_PWR_DMN_LVL
      such that CSS_SYSTEM_PWR_DMN_LVL is uniquely defined for each of the
      CSS platform.
      
      Change-Id: Ia837b13f6865e71da01780993c048b45b7f36d85
      Signed-off-by: default avatarChandni Cherukuri <chandni.cherukuri@arm.com>
      eff2f444
  2. 26 Nov, 2018 2 commits
  3. 23 Nov, 2018 2 commits
  4. 22 Nov, 2018 4 commits
  5. 21 Nov, 2018 2 commits
  6. 20 Nov, 2018 5 commits
  7. 19 Nov, 2018 4 commits
  8. 16 Nov, 2018 1 commit
  9. 15 Nov, 2018 10 commits
  10. 14 Nov, 2018 7 commits
    • Andre Przywara's avatar
      allwinner: power: Add DCDC6 power rail · 793c38f0
      Andre Przywara authored
      
      
      The DCDC6 power rail is typically driving VDD_SYS in the SoC, so it is
      on by default and uses the default voltage.
      
      As there seems to be at least on board using a different voltage, add
      the rail to the list of known voltage lines, so we can setup the right
      voltage as early as possible.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      793c38f0
    • Andre Przywara's avatar
      allwinner: power: add enable switches for DCDC1/5 · a561e41b
      Andre Przywara authored
      
      
      The DCDC1 and DCDC5 power rails didn't specify the enable bits. This
      isn't critical, since those rails are on by default (and are needed for
      every board), but it is inconsistent.
      
      Add the respective enable bits for those two rails.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      a561e41b
    • Andre Przywara's avatar
      allwinner: power: fix DRIVEVBUS pin setup · d93eb446
      Andre Przywara authored
      
      
      The DRIVEVBUS pin setup was broken in two ways:
      - To configure this pin as an output pin, one has to *clear* the bit in
        register 0x8f. It is 0 by default, but rebooting from Linux might have
        left this bit set.
      - Doing this just configures the pin as an output pin, but doesn't
        actually drive power to it. This is done via bit 2 in register 0x30.
      
      Fix the routine to both properly configure the pin and drive power to
      it. Add an axp_clrsetbits() helper on the way.
      
      Now this isn't really perfect, still:
      We only need to setup the PMIC power rails that are needed for U-Boot.
      DRIVEVBUS typically controls the VBUS voltage for the host function of
      an USB-OTG port, something we typically don't want in U-Boot (fastboot,
      using the USB *device* functionality, is much more common). The
      BananaPi-M64 uses the regulator in this way, but the Remix Mini PC
      actually controls the power of both its USB ports via this line.
      
      Technically we should differentiate here: if DRIVEVBUS controls a
      microUSB-B socket, the power should stay off, any host-type A sockets
      should be supplied, though.
      For now just always enable the power, that shouldn't really hurt the
      USB-OTG functionality anyway.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      d93eb446
    • Andre Przywara's avatar
      allwinner: A64/H5: setup missing bus clocks · 19a7507a
      Andre Przywara authored
      
      
      The legacy Allwinner ATF port used to setup some clocks, and U-Boot is
      still relying on this. We don't need to setup the full set, as the SPL
      is doing most of it, but it misses one clock (AHB2) and programs another
      (AHB1) to quite conservative values.
      
      Fix this up during the platform setup to improve USB and Ethernet
      performance, iperf values go up by 31% in my setup with that patch.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      19a7507a
    • Sughosh Ganu's avatar
      SPM: Raise running priority of the core while in Secure Partition · 6e3bad36
      Sughosh Ganu authored
      
      
      The current secure partition design mandates that a) at a point, only
      a single core can be executing in the secure partition, and b) a core
      cannot be preempted by an interrupt while executing in secure
      partition.
      
      Ensure this by activating the SPM priority prior to entering the
      parition. Deactivate the priority on return from the
      partition.
      
      Change-Id: Icb3473496d16b733564592eef06304a1028e4f5c
      Signed-off-by: default avatarSughosh Ganu <sughosh.ganu@arm.com>
      6e3bad36
    • Sughosh Ganu's avatar
      SPM: Register Secure Partition priority level with ehf module · 5681b292
      Sughosh Ganu authored
      
      
      Register a priority level, PLAT_SP_PRI, for secure partition with EL3
      exception handling framework(ehf) module.
      
      The secure partition manager(SPM) would raise the core's priority to
      PLAT_SP_PRI before entering the secure partition, to protect the core
      from getting interrupted while in secure partition.
      
      Change-Id: I686897f052a4371e0efa9b929c07d3ad77249e95
      Signed-off-by: default avatarSughosh Ganu <sughosh.ganu@arm.com>
      5681b292
    • Sughosh Ganu's avatar
      SPM: EHF: Build EHF module along with Secure Partition Manager · 8a3588a7
      Sughosh Ganu authored
      
      
      Add a dependency for building EL3 exception handling framework(EHF)
      module with the secure partition manager(SPM).
      
      The EHF module is needed for raising the core's running priority
      before the core enters the secure partition, and lowering it
      subsequently on exit from the secure partition.
      
      Change-Id: Icbe2d0a63f00b46dc593ff3d86b676c9333506c3
      Signed-off-by: default avatarSughosh Ganu <sughosh.ganu@arm.com>
      8a3588a7
  11. 13 Nov, 2018 2 commits
    • Pete Batard's avatar
      rpi3: add RPI3_RUNTIME_UART build option · 6d5c61de
      Pete Batard authored
      
      
      Some OSes (e.g. Ubuntu 18.04 LTS on Raspberry Pi 3) may disable the
      runtime UART in a manner that prevents the system from rebooting if
      ATF tries to send runtime messages there.
      
      Also, we don't want the firmware to share the UART with normal
      world, as this can be a DoS attack vector into the secure world.
      
      This patch fixes these 2 issues by introducing new build option
      RPI3_RUNTIME_UART, that disables the runtime UART by default.
      
      Fixes ARM-software/tf-issues#647
      Signed-off-by: default avatarPete Batard <pete@akeo.ie>
      6d5c61de
    • Antonio Nino Diaz's avatar
      Merge pull request #1676 from Yann-lms/static_analysis · a6febeab
      Antonio Nino Diaz authored
      Correct some issues found with static analysis tools
      a6febeab