jernej

Mali is only 3D accelerator, so I'm not sure what you mean exactly by that. If you mean HDMI output, that's entirely different thing, but it works. However, without any kind of acceleration.
 
Mali T720 is not supported at all at this moment, however it will be soon.

In case of Allwinner port of U-Boot, ATF (bl31.bin) gets packaged into itb file (u-boot.itb), along with U-Boot proper (u-boot.bin) and dtb file. You should just combine sunxi-spl.bin-arm32 (make sure is padded to 32K or 24K, I'm not sure ATM) and u-boot.itb.
 
BTW, I'm not sure if mainline Linux works with BSP ATF binary. Just compile latest official ATF release (mainline H6 ATF is not board specific, so it should work).
 
Not sure, I don't use earlyprintk. If it's not CPU mode issue (Linux expects that it's already in 64-bit mode) it may be DT issue.
 
Anyway, I wouldn't bother with Linux at this stage. Fixing mainline DDR3 DRAM driver would help a lot with other issues.

There is also VP9 decoding IP core , which is present in Allwinner H6, NXP i.MX8 and I think Rockchip has it too. It may be connected to Hantro and Google, but I'm unsure who is the original author.

@NicoD @johanvdw Actually with some of the out of tree patches is possible to make it work. After all, I have fully functional LibreELEC image for PineH64. Well, not completely everything, but HDMI audio works pretty well. Patches are here and here. Btw, dma patches are important for audio and you have to enable sun4i-i2s driver and simple audio card if it's not yet.

@NicoD @johanvdw Actually with some of the out of tree patches is possible to make it work. After all, I have fully functional LibreELEC image for PineH64. Well, not completely everything, but HDMI audio works pretty well. Patches are here and here. Btw, dma patches are important for audio and you have to enable sun4i-i2s driver and simple audio card if it's not yet.

@froezus
can you check if hdmi works after applying https://patchwork.kernel.org/patch/10882335/mbox/ ?

I must have done something wrong, because after another trial, it works !!!
So, I will investigate to figure out "what are the differences between those 2 u-boots", because I didn't found any yet ...
 
EDIT : Bingo ! The missing thing is CONFIG_NR_DRAM_BANKS=1, although the documentation isn't explaining why, but it seems that diffs between OPis and PineH64 revealed this.
I will do full image for OPiLite2 and OPiOnePlus and see if this issue is definitively gone ...

Issue is that U-Boot DT is missing ethernet0 alias. Solution is that you patch U-Boot, like I have done for PineH64 here.

Actually I already make it work on mainline: https://github.com/jernejsk/linux-1/commits/h6_i2s But I didn't sent patches yet, because DMA patches (pre-requirement) are still pending.

It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
 
Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).

It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
 
Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).

It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
 
Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).

DMA channels for SPI0 are 22 and 22 (Rx, Tx).
 
BTW, I already sent patches, but I still want to know if it will work for you once you fix DT issues.

It would be weird if you wouldn't get this error. This actually tells you that U-Boot checked if environment variables are stored somewhere. It looked at configured place, noticed that CRC doesn't match and concluded that it will use default environment instead.
 
In short, this error is normal and it would go away only if you would execute "saveenv" command in U-Boot.

I have H6 DRM patches prepared for 4.20, so you can just copy them over. However, I think you would need some more of them for 4.19. Currently, we're investigating some troubles with HDMI, so it's not stable yet anyway.

I'll try to add support for it soon. But it will be in the same boat as others at first. Don't expect to have 10 bit HEVC support at the beginning. BTW, VP9 is separate peripheral so it needs separate driver. Since nobody did reverse engineering yet, it will take a long time to be supported. However, it seems to be Webm project reference VP9 HW decoder, so there is a great chance that other SoCs from other manufacturers have same unit and someone else might write a driver for it.

I'll try to add support for it soon. But it will be in the same boat as others at first. Don't expect to have 10 bit HEVC support at the beginning. BTW, VP9 is separate peripheral so it needs separate driver. Since nobody did reverse engineering yet, it will take a long time to be supported. However, it seems to be Webm project reference VP9 HW decoder, so there is a great chance that other SoCs from other manufacturers have same unit and someone else might write a driver for it.

Why it can't be both? I have commit rights for LE and I'm maintainer of allwinner branch (until it's merged in master). And everything I do is in my spare time. As it is the case for any other LibreELEC developer.
 
And 4.20 will be out around Christmas, so I guess I'll merge all HW decoding related patches to allwinner branch around then. But you can get my WIP stuff from my github.
 
BTW, merged version won't use libva-v4l2-request, but native ffmpeg integration.

Why it can't be both? I have commit rights for LE and I'm maintainer of allwinner branch (until it's merged in master). And everything I do is in my spare time. As it is the case for any other LibreELEC developer.
 
And 4.20 will be out around Christmas, so I guess I'll merge all HW decoding related patches to allwinner branch around then. But you can get my WIP stuff from my github.
 
BTW, merged version won't use libva-v4l2-request, but native ffmpeg integration.

That is unfortunate. The only other solution I know is this:
sudo su cd /sys/kernel/debug/dispdbg/ echo "switch" > command echo "disp" > name echo "0 5" > param echo "1" > start Actually, second number for "param" could be anything. If you want to reenable, then you should write "4 5" to param, where 4 means HDMI output and 5 is wanted resolution, the same number as it is used in script.bin and with h3disp utility (most commonly 10 for 1080p60 and 5 for 720p60) .

Address is correct.
 
I would suggest you first find devmem2 program (source is all over the net). It does almost exactly what you want, but universally (you give it physical address on command line which you want to read).

Cons: I never worked on ffmpeg source or V4L2, so there is large amount of code and documentation to research.
Pros: It is the best way to go on for Kodi. It wouldn't even need any change, while for current approach, it needs a patch, which has to be cared for (I''m not sure if approach taken in that patch would be acceptable for upstream Kodi). I think that other problems could also be avoided like excessive buffering...
 
Please don't take that for granted, I don't know ffmpeg well.

Direct access is a bit strong word. Technically, it means that VAAPI layer would be dropped and same interface as in https://github.com/bootlin/libva-v4l2-request would be used (V4L2 interface with new additions).
 
 
If I understand correctly, "untiling" research took a bit more time than anticipated. Please also note that request API patches (base for AW VPU driver) are at v18 (!) written by multiple people outside Bootlin. But now that V4L2 base (request API) and VPU driver base are more or less finished, it should be much easier to add support for other codecs.
 
BTW, you can actually watch movies with current H264 driver. It just doesn't cover all possible variants and from time to time you can see artifacts. Bigger problem is ffmpeg + VAAPI combination for H264, since you often run out of memory (note that VPU can address only 128 MB of memory and currently DT allocate even less). This problem is know and noted on cedrus wiki page. I hope that using more direct approach in ffmpeg this could be solved.
 
Contrary to you, I'm not disappointed, since the work needed to make stable base is enormous. Framework which support such driver (request API) is evolving along AW VPU driver and AW VPU driver will be it's first user.

MPEG2 is with latest version definitely production quality while H264 is not. You must understand that MPEG2 is very simple codec. It seems that focus shifted to H265 because Paul has a contract only until end of August. Fortunately, H264 and H265 share some common features, so work on H265 will definitely help with H264.
 
However, it turns out that ffmpeg + vaapi doesn't work well for some not so well formed MPEG2 files (same issues with Intel vaapi + ffmpeg), while purely SW ffmpeg decoding works well. I kinda started working on direct ffmpeg integration, but I'm not sure if I have enough motivation to actually finish it.

@HANAX please tell me which is your kernel version. If it is based on mainline, there is no need to specify anything. However, just few days ago issue has been found which causes that some resolution don't work. I already prepared some patches to fix that issue.