| Message ID | 20180619110027.16935-1-digetx@gmail.com |
|---|---|
| Headers | show |
| Series | Initial support of Trusted Foundations on Tegra30 | expand |
Good Afternoon, I have tested these patches on the Ouya T3 device. They work great to enable the L2 cache controller, however they do not respect explicitly disabling the L2 cache controller via the kernel config nor device tree. With CONFIG_CACHE_L2X0 disabled, but CONFIG_TRUSTED_FOUNDATIONS enabled, the L2 cache controller is silently enabled and allows all four cores to boot. One must also disable CONFIG_TRUSTED_FOUNDATIONS to stop the L2 cache controller from spinning up. Tested-by: Peter Geis <pgwipeout@gmail.com> On 06/19/2018 07:00 AM, Dmitry Osipenko wrote: > Hello, > > This series of patches brings initial support of Trusted Foundations to > Tegra30, that is to the consumer-grade Tegra30 devices which do not allow > to easily replace the proprietary bootloader. Support is initial because > this series implements only a proper CPU boot-up (main + secondary cores) > and a basic L2 cache maintenance that is done using the TF firmware. > Suspend-resume support is missing yet as I couldn't get it to work > (CPU hangs on resume from suspend after awhile and seems that is related > to inappropriately done cache maintenance during of suspend-resume using > the firmware), it is work-in-progress for now. > > This patchset is partially based on the work done by Michał Mirosław [0]. > > [0] https://www.spinics.net/lists/linux-tegra/msg30368.html > > Changelog: > > v2: > - The "Don't apply CPU erratas in insecure mode" patch got some > cleanup, in particular resolved the messiness in > __tegra_cpu_reset_handler_data. > > - Added a comment to tf_cache_write_sec(), justifying the warning > message. > > Dmitry Osipenko (5): > ARM: trusted_foundations: Implement L2 cache initialization callback > ARM: trusted_foundations: Provide information about whether firmware > is registered > ARM: tegra: Setup L2 cache using Trusted Foundations firmware > ARM: tegra: Don't apply CPU erratas in insecure mode > ARM: tegra: Always boot CPU in ARM-mode > > arch/arm/firmware/trusted_foundations.c | 32 ++++++++++++++++++++++ > arch/arm/include/asm/trusted_foundations.h | 7 +++++ > arch/arm/mach-tegra/reset-handler.S | 25 +++++++++-------- > arch/arm/mach-tegra/reset.c | 5 +++- > arch/arm/mach-tegra/reset.h | 9 ++++-- > arch/arm/mach-tegra/sleep-tegra20.S | 4 +++ > arch/arm/mach-tegra/tegra.c | 15 ++++++++++ > 7 files changed, 82 insertions(+), 15 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, 29 June 2018 22:37:02 MSK Peter Geis wrote: > Good Afternoon, > > I have tested these patches on the Ouya T3 device. > They work great to enable the L2 cache controller, however they do not > respect explicitly disabling the L2 cache controller via the kernel > config nor device tree. > > With CONFIG_CACHE_L2X0 disabled, but CONFIG_TRUSTED_FOUNDATIONS enabled, > the L2 cache controller is silently enabled and allows all four cores to > boot. > I don't see how cache could be enabled with CONFIG_CACHE_L2X0 disabled, there is no code to do that. Could you elaborate please? Secondary cores do not depend on the cache state, disabled cache shouldn't prevent them to boot. > One must also disable CONFIG_TRUSTED_FOUNDATIONS to stop the L2 cache > controller from spinning up. > > Tested-by: Peter Geis <pgwipeout@gmail.com> > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/2018 10:48 AM, Dmitry Osipenko wrote: > On Friday, 29 June 2018 22:37:02 MSK Peter Geis wrote: >> Good Afternoon, >> >> I have tested these patches on the Ouya T3 device. >> They work great to enable the L2 cache controller, however they do not >> respect explicitly disabling the L2 cache controller via the kernel >> config nor device tree. >> >> With CONFIG_CACHE_L2X0 disabled, but CONFIG_TRUSTED_FOUNDATIONS enabled, >> the L2 cache controller is silently enabled and allows all four cores to >> boot. >> > > I don't see how cache could be enabled with CONFIG_CACHE_L2X0 disabled, there > is no code to do that. Could you elaborate please? > > Secondary cores do not depend on the cache state, disabled cache shouldn't > prevent them to boot. On the untouched mainline kernel running on a Trusted Foundations T3 device, I observed the following indications: With the L2 cache controller enabled, all four processor cores were enabled, but it would immediately panic for writing to a secure register from insecure mode. With the L2 cache controller disabled, only the boot core is detected, but it successfully boots. This is the issue that I inquired originally to you about. With your patch running on the same device, the following is observed: With the L2 controller enabled, all four cores are active, and the cache controller appears to function. With the L2 controller disabled, but trusted foundations enabled, the L2 controller enabled kernel message is missing, however all four cores still enable. After looking through the code a little more deeply, I see you modified the reset handler for handling offline cores. I am wondering if you fixed an additional issue inadvertently. The reason I discovered this is I am working with kexec as a bootloader. On a device without trusted foundations, kexec works without issue. On a device with trusted foundations and your patch, I found that disabling the l2 cache controller and trusted foundations allow kexec to occur. I haven't tried an either/or scenario, though now you have me thinking I should. > >> One must also disable CONFIG_TRUSTED_FOUNDATIONS to stop the L2 cache >> controller from spinning up. >> >> Tested-by: Peter Geis <pgwipeout@gmail.com> >> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, 2 July 2018 21:53:08 MSK Peter Geis wrote: > On 07/02/2018 10:48 AM, Dmitry Osipenko wrote: > > On Friday, 29 June 2018 22:37:02 MSK Peter Geis wrote: > >> Good Afternoon, > >> > >> I have tested these patches on the Ouya T3 device. > >> They work great to enable the L2 cache controller, however they do not > >> respect explicitly disabling the L2 cache controller via the kernel > >> config nor device tree. > >> > >> With CONFIG_CACHE_L2X0 disabled, but CONFIG_TRUSTED_FOUNDATIONS enabled, > >> the L2 cache controller is silently enabled and allows all four cores to > >> boot. > > > > I don't see how cache could be enabled with CONFIG_CACHE_L2X0 disabled, > > there is no code to do that. Could you elaborate please? > > > > Secondary cores do not depend on the cache state, disabled cache shouldn't > > prevent them to boot. > > On the untouched mainline kernel running on a Trusted Foundations T3 > device, I observed the following indications: > With the L2 cache controller enabled, all four processor cores were > enabled, but it would immediately panic for writing to a secure register > from insecure mode. > With the L2 cache controller disabled, only the boot core is detected, > but it successfully boots. > This is the issue that I inquired originally to you about. > > With your patch running on the same device, the following is observed: > With the L2 controller enabled, all four cores are active, and the cache > controller appears to function. > With the L2 controller disabled, but trusted foundations enabled, the L2 > controller enabled kernel message is missing, however all four cores > still enable. > This is the correct behaviour. > After looking through the code a little more deeply, I see you modified > the reset handler for handling offline cores. > I am wondering if you fixed an additional issue inadvertently. > CPU will fail to boot if it tries to apply erratas via accessing the secure registers. I've changed the reset handler to skip erratas on T20/30 if trusted foundations present, see "Don't apply CPU erratas in insecure mode" patch. This is an intentional change. > The reason I discovered this is I am working with kexec as a bootloader. > On a device without trusted foundations, kexec works without issue. > On a device with trusted foundations and your patch, I found that > disabling the l2 cache controller and trusted foundations allow kexec to > occur. > I haven't tried an either/or scenario, though now you have me thinking I > should. > Secondary cores are dying in the reset handler in a case of disabled L2 + disabled TF. Looks like there is something wrong in regards to stopping secondary CPU cores / flushing CPU caches, the suspend-resume isn't working right now because of it and likely that kexec is suffering from the same issue. > >> One must also disable CONFIG_TRUSTED_FOUNDATIONS to stop the L2 cache > >> controller from spinning up. > >> > >> Tested-by: Peter Geis <pgwipeout@gmail.com> Thanks for testing! -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kexec works for me on T30 with the following kernel config options on top of the tegra_defconfig: CONFIG_SMP=n CONFIG_CPU_IDLE=n CONFIG_TEGRA_IOMMU_SMMU=n CPU stopping isn't working correctly with the trusted foundations and it's not obvious what is wrong. I hope we'll fix it at some point. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, This series of patches brings initial support of Trusted Foundations to Tegra30, that is to the consumer-grade Tegra30 devices which do not allow to easily replace the proprietary bootloader. Support is initial because this series implements only a proper CPU boot-up (main + secondary cores) and a basic L2 cache maintenance that is done using the TF firmware. Suspend-resume support is missing yet as I couldn't get it to work (CPU hangs on resume from suspend after awhile and seems that is related to inappropriately done cache maintenance during of suspend-resume using the firmware), it is work-in-progress for now. This patchset is partially based on the work done by Michał Mirosław [0]. [0] https://www.spinics.net/lists/linux-tegra/msg30368.html Changelog: v2: - The "Don't apply CPU erratas in insecure mode" patch got some cleanup, in particular resolved the messiness in __tegra_cpu_reset_handler_data. - Added a comment to tf_cache_write_sec(), justifying the warning message. Dmitry Osipenko (5): ARM: trusted_foundations: Implement L2 cache initialization callback ARM: trusted_foundations: Provide information about whether firmware is registered ARM: tegra: Setup L2 cache using Trusted Foundations firmware ARM: tegra: Don't apply CPU erratas in insecure mode ARM: tegra: Always boot CPU in ARM-mode arch/arm/firmware/trusted_foundations.c | 32 ++++++++++++++++++++++ arch/arm/include/asm/trusted_foundations.h | 7 +++++ arch/arm/mach-tegra/reset-handler.S | 25 +++++++++-------- arch/arm/mach-tegra/reset.c | 5 +++- arch/arm/mach-tegra/reset.h | 9 ++++-- arch/arm/mach-tegra/sleep-tegra20.S | 4 +++ arch/arm/mach-tegra/tegra.c | 15 ++++++++++ 7 files changed, 82 insertions(+), 15 deletions(-)