On 13.03.2018 21:08, Peter Geis wrote: > Good Afternoon, > > I have successfully booted 4.14 and 4.16 on the Ouya, with L2 cache support. Awesome :) > I am having three major hangups right now. > > I can't seem to find a valid frambuffer driver for the fbconsole. Please show the dmesg log, it should contain some errors. Add drm.debug=0xe to the kernels cmdline. > The old kernel eEMMC support seems to be a hack job. Most likely eMMC has a custom downstream partitioning that is not supported by upstream. You should be able to specify partitions manually using CONFIG_CMDLINE_PARTITION, though I never used it myself. If that's your problem with eMMC. > There is no cpufreq support for the t3, though there is for the t2 and for the > t114. Yes, seems there is no cpufreq driver for T30 in upstream. Probably shouldn't be difficult to implement it. > If any of ya'll have more suggestions, I would greatly appreciate it. > > Also, thanks again for all the fish. > > > On 03/05/2018 04:34 PM, Stephen Warren wrote: >> On 03/04/2018 07:31 AM, 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. >> >> I think it'd be best to be explicit and have a firmware node if possible. >> While the procedure I mentioned above does appear to work, I think that where >> there is DT, this kind of configuration should come from DT if possible. >> >>> 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? >> >> Doesn't T114 have Cortex A15? IIRC the L2 cache controller is different >> between A9 and A15, and perhaps the control mechanism is different? >> >>> 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? >> Quite likely there's a carve-out yes. In systems I'm familar with (which >> doesn't include T114 any more) this is usually right at the top of physical >> RAM. Hopefully the memory node that's passed to the kernel already has had its >> size reduce to take account of the carve-out. > -- 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
