Good Morning,
The L2 cache init was a separate entity on the A9, then in the A15 they
moved it into the bootloader firmware.
The L2 cache documentation references this,
Documentation/devicetree/bindings/arm/l2c2x0.txt
The issue I was having with this was the trusted foundations code,
Dmitry sent me a patch offline that solved the issue.
Now I am tracing down a hung task, caused by what I think is a missing
reset trigger.
On 03/04/2018 10:10 AM, Dmitry Osipenko wrote:
On 04.03.2018 17:51, Mikko Perttunen wrote:
On 03/04/2018 04:31 PM, Dmitry Osipenko wrote:
On 02.03.2018 20:10, Stephen Warren wrote:
On 03/02/2018 06:27 AM, Peter Geis wrote:
Good Morning,
I have an OUYA console that I am attempting to get the 4.14 kernel booted on.
It is a Tegra30-Cardhu based system, which from what I can tell had as many
corners cut during development as possible.
I do not have access to the firmware itself, and the firmware does not support
anything beyond 3.1.10, so I am using a kernel appended DTB.
The issue I'm running into right now is I cannot get the layer 2 cache
controller, a PL310, to init correctly.
I can disable the function, and I boot till DMA starts accessing hardware and
go into a hard lock.
If I have the L2C enabled, it kernel panics during L2c310_configure, while
trying to write the secure registers.
I am pretty sure the firmware is not using secure mode at all, and in the
cache-l2x0.c source the function states "By default, we write directly to
secure registers. Platforms must override this if they are running
non-secure."
You can tell whether SW is running in secure mode; see below. This will tell you
whether (a) there's just some general bug, or (b) the kernel is running in
non-secure mode and needs adjustment to do so, since that's probably not
currently supported.
To find out how to tell, see the following code in U-Boot:
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-tegra/board.c;h=b3a041b539af80ae7b75e3f709931ab92ff1a213;hb=refs/heads/master#l52
While that is only validated on Tegra124, I expect it works the same on Tegra30.
The PMC address and/or mc_security_cfg0 register offset might need to be
adjusted though; track down the definitions for both chips in U-Boot's header
files to check.
I've applied that 'secure mode' check to the reset handler and it works fine on
non-secure T30, as well as on secure T20. This looks like a nice feature, so we
don't even need the firmware node in DT and instead could check for the mode in
runtime.
Upstream kernel has DT files for T114 Roth and TN7 devices that have firmware
node, but the TF code doesn't implement firmware calls to initialize the L2
cache yet. Stephen, do you know if Roth and TN7 devices are just broken or T114
doesn't need these L2 firmware calls?
Also, do you know where firmware code is stored? Maybe there is a part of DRAM
that is reserved for the firmware and then it should be taken into account by
the kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
I know roth worked fine with https://github.com/linux-shield/kernel back in the
day, and I'm not seeing any related patches there either, so maybe the
initialization is not required or it's done by the bootloader.
I noticed that t114 doesn't have L2 cache node in DT. So yes, either cache is
handled by firmware without involving kernel or L2 just kept disabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
