Re: [U-Boot] [PATCH 0/3] arm: tegra20/colibri_t20: early pmic rail configuration
On 20 Aug 2015 21:58, Stephen Warren swarren@wwwdotorg.org wrote:
Is there any guarantee that the voltage levels are high enough for the AVP to run correctly before the CORE rail is adjusted? It sounds to me like a HW design issue; the SoC reset output should reset the PMIC too.
If by guarantee you mean whether it is impossible by software to completely screw the rail configuration no there is no such guarantee. But even on T30 where usually some PMIC GPIOs are used to switch to a sane default software could mess up the configuration of that as well. To prevent any of that I guess a higher level of trusted computing stuff would be required. At the end we just have to assume that regular DVFS operation should never leave it in a completely unbootable state.
On 08/20/2015 04:59 PM, Marcel Ziswiler wrote:
On 20 Aug 2015 21:58, Stephen Warren swarren@wwwdotorg.org wrote:
Is there any guarantee that the voltage levels are high enough for the AVP to run correctly before the CORE rail is adjusted? It sounds to me like a HW design issue; the SoC reset output should reset the PMIC too.
If by guarantee you mean whether it is impossible by software to completely screw the rail configuration no there is no such guarantee. But even on T30 where usually some PMIC GPIOs are used to switch to a sane default software could mess up the configuration of that as well. To prevent any of that I guess a higher level of trusted computing stuff would be required. At the end we just have to assume that regular DVFS operation should never leave it in a completely unbootable state.
That almost sounds like there's no need for this patch/series then, since we're assuming that SW won't leave the HW in a bad state. If SW can leave HW in a bad state, the only choice is to fix the issue in HW. However, perhaps you mean there are some states that are worse than others; we assume that the rails required for the AVP are always in a good state but the rails required for the CPU/CCPLEX may not be?
participants (2)
-
Marcel Ziswiler -
Stephen Warren