Good Afternoon,
I have successfully booted 4.14 and 4.16 on the Ouya, with L2 cache support.
I am having three major hangups right now.
I can't seem to find a valid frambuffer driver for the fbconsole.
The old kernel eEMMC support seems to be a hack job.
There is no cpufreq support for the t3, though there is for the t2 and
for the t114.
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
