• Content Count

  • Joined

  • Last visited


About jernej

  • Rank
    Embedded member

Recent Profile Visitors

6334 profile views
  1. Any information on this? - Mainline has some better cpu performance, but GPU side of things with panfrost is not well integrated. My testing using kodi on non-legacy builds of armbian and even attempts at archlinux(arm), have shown me that VPU(VideoDecoder) seems to be a mess on the oss side of things, so proprietary drivers seem to be the only way to a functional experience. I wouldn't say mess, just work in progress - with 5.13, MPEG2, VP8 and H264 will be all stable (no need to patch anything), with HEVC and VP9 being in development (most or all supported features reachable with o
  2. @tony013 Fix for RK3399 HDMI audio on mainline has been just merged in LE:
  3. I was speaking about SoC capabilities with first part, not about Armbian setup. Second part is speaking about my experiments about passthrough on mainline.
  4. Yeah, I realized that this topic is about BSP kernel after posting. There will be no more work done for it in LE, next RK release will use mainline. I believe deinterlacing also doesn't work here in Kodi, right?
  5. In short, HW decoding on ARM boards is messy at this moment (check this summary). I'm not sure you'll get far with Kodi on Armbian. LibreELEC uses a lot of out-of-tree ffmpeg and kernel patches to achieve good Kodi overall performance (they are being gradually upstreamed, but that takes time), so I suggest you try that image first. Note: Passthrough on RK3399 is possible - it uses similar peripherals and concept as Allwinner H6, for which I have experimental passthrough patches, even for HBR. But that also needs proper ALSA config, where I have issues... EDIT: I'm talki
  6. No, wifi is not yet supported, it needs some out of tree driver. I don't think anyone bothered to try it out (I'm big skeptic about these wifi modules...).
  7. H6 doesn't support GPU devfreq yet - this feature is mysteriously elusive - all attempts to add this feature ended with GPU lock up. It's possible, because BSP can do that. Currently it runs with default rate, but you can adjust that with some DT magic, like I did that for A64. Note that you probably need to increase GPU power supply voltage too.
  8. This board has 1 GiB of RAM - just multiply 4 x 512M x 4 bits and you get 8G bits which is 1G bytes. You would need 8 chips (512M x 4) to get 2 GiB.
  9. It seems like 4 chips, right? so, 4x 512M x 4 -> 2x 512M x 8 -> 1G x 8 -> 1 GiB Your board has 1 GiB of RAM and DRAM driver properly detected it.
  10. GPU and CPU share same memory bus, so 2 GiB total. If you really want to figure out amount of RAM, you should open your box and post detailed images of the board (both sides), so number and markings on RAM chips can be determined. From that, real amount of RAM can be calculated. It also helps verify DRAM settings (DRAM driver is not "one size fits all", it has to be properly configured).
  11. Ah, you didn't add panel description to DT for Linux. So yes, Linux uses U-Boot FB. 32-bit colours are hardcoded in U-Boot here: Fortunately for you, I added handling 16-bit colours (if you change constant), but I can't guarantee it will work. I only tested it in U-Boot for H3 and not in Linux. EDIT: Apparently you have to change also this line:
  12. That may or may not be true. Linux has proper V3s display driver for a long time. However, U-Boot may still hand over its FB to Linux. In that case U-Boot FB is used for a very short time and it's replaced with Linux FB during boot. Now, I'm not sure if U-Boot FB memory is actually released or just stays reserved. Best way to check would be to disable display driver in U-Boot (via U-Boot config and rebuild) and compare free memory. I don't know how to force 16-bit buffer. There is probably some kind of kernel parameter for that.
  13. If you can manage to prepare appropriate edid binary, you can supply it to kernel according these instructions: If it works, you can in some cases also write that permanently into your screen. Wrong EDID is worst kind of issue. I never actually had such problems, so I'm not sure how to edit edid.
  14. Everything seems to be in order, assuming edid is correct. Refresh rate is pretty strange - 65.681 Hz. Clocks are correctly set according to edid - 32 MHz. I have another waveshare HDMI screen (1024x600) where pixel clock is also 32 MHz and it works fine. Not sure what to suggest, except that you can try to override edid with your own.
  15. Please provide EDID blob (most probably at /sys/class/drm/card0-HDMI-A-1/edid) and content of /sys/kernel/debug/clk/clk_summary