Jump to content

jock

Members
  • Posts

    2109
  • Joined

  • Last visited

Posts posted by jock

  1. 37 minutes ago, GmP said:

    I will try to upgrade to tm16xx driver and be back.

    :thumbup:

     

    38 minutes ago, GmP said:

    As for the HDMI, do you mean that Multitool shoud work anyway?

    Yes, or at least there should be less chances to hit some corner case that reduces the compatibility. LibreELEC is using the mainline kernel only for years though, so it is really strange you have issues with both armbian and multitool. I may wonder there is something odd in the device tree, but it would be odd that a misconfiguration in the device tree causes a kernel fault in the DRM code and in particular in the wait for vblank function 🙄  

  2. 42 minutes ago, GmP said:

    Still not clear why HDMI not working, However VFD display based n FD650 is working. Attached the vfd.conf file for openvfd: clock , USB, ETH,WIFI and COLON working. 

    Very weird HDMI is not functional in both armbian and multitool: they use very different kernels. Multitool uses the 4.19 vendor kernel, which should be supposed to provide "best" compatibility.

    The dmesg error is highly related to the missing HDMI, but in a way I can't recognize.

     

    About the VFD driver, I guess you're using OpenVFD driver. Latest kernels (both 6.12 and >= 6.16) come with tm16xx driver which is by far much much better and candidate to be upstreamed in the mainline kernel. Here is the github project reference; the driver is already compiled in the kernel, but you may need to edit a device tree overlay by yourself to let it work with your board. 

     

    To try some debugging, the complete dmesg output and the original device tree of the stock android firmware would be very useful.

  3. One suggestion I can give you is to try a fresh image from https://github.com/armbian/community/releases. Make a backup of the eMMC and clean it up (multitool can do both things), then try to boot from sdcard with the new image.

    Newer images come with u-boot v2025.10-rc5 and a "fix" to reset the VOP before entering the kernel. Some people on the other thread reported that disabling u-boot HDMI made the HDMI work once in Linux. With kernel 6.17 this issue hit my box and I could arrange a fix, perhaps this fix will address your problem too (for reference: https://github.com/armbian/build/pull/8674/files#diff-70c2c867b6e2024080868c0d5c3230d58be2d2c4b88a24291b0469c7d2229629)

  4. I compiled mpv 0.40.0 on Debian Trixie with the patches for v4l2request, but the outcome is messy at best. There is a new hwdec v4l2request, but also two new gpu-hwdec-interop v4l2request and v4l2request-overlay. It works with acceleration when launched from a terminal, but in wayland/weston v4l2request refuses to work. I don't know what happened, but it looks like a big regression from 0.39. Better use the old mpv version IMHO.

  5. @samircobra Did you try multitool? You can find it in the first post; also read carefully the first post, it contains very useful informations, for example the hint about the failing eMMC on these rk3318 boards. Probably your box has a failing eMMC. Also another important thing: we don't talk about "firmwares" here, we talk about Armbian, so if you have questions not related to Armbian, this is the wrong place.

  6. @JaydenWithaWhy ok ,the source is right. The multitool should leave a dmesg log in the MULTITOOL partition of the sdcard; that log could be handy to understand what's wrong. Also you can access via SSH and run the multitool from there, so you may get some clearer output and some more details about the error. A last note, I never tested it with a 128gb sdcard; it should work but bugs are around the corner...

  7. 22 hours ago, MX10.AC2N said:

    I've tried a reboot by disabling the overlay line in armbianEnv.txt and I've got one of my 2 LEDs back. It seems that ledconf-3 is no longer working for me. 

    Hello!

     

    You should really look to the board name in rk3318-config rather than relying to led-conf numbering; also your dmesg is showing a very bad error which is probably due to an unstable system rather than a bug

  8. 15 hours ago, sam6o9 said:

    @hexdump hey mate , do you know if new armbian image still uses an offset of 8192 sector ? i'm trying the workaround you proveded in first page for linux hanging excatly after 60 seconds , but it only worked with multitool.img . with new armbian images it doesn't even boot after applying the trick 🙁

    rk322x armbian images never used the offset of 8192 sectors, only the multitool has such offset to increase compatibility with stock images

  9. On 8/28/2025 at 8:32 AM, Afsa Jahanara said:

    R-TV Box S10 – I realize this is an older topic, but I’m trying to fix an S10 box for an old colleague.. After an update, it no longer boots, stuck on the startup animation, and won’t load Android. I can’t seem to find any firmware download. Thanks in advance.

    You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

  10. This remembers me a recent set of changes to the DWC3 driver for RK3399 to fix exactly these kind of issues exposed here, including the single-orientation problem, plus some more issues with the displayport over usb type-c functionality.

     

    The PR had a lot of comments but finally it got merged because both the author and me tested the whole apparatus and it proved to improve significantly the situation on rk3399: https://github.com/armbian/build/pull/8271


    Patches should address some issues in the dwc3 driver in general, and I see from the device tree that rk356x uses the snps,dwc3 compatibility string, so probably also rk356x benefits from them as well. It would although require some device tree tinkering: I tested on Orange PI4 LTS board and the device tree fixes are within this hunk; rk356x-based devices can probably share several declarations but that depends upon the rk356x capabilities. I would start from changing dr_mode to otg and removing regulator-always-on; property from the vbus supply.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines