jernej

  • Posts

    1017
  • Joined

  • Last visited

5 Followers

Recent Profile Visitors

6701 profile views

jernej's Achievements

  1. Here is early work for proper XR819 mainline support. Tests reports are welcome, to see if it is actually any better than vendor driver. I got reasonable speed using it and only problem I can see is that suspend doesn't work. Of course, developer tests rarely last more than a few minutes, so long term stability isn't known. Note, I extracted pretty recent FW binaries from H616 Android box, which should be better than old ones, in theory.
  2. disp_mode trick doesn't work with mainline kernels. There are two ways that I know, both via kernel boot arguments: 1. Specify preferred video mode: "video=HDMI-A-1:800x480" 2. override EDID data, like described here. Note that I tested only second approach on different distro. First one should work, but maybe syntax is not completely correct (google is your friend here). Another note, if resolution you want to set is not reported by your monitor, only second approach will work.
  3. well. I don't have this particular board to test resulting image.
  4. I found the culprit. Patch https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.13/board-h6-orangepi-lite2-fix-missing-all.patch messes up HDMI node, which then doesn't properly enable DDC lines and then in turn, HDMI driver can't read EDID. @Igor any reason for above patch to be so big? OPi Lite2 is pretty well supported in 5.13. Only nodes which are not present in mainline are spi0, usb3phy and dwc3. Patch can be much smaller...
  5. Yes, I do In short, if you only have 1024x768 resolution, that means that board was unable to read EDID data from monitor (it holds info which resolutions are supported by monitor and a few other things). It's a bit weird that this doesn't work. I would try with different HDMI cable and if your cable is long, I would try with a short one. It's also possible that DDC lines are fried due to ESD. Of course it could also be a driver bug, but I have never observed such issue on my boards.
  6. Check U-Boot output on serial. It should say something like 4 GiB of RAM detected, 3 GiB used. That won't change, since it's impossible to use that extra GiB due to HW limitations.
  7. According to https://linux-sunxi.org/Tanix_TX6 there are two versions of the box, 2 GiB and 4 GiB of RAM. RAM size detection code on H6 should be pretty solid these days, but if you really think you have 4 GiB version, open the box and provide clear images of both board sides. That way we could count RAM chips and check markings on them to manually calculate RAM size and if it's incorrect, to get at least some idea what could be wrong. P.S: Boards really do have 4 GiB of RAM, it's just that H6 can use only 3 GiB.
  8. jernej

    Mainline VPU

    Yeah, LE currently uses 5.10 kernel because we are preparing stable release (no ETA, but hopefully soon). Only after that Linux will be updated to whatever current stable release will be at the time. However, v4l2 request api ffmpeg patches for Linux 5.13 can be found here. Note that they are untested and you still need corresponding kernel patches too.
  9. I have troubles booting Tritium H5 myself, but from SD card. I just power cycle it until it works. Sometimes it seems that it helps if HDMI is unplugged, but that might be just red herring. However, once it's booted, all reboots, suspend/resume cycles via Crust work. I have no idea why it's behaving that way.
  10. That's not correct - distinction between bytes (B) and bits (b) is just upper and lower case. Prefix "Gi" means gibi and it means factor of 1024 * 1024 and second one is giga which means factor 1000 * 1000.
  11. H616 ATF stuff should be upstreamed already, but I'm not sure if it is in any stable version.
  12. If I'm not mistaken, yes. You can always make a SPL hack, which do stuff with otherwise protected resources.
  13. 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 out of tree patches). Anyway, regarding passthrough - I can give you only a hint from source, since I don't have any intention of running BSP RK kernel: https://github.com/rockchip-linux/kernel/blob/develop-4.4/sound/soc/codecs/hdmi-codec.c#L126 You can set this with amixer - 0 means PCM, 1 means NLPCM and 2 means HBR NLPCM. I have no idea how to properly use it.
  14. @tony013 Fix for RK3399 HDMI audio on mainline has been just merged in LE: https://github.com/LibreELEC/LibreELEC.tv/pull/5365
  15. I was speaking about SoC capabilities with first part, not about Armbian setup. Second part is speaking about my experiments about passthrough on mainline.