anarsoul|2 has quit [Remote host closed the connection]
anarsoul has quit [Ping timeout: 272 seconds]
<Myy>
Ok, I'm starting to figure it out. Mainline kernels do not enable the IOMMU_DMA API on RK3288 boards
<Myy>
Forcing the IOMMU_DMA API generates panics on boot ! Yay !
JohnDoe_71Rus has joined #linux-rockchip
<Myy>
It seems that the VOP MMU breaks. So unplugging the HDMI cable allows the system to boot. However, I still have the same issue with the VPU driver. It runs but no output.
<hanetzer>
Myy: I'll be frank, I don't use it myself (gentooist), but I realize it to be greatly needed until stuff hits mainline and we liberate the vpu/mali :)
<Myy>
Well, it's one of the main roadblocks from using mainline kernels for many people who wants to use it as standard PC, which includes playing videos on Youtube and Netflix.
<Myy>
I had a Gentoo on a MiQi system but it died after a while. I still use Gentoo on my main PC though.
<hanetzer>
aye. I have two asus c201 chromebooks (4gb ram models), I've been doing dev work on u-boot for them :)
<Myy>
Ah, I'll have to delve into U-Boot one day, in order to deal with the dreaded ASUS Tinkerboard reboot issue.
<Myy>
I still can't believe that made a system that forgets to setup the MMC correctly on reboot and hangs.
<Myy>
But it only works with standard reboot. Panic reboot does not work. It goes back on U-Boot then fails to setup the MMC voltage and gets stuck.
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 is now known as cnxsoft
<hanetzer>
Myy: nifty. currently I'm waiting for upstream u-boot to support gt 0xffff_ffff bytes of ram on 32-bit rockchip targets. I have a kludgy fix for that which I stole from coreboot which clamps it to 0xff00_0000 for the rk3288 :P
<Myy>
Didn't they enable LPAE on some RK3288 boards ? I remember that the whole Rockchip 32 bits DTS{,I} files were changed to use 64 bits addressing for that reason.
<hanetzer>
no idea offhand. did some testing and back and forth on the ml
<Myy>
I see.
<Myy>
ezequielg, If you got anything written to the output buffer, let me know. And if you don't, my guess is that there might be something missing in the DTSI definition.
<Myy>
Beside the power domain not being defined in the VPU MMU ( -_-)
<Myy>
The old IOMMU initialization code seems to be a red herring, IMHO
<ayaka>
Myy, I have replied your mail
<Myy>
Yes, I saw that
xerpi has joined #linux-rockchip
<ayaka>
ayaka, do you know my new vpu driver
<Myy>
But like I said, porting the MPP device driver will just piles up more issues, since a few other things are missing (IOMMU_DMA) or are done differently in recent kernels (iommu_domain_alloc ...).
<ayaka>
you may refer the iommu and dma code from it
<Myy>
And I can't test it since I'm basically relying on Armbian for 4.4 kernels and they cannot compile them anymore, it seems.
<Myy>
So I looked at the code, and it's way cleaner than the vcodec_service.c code
<Myy>
But there are a few things here and there that I have to see with Jacob Chen and other Rockchip developers working on mainline kernels, before being able to port it.
<ayaka>
basically you are suffering the iommu problem
<ayaka>
Jacob doesn't work for rockchip anymore
<Myy>
Well, not per-Se. I found a way to enable the IOMMU_DMA option on mainline kernels. While it breaks the video output, the kernel can still be booted. I then loaded my driver and... same issue.
<Myy>
The IRQ is triggered, the registers are slightly changed but nothing else.
<Myy>
The IOMMU fault handler is not called.
<Myy>
The output buffer is unchanged
<ayaka>
well, there is a patch in kernel 4.4 to disable the auto iommu loading for vop
<Myy>
That would be the issue ?
<Myy>
For VOP, anyway ?
<Myy>
I'm starting to wonder if that's really an IOMMU issue.
<Myy>
I think it's more a bad setup of the encoded frame, or the quantization table
<Myy>
Still, I'll first try to disable an old patch that I still kept around