jernej

  • Posts

    1048
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by jernej

  1. Branch https://github.com/apritzel/linux/commits/h616-v2 is currently the best we have. With it following peripherals are supported and nothing more: - serial - ethernet - SD card - RTC - watchdog (needed for reset) - GPIO/I2C/SPI/UART (if you enable them manually) - SPI flash HDMI, USB and other more complex stuff is not understood enough to be implemented. If you need it, use images from OrangePi, but don't expect support here.
  2. Here is fixed v2 version: https://github.com/jernejsk/u-boot/commits/h616-v2 Note - it's not finished yet, so it will still change (force pushes).
  3. Yeah, I forgot to add A100 compatible to mmc driver, that's why it doesn't boot.
  4. @valantissue is more complicated than just some config option. Currently U-Boot doesn't support voltage regulators and rely on ATF to enable them (A64 has HDMI voltage supply pin). Logic in ATF will turn on all referenced voltage regulators, which is mostly fine. Issue is in word "mostly" - this logic will prevent ethernet PHY to power on correctly on OrangePi 3. Distros must decide what is lesser evil for time being, having no HDMI and ethernet in U-Boot or having no ethernet in Linux on OrangePi 3 (I didn't check what Armbian does exactly). Situation was discussed with maintainers and consensus is to implement voltage regulator driver in U-Boot, but that will take time. In the mean time, ATF could be updated with a improvement, which would temporary solve both situations, but I didn't find any patch for that yet.
  5. jernej

    Mainline VPU

    H264 related headers are moved to UAPI in 5.11 and thus considered stable. ffmpeg patches are already on ML but it will take some time before they're merged. HEVC is sadly still in verly early stages and basically useless without heavy patching. Next stable codecs will most likely be MPEG2 and VP8. Note that codecs are driven by developers interest and HEVC is not on top of the list for paying customers, most likely because of patents.
  6. mainline U-Boot also don't have TV out support for H3, unless out-of-tree patch is included in Armbian (I'm not sure)... Anyway, this would bring only simplefb support which has no features - no planes, only one bit depth, one color format, no double buffering, etc.
  7. jernej

    Mainline VPU

    libva-v4l2-request is not driver specific, it has same issues with Cedrus too. It was just proof of concept/tech-demo. Bootlin doesn't have time to maintain it. Codecs are moving targets for now, first stable codec will be H264 in 5.11, MPEG2 and VP8 will follow soon after, probably in 5.12 already. HEVC is in early stages, so that won't be stable soon.
  8. T95 needs different configuration of DRAM driver. Quick and dirty T95 U-Boot port with appropriate defconfig can be found here: https://github.com/jernejsk/u-boot/commits/t95
  9. TV out is not supported on mainline kernel at the moment.
  10. Those patches are for A100, not H616. The biggest issue for cpufreq is making opp table - you have to make sure that each point is stable. BSP one is good starting point, but testing is not fun. On top of that, it's very good to have thermal driver working, to prevent burning hot SoC... I don't plan working on OPP...
  11. I don't see anything out of the ordinary, but note that there are newer Linux patches: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=394711 However, they shouldn't change anything AFAIK.
  12. That's expected, only things that I explicitly stated work - so SD card, network and serial console. Maybe also SPI and I2C, but I don't test buses unless some device is connected to it. Strange. It works for me. Make sure you have DT node which reserves memory for firmware. Without it, ATF will be overwritten and reset won't work. Other than that, I don't know. Why would be that strange? AFAIK kernel disables unused voltage regulators.
  13. Certainly. I'm using unified approach for quiet a while on LE. Strange. I use Arch 32-bit userspace without any big issue.
  14. At the end of U-Boot build process you should get u-boot-sunxi-with-spl.bin - this is now unified for 32 and 64 bit SoCs for some time now. It is possible that names of intermediary files changed since script for generating single binary was moved from shell script to python one recently.
  15. I just updated that branch, now it can boot normally from SD card. You'll also need TF-A and Linux to make it usable: https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP https://github.com/apritzel/linux/commits/h616-WIP UART, ethernet and SD card already work, so it already works good enough for headless server...
  16. Me too. I just tested it last week and it felt much smoother than OPi3. For example, ~125 MiB file is consistently transferred in ~2 seconds on pineh64, while on OPi3 can also sometimes takes 2 seconds, but most of the time 8-14 seconds (all via scp). Why do you think so? AFAICT almost everything is mainlined, with wifi patch merged yesterday and bluetooth not yet, but patches exist. On the other hand, OPi3 still requires several out-of-tree patches for ethernet due to unusual ethernet phy power design.
  17. jernej

    Mainline VPU

    AFAIK HEVC is not yet supported in RK driver but some WIP patches exists. Try H264 first.
  18. jernej

    Mainline VPU

    Well, DRM PRIME acceleration is the most efficient one for ARM boards and disabling it means that CPU will use much more resources than it's needed. In fact, v4l2-request hwaccel patches for ffmpeg were developed together with DRM PRIME acceleration in Kodi. Note that DRM PRIME acceleration consists of two parts: 1. DRM PRIME HW decoding 2. DRM PRIME zero-copy rendering First one is absolutely necessary to have it enabled, otherwise VPU won't be used and instead video will be SW decoded. Second one is still very important - it bypasses GPU for rendering and instead it uses DRM planes which is much more efficient. This is important for SoCs with weak GPUs like mali400. However, it will only work with GBM version of Kodi and maybe wayland. Although I never tested it with X11, I'm pretty sure it won't work. So for X11 you have to set DRM PRIME rendering method to GLES (I guess). At this point I'm not sure if X11 and GLES even work together and most ARM GPUs don't support GL, only GLES (I really don't use X11 on ARM boards, so I don't know). What is your SoC? Do you use X11 desktop? What is your CPU utilization during video playback (press "o" during playback)? Normal utilization is about 10% of one core.
  19. Sadly noone maintain vaapi layer, so you're mostly on your own there, which means learning a ton of internal details of vaapi, v4l2 request api and supported codecs. On the other hand, ffmpeg fork with v4l2 request api is pretty well maintained. I know this is not ideal, but for example mpv (with one patch) can work with that modified ffmpeg.
  20. Note that @Kwiboo's ffmpeg is assuming that kernel is patched with some out-of-tree patches (you can find them in LibreELEC build system). For example, if you remove this commit, output should be much better, but that would mean that interlaced videos will be decoded incorrectly. Good news is that with Linux 5.10 H264 API will be aligned and no out-of-tree patches will be necessary anymore.
  21. I mean flags in source, not compile flags. Check what has been removed in h265.c and restore it, with new flag or field names.
  22. mpv uses system ffmpeg libraries, so you have to re-compile ffmpeg package with v4l2 request api patches. You need this mpv patch.
  23. BTW, while your approach may work to some degree, note that you don't set bunch of flags for h265. This may work only in very specific cases. Certainly h265 should be worse than before.
  24. Basically yes. Note that kernel patches are only for improvements - fixing decoding issues. At least H264 API should be promoted to stable with kernel 5.10, maybe others too. Any player which uses ffmpeg directly should be able to benefit from those patches. AFAIK mpv needs only one simple patch in order to use this chain. I have no idea about VLC internals so I can't say much about it. About VAAPI - request API (Cedrus implements it for decoding) is similar in terms of requirements and features to VAAPI so Bootlin created simple library to expose it. That way they could use any VAAPI capable player. However, some codec interfaces changed considerably from those times and Bootlin didn't invest any time to update this library, so it's not very useful ATM unless you know how to fix it. I know that some people has still interest in that library so I imagine it will be forked/updated once api stabilizes further. Note that there is one hidden issue. As long as you play video in native size, all is well. If you want to scale it then you might get a lot of dropped frames. Issue here is how you do scaling. It's pretty intense process for CPU so you should avoid that at any cost. Unfortunately, VLC with VAAPI translation library did just that. Second option is to go with GPU. IIUC it was impossible to do with binary drivers due to missing import buffer functions, but with mesa it should work now (didn't try it myself). Note that mali400 may still be limiting factor for some cases. Another approach is to use dedicated HW cores. For example, deinterlace core on H3 can be used for scaling only (with few driver tweaks). Downside of this is that scaling process depends on SoC. This would be different even for Allwinner SoCs (not all SoCs have deinterlacer). Most efficient approach (used in LibreELEC) is to use DRM planes - you instruct display engine how to scale and crop it and where on screen to render it. However, I'm not sure if this can work on X11 at all. Wayland should be able to pull this off IIUC. Disclaimer: I don't care about desktop on ARM boards so I didn't do many experiments in this regard and I don't plan to work on improving desktop experience. LE runs without any desktop on ARM boards. Note that I also don't plan to work on any player except ffmpeg/Kodi combo.
  25. Note that ffmpeg patches for request API are important - without patched ffmpeg, all kernel patches have no meaning. Second important thing is that LibreELEC runs Kodi without X11 for ARM boards - this allows to use display more efficiently. On X11 it would be needed to render video through GPU which is less efficient. Note that I never actually tried that.