jernej

Members
  • Content Count

    681
  • Joined

  • Last visited

1 Follower

About jernej

  • Rank
    Embedded member

Recent Profile Visitors

1420 profile views
  1. Of course, I'm using Paul's Kodi hack for the moment, but it is proof-of-concept quality. Nope, but it shouldn't be hard to do. I'm maintaining patches for 4.18 for LibreELEC. But truthfully, I didn't test it on anything else than LibreELEC + Kodi on H3. If there won't be any surprises, driver will be merged in 4.20 kernel.
  2. 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.
  3. 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.
  4. 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.
  5. Due to non-optimal algorithm for recognizing RAM size in U-Boot, which can recognize only power of 2 sizes. For example, 512 MB, 1 GB, 2 GB, 4 GB...
  6. jernej

    1280X1024 resolution Orange Pi

    @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.
  7. That will change hopefully during this year with community build LibreELEC at first and after it becomes stable, also official build.
  8. jernej

    AV/HDMI switch and display rotation

    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).
  9. jernej

    AV/HDMI switch and display rotation

    That can work only if /dev/mem (or kmem?) access is permissive, i.e. it is allowed to access device memory regions from userspace. Additionally, daemon has to be run as root (maybe you can drop priviliges later?). That being said, it can work. HDMI PHY status register is 32 bit wide, located at 0x01ef0038 and as you can see from above snippet, you have to check bit 19.
  10. jernej

    [Solved] SDRAM parameters

    It's the later. sunxi platform doesn't use DT in SPL.
  11. jernej

    [Solved] SDRAM parameters

    Actually, Armbian (mostly) uses mainline U-Boot which has reverse engineered DRAM code from Allwinner blobs. Armbian for H3 is definetly such. Because reverse engineering is a pain, even more so when there is no documentation, most people are happy when it works nicely. Optimizations in this area are rare. You can still use BSP U-Boot, which has configurable DRAM settings. But it's ancient version with fex files (something totally Allwinner specific), so using mainline U-Boot (with reverse engineered DRAM driver) is very much preferred and done as soon as feasible. BTW, even mainline U-Boot has some settings for RAM. I suggest you take a look at them, but don't expect miracles, since DRAM controller is (at least afaik) not fully understood.
  12. jernej

    [Solved] SDRAM parameters

    Allwinner doesn't release any DRAM documentation. Actually, very few companies do. Presumably due to licensing terms with IP block vendor.
  13. No, unless you want to write a driver for completely undocumented controller with no or very little source code (reverse engineering ftw). It seems that something can be concluded from sunxi-dramfreq.c, which can be found in BSP kernel source, but AFAIK, no one works on that. Yes, you have to change CONFIG_DRAM_CLK. But be very careful what you set here. Going up is completely discouraged.
  14. If you are ok with fixed lower frequency, you can rebuild U-Boot, or more specifically, SPL with wanted frequency and use that one instead.
  15. jernej

    New Mali blobs (Allwinner, mainline)

    No, there is very strange issue. When you are walking through Kodi menus, half of the screen has new menu and half old menu. Useless at this point. This is with Rockchip Mali450 GBM 32 and 64 bit blob... Tried many changes to correct this, but nothing helped. I never tried X11 or FBDEV blobs, because they are useless for my purpose. My base is Maxime driver with Icenowy changes for mali450, with some other changes which are not important. BTW, all blobs on free-electrons github are for mali400. Although there are mali450 strings in r8p1 blobs, actually important is VARIANT= string, which is still mali400.