On 15.03.2018 16:41, Peter Geis wrote: > Good Morning, > > I found these snippets relating to the DRM module. > [ 0.544779] iommu: Adding device 54200000.dc to group 0 > [ 0.548694] iommu: Adding device 54240000.dc to group 0 > > [ 8.112258] [drm] Initialized vgem 1.0.0 20120112 for virtual device on minor 0 > [ 8.118253] Failed to attached device 54200000.dc to IOMMU_mapping > [ 8.132182] Failed to attached device 54240000.dc to IOMMU_mapping I'm not sure why you have this. Though AFAIK IOMMU currently doesn't work properly on T30, so fixing the attachment probably won't help. At least IOMMU doesn't work for me on T30 and I haven't got my hands on trying to fix it yet. > [ 8.145152] tegra-hdmi 54280000.hdmi: 54280000.hdmi supply hdmi not found, > using dummy regulator > [ 8.152191] tegra-hdmi 54280000.hdmi: 54280000.hdmi supply pll not found, > using dummy regulator > [ 8.160787] tegra-hdmi 54280000.hdmi: 54280000.hdmi supply vdd not found, > using dummy regulator > [ 8.173520] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 8.178231] [drm] No driver support for vblank timestamp query. > [ 8.184391] [drm] Cannot find any crtc or sizes > [ 8.188791] [drm] Cannot find any crtc or sizes > [ 8.193264] [drm] Initialized tegra 0.0.0 20120330 for drm on minor 1 > > I have included the full boot log. > Thanks again! Try to disable CONFIG_TEGRA_IOMMU_SMMU in the kernels config. > On 03/13/2018 03:15 PM, Dmitry Osipenko wrote: >> 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
