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
