Jump to content


  • Posts

  • Joined

  • Last visited

Other groups



Recent Profile Visitors

21925 profile views
  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?
  • Create New...