jernej

Members
  • Posts

    1093
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by jernej

  1. VP9 is stable already and it's covered on more SoCes than RK3399. It works on Allwinner H6, for example. HEVC is not yet stable, you still need external patches. LE has already patches for 5.18: - kernel: https://github.com/LibreELEC/LibreELEC.tv/pull/6423 - ffmpeg: https://github.com/jernejsk/FFmpeg/commits/v4l2-request-hwaccel-4.4
  2. Yes, there are several topics. Quick search found: Best to ask in one of existing topics. Oh, only H264 encoding is supported.
  3. Encoding isn't supported by mainline kernel, unless you modify kernel like some people on this forum.
  4. jernej

    Orange Pi3 lts

    Well, you have to be careful which address you use with which bus type. As long as bus and address pair match, there should be no observable difference in behaviour. I have no clue why it wouldn't work on another board. BTW, error -517 means that driver can't be loaded due to dependency issues. In this case, where axp address was wrong, this happened because many devices tried to enable or set up their regulator, but regulator couldn't be located on bus due to wrong address.
  5. jernej

    Orange Pi3 lts

    There is absolutely no difference, otherwise there is a bug somewhere. Reason why OrangePi image has I2C and Armbian RSB is that switch from I2C to RSB happened with kernel 5.13 and OrangePi uses kernel 5.10, which predates this. If OrangePi releases image with newer kernel, it will most likely use RSB too. The only important differences could be in regulator settings (subnodes to axp), those are important settings to copy.
  6. jernej

    Orange Pi3 lts

    I have zero idea what is that about... As I said, it looks like some image building issue, but don't hold me on that. BTW, can you try to boot ordinary OPi3 image and see if there is same issue? it should mostly work.
  7. jernej

    Orange Pi3 lts

    Note that actual address is in reg property, it's just convention that address is in node name too. So make sure you fixed address in both places.
  8. jernej

    Orange Pi3 lts

    No, output method is always the same as input. Anyway, RX on Arduino still operates at 5 V internally, so it might not reliably decode 3.3 V signal (it can be even slightly lower than that). Why don't you just fix regulator address first and see if this is it? As I mentioned, boot reliability issues can come from incorrectly set voltage regulator.
  9. jernej

    Orange Pi3 lts

    No, U-Boot (currently) doesn't set any voltage regulators for H6 boards. However, ATF does, but it works with both busses (at least new versions). But even this is not really necessary. Most important regulators already run at power on. You can boot to Linux with them.
  10. jernej

    Orange Pi3 lts

    It's a long time ago since I worked with Arduino, but they usually run at 5 V. This is too much for H6 serial port, which expects 3.3 V signals. I may be wrong about Arduino, though. I highly recommend measuring idle state voltage level on TX pin. If it is above 3.3 V, then don't use it.
  11. jernej

    Orange Pi3 lts

    Both works, but RSB is faster. I suggest to use RSB, just to be in line with OPi 3 DT.
  12. jernej

    Orange Pi3 lts

    Yes, you can, but be careful to work at 3.3 V, otherwise you'll damage H6 chip.
  13. jernej

    Orange Pi3 lts

    @Ukhellfire if that is the DT file you're using, then yes, regulator address is wrong. You see, it can work via I2C bus, where it has address 0x36 or via RSB bus, where it has address 0x745. In DT file you mentioned, it's connected to RSB bus, so address is wrong. Change @36 to @745 and reg = <0x36>; to reg = <0x745>; and all regulator related issues should go away.
  14. jernej

    Orange Pi3 lts

    How do you access initramfs console? Via connected HDMI monitor? If so, then take a photo of each dmesg page Anyway, serial is basic requirement for debugging boot issues. Anyway, if it's possible to boot sometimes, but not otherwise, it's possible that there is timing issue, insufficient voltage of some regulator or too high frequency. Unfortunately, all of these things are hard to debug, especially remote.
  15. jernej

    Orange Pi3 lts

    @Ukhellfireboot looks good, except when loading modules. I haven't seen anything like that. Did you by any chance build kernel and modules separately, possibly with different compiler/settings? This is more or less the only reason for such issues.
  16. jernej

    Orange Pi3 lts

    If you have an option to build custom kernel, you can mark usb keyboard driver as =y and it will be included in kernel directly, so it should work from initramfs shell too.
  17. jernej

    Orange Pi3 lts

    Initiramfs shell should support dmesg command. If not, remove "quiet" from kernel arguments and you'll get basically the same output on serial.
  18. jernej

    Orange Pi3 lts

    There is no reason why standard method wouldn't work on OPi 3 LTS. It's possible that something in DT file isn't set correctly, although quick comparison doesn't show anything useful. Show me output of dmesg, maybe there is something useful there.
  19. If you have image with mainline U-Boot, you can first burn it to SD card, boot it and then butn same image to emmc directly. Only precondition is that emmc is enable in both, U-Boot and Linux.
  20. I don't remember which version was first. I guess 5.15? There is also one patch, which was merged already, so you need to dig it up from rtw88 history. As I said, I don't have them. I deleted them at one point. Anyway, it's simple, adding new variant to BT RTL driver and making sure module is reset before use (patch for this is on BT mailing list).
  21. I have TX6 box with 8822BS wifi+bt too. I have patches for this wifi, meant to be upstreamed. Speed is probably not on par with out of tree driver and has locking issue (I never experienced it, but it was discovered during testing it on another wifi), but it generally works ok. Take a look here: https://github.com/jernejsk/linux-1/commits/rtw88-test2 (ignore first two patches). BT needs some more patches and FW extracted from Android image (I asked Realtek, but they are not interested in officially supporting BT on 8822BS version). I don't have those patches available anywhere currently.
  22. If there is no status line, it's considered active. You have to set status to "okey" only when parent node sets it to "disabled". For example, sun50i-h6.dtsi has spdif node set to disabled. In sun50i-h6-tanix-tx6.dts we override status to "okay".
  23. SPDIF is already included in base H6 DTSI file (any board can easily enable it, if present) and it will be enabled for Tanix TX6 by default in 5.17
  24. No, not really, only general instability (app crashes, kernel lockups, etc.). Note that Android has completely different display stack, so you can't compare it to X11. If you really want to prove it's driver issue, you would need to create BSP based image and test it there. But I never done that for 64-bit Allwinner SoCs, so I have no idea how hard it would be. Strange, your DT blob has this: awleds { device_type = "awleds"; compatible = "allwinner,fd6513_dev"; status = "okay"; leds_clk = <0x87 0x07 0x05 0x01 0xffffffff 0xffffffff 0x00>; leds_dat = <0x87 0x07 0x06 0x01 0xffffffff 0xffffffff 0x00>; phandle = <0x1bd>; }; which clearly indicates it should have FD6513 LED driver and thus display. Maybe it's one image for several box variants.