Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by jernej

  1. well, I've been messing with Linux kernel and especially sunxi drivers for several years
  2. That wiki article is missing explanation how to calculate pin number in case of multiple pin controllers. PL2 is on second controller, where first port is "L". So pin number calculation is actually 0 * 32 + 2 = 2.
  3. H313 is basically the same as H616, so you can try any of those variants. But of course there is no guarantee any of it will work...
  4. That is default fallback resolution when kernel can't read resolution info from display (on all platforms and architectures). There can be multiple reasons, like cable, monitor, some kernel/driver issue...
  5. Your understanding is incorrect: 1. VDPAU was used only with vendor kernel, which is obsolete for a long time. Armbian uses only mainline kernel. 2. No need to worry due to 1) 3. GPU doesn't do anything for video decoding. That's desktop PC concept. Embedded SoCs have dedicated VPUs (video processing unit). But it's true that ffmpeg need patching. More specifically, it needs v4l2 request api support. 4. That's not necessary if ffmpeg libraries are patched and installed system wide. Last but not least, v4l2 request video decoding support is tested only in Kodi GBM mode. This means that it must be started from console, when no desktop environment is running. Maybe wayland mode would work, but I don't know. Certainly it won't work under X11. You have to use software decoding there.
  6. AFAIK, mainline kernel isn't meant to be booted in secure mode and this is just to allow BSP kernel to be booted. I might be wrong, though. Just try running in non-sec mode.
  7. That's not true anymore. MPV support it via GPU rendering in v0.35 for both, X and Wayland. However, you still need patched ffmpeg for that.
  8. Latest stable version of mpv also supports video playback with patched ffmpeg, even in x11 and wayland. If Armbian would package such ffmpeg, it would make almost trivial for people to watch movies using mpv on desktop.
  9. It has nothing to do with video decoding. Read posts right before yours.
  10. NV15, although sounds standard, it's not. It's RK invention and used only (AFAIK) on their chips. So I would presume not many mesa developers are aware of it and even less care about it. Note, EGL has nothing to do with DRM planes. EGL lists format supported for GPU rendering and DRM planes lists formats supported by Direct to plane rendering. There is catch, though. ffmpeg must provide proper mapping to DRM descriptor. I have no idea if that's done for NV15 in ffmpeg rkmpp module. If that's not done, direct to plane method won't work. Note that I don't care about vendor solutions and I'm only indirectly involved with RK platforms, so I can't help you more.
  11. Driver needs a bit of rework since Cedrus on H6 needs a bit different initialization. I guess you need this for video encoding?
  12. Well, if freezes it's doubtful that it will work with newer image. Your box is different than OrangePi board, so most likely reason why it freezes is that electronics is not compatible and you would need device tree file (HW description) tailored to your box. This is not an easy task for a beginner. You can copy 1 MiB from that image, starting at 8 KiB offset. However, U-Boot has many board related configuration hardcoded, so I can't promise it will work.
  13. Bootloader has to be written to SD card at offset of 8 KiB. dd command for this would be: sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1k seek=8 conv=fsync NOTE: Replace /dev/sdb with proper path to your SD card.
  14. ZQ value should be in decimal, so 3750393. Other than that, it should be ok. Just be sure to write U-Boot to right location. How do you write U-Boot to SD card?
  15. jernej

    TV out

    It's not supported on H6 yet.
  16. Uh, your box uses RAM with extremely low frequency. All images you tested have about 2 times higher frequency set. This alone is very likely the reason for non working RAM. Additionally, ZQ value is different, but usually that's not a big problem. With these two changes, you can already customize U-Boot config, build it and replace it on one of the images.
  17. Please write in english, I don't speak russian. Yes. Most of them contains partial DRAM configuration. Not enough to configure DRAM properly, but enough for quick check. Just copy first 1 MiB from eMMC, you can use dd command for that. There is plenty of guides on net. You still didn't tell which Armbian image you tried to boot.
  18. This was maintained right - obsolete vendor kernel which hinders many modern functionality (wireguard, for example) was replaced with mainline kernel, which receives non-stop fixes and improvements for the cost of not supporting some HW features, which still can be eventually supported. DDR frequency scaling is mostly regarded as power saving feature, so most people don't care if board consumes few mA more or less. Only recently such driver was added for Allwinner A64 and H5, but these are pretty different from A20, so driver most probably can't be easily extended.
  19. You should tell which image you tried to use and in order to be able to do anything, boot log of original FW (probably Android) and extracted sys_config.fex or first megabyte of bootloader, so it can be extracted from there.
  20. It's ARM9 core, so it's very old architecture. Only BSP kernel exists, but who knows where source can be found. So, even if sources for kernel can be found, it would be a waste of time to support it in Armbian.
  21. First of all, I assume you installed patched ffmpeg libraries system wide? I saw mpv complain if installed ffmpeg libraries are different version that the version that mpv was built with. In such case, you have to also rebuild mpv. Second, mpv will use v4l2 request acceleration only in gbm mode, e.g. when no desktop environment is running. I guess nobody wrote support for converting dma-bufs to gles buffers, even though mesa have function for exactly that. Simple, RPi foundation has enough power to convince various players to support their proprietary API. Others did not. Similarly, Android is popular enough that vendors hammer their own proprietary solution into their ports. Only now various HW decoders are being unified under v4l2, either with request api or stateful api. Currently only gstreamer has good native support for these apis out of the box (HEVC will be supported in next stable release).
  22. jernej

    Mainline VPU

    That's not the case. Collabora was contracted to work on Hantro and RKVDEC driver, that's why there is a major push to improve these drivers and make API stable. While LE always had good enough patches for missing functionality, there was lack of time to actually push them in mainline. It's not, but @Kwiboofixed most issues for media playback long time ago, so his DRM/KMS patches are still maintained in LE.
  23. jernej

    Mainline VPU

    Well, you can always wait until any issue is resolved by LE developers.
  24. jernej

    Mainline VPU

    Deadline for media patches was extended for another week, due to additional RC version for 5.19. Let's see if RKVDEC HEVC manages to sneak in.
  • Create New...