jernej

  • Content Count

    958
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jernej got a reaction from Werner in OrangePi Zero2 - Allwinner H616   
    I haven't build Armbian for some time now, I'm just the guy who works on upstream U-Boot and Linux support for H616. I build all components separately and then manually put them together.
  2. Like
    jernej got a reaction from kprasadvnsi in OrangePi Zero2 - Allwinner H616   
    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. Like
    jernej got a reaction from Werner in OrangePi Zero2 - Allwinner H616   
    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).
  4. Like
    jernej got a reaction from valant in HDMI output at u-boot load   
    @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. Like
    jernej got a reaction from shacodelico in t95 allwinner h616 armbian   
    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
  6. Like
    jernej got a reaction from guidol in OrangePi Zero2 - Allwinner H616   
    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...
  7. Like
    jernej got a reaction from Werner in OrangePi Zero2 - Allwinner H616   
    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...
  8. Like
    jernej got a reaction from lanefu in Current status of the Orange Pi 3 (H6)   
    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.
  9. Like
    jernej got a reaction from buptsb in OrangePi PC2 H.264 artifacts with sunxi-Cedrus   
    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.
  10. Like
    jernej got a reaction from gounthar in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    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.
  11. Like
    jernej got a reaction from gounthar in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    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.
  12. Like
    jernej got a reaction from JORGETECH in Unable to make Panfrost work on H6   
    GPU, Display Engine and HDMI all have different clock sources. It could still be HDMI clock issue, just different...
  13. Like
    jernej got a reaction from gounthar in Hardware Graphic/Video Acceleration in H3 Mainline   
    Well, kernel modification is needed for better decoding (less glitches). Probably new *-ctrl.h files contain new fields (not 100% sure) which also need to be filled.
     
    There is no any post processing implemented here like scaling. It would be possible to do that via SoC specific peripherals but that wouldn't be universal and thus it's out of scope of this library.
     
    Anyway, I'm glad you succeeded.
  14. Like
    jernej got a reaction from manuti in Hardware Graphic/Video Acceleration in H3 Mainline   
    Well, kernel modification is needed for better decoding (less glitches). Probably new *-ctrl.h files contain new fields (not 100% sure) which also need to be filled.
     
    There is no any post processing implemented here like scaling. It would be possible to do that via SoC specific peripherals but that wouldn't be universal and thus it's out of scope of this library.
     
    Anyway, I'm glad you succeeded.
  15. Like
    jernej got a reaction from Sash0k in Mainline VPU   
    You have to make sure that libva-v4l2-request uses  same *-ctrl.h files that are in kernel sources under include/media/. For starters, just copy them over from kernel to lib source folder. Then you might need to adjust lib sources to new field names. Unless these files are completely the same, you won't have any success.
  16. Like
    jernej got a reaction from nik012003 in Orange Pi Plus 2e H3 how do I get GPU HW acceleration working?   
    Mali is only for rendering, video decoding is done on separate HW core. However, its driver is not finished, VAAPI lib for it is also not finished yet and most of all, firefox supports HW video decoding (e.g. VAAPI) only on wayland. So, nothing that you could use right now. If you want decent video player on OPi Plus2E you can use LibreELEC image (Kodi) which has all work in progress included, but that is probably not something you had in mind (multimedia center app with no browser but youtube addon can be installed).
  17. Like
    jernej got a reaction from gounthar in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Simple, LibreELEC heavily patches kernel and ffmpeg for better experience. Patches are slowly getting in kernel but ffmpeg patches will need far more time to be accepted (kernel must first declare this API stable which won't happen anytime soon). You also need Kodi master (e.g. Kodi 19 pre-alpha), because it has a lot of important improvements. Last but not least, only Kodi GBM (e.g no desktop environment) version really works well (zero copy playback) and soon wayland. X11 has no chances to work well.
     
    TL;DR: LibreELEC uses features which are in development and not present in any stable version yet.
     
    BTW, also 4K HEVC videos work well.
  18. Like
    jernej got a reaction from Myy in Unable to make Panfrost work on H6   
    @Myy small advice - make links to https://github.com/LibreELEC/LibreELEC.tv because I often delete branches which were already merged. linux56 branch will be removed soon.
  19. Like
    jernej got a reaction from sabirovrinat85 in Unable to make Panfrost work on H6   
    No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
    No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.
  20. Like
    jernej got a reaction from NicoD in Unable to make Panfrost work on H6   
    No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
    No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.
  21. Like
    jernej got a reaction from JORGETECH in Unable to make Panfrost work on H6   
    No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
    No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.
  22. Like
    jernej got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    If you have Pinebook in mind and the one from Olimex, they both use anx6345 IIRC. Driver for that chip was merged in kernel some time ago, but it doesn't consider "panel-supply" property. I guess that's what's wrong. @Icenowy?
  23. Like
    jernej got a reaction from TRS-80 in No Ethernet in u-boot (Orange Pi win)   
    You should send patch for that to U-Boot so next person which tries to use USB on OrangePi Win don't need to do that work again.
  24. Like
    jernej got a reaction from TRS-80 in No Ethernet in u-boot (Orange Pi win)   
    OrangePi Win default configuration in U-Boot has only half drivers enabled for ethernet. I fixed that recently with https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi/commit/2936eb2d550a642275113464fc9dcbb03357c049 It will be part of U-Boot v2020.04.
  25. Like
    jernej got a reaction from balbes150 in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    current AC200 Ethernet PHY driver is hacky, so it needs specific combination of drivers set as module and others as build in. You also need PWM driver, which is not yet merged upstream. Check here: