jock
-
Posts
2121 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
It could even be that I should re-align the libreelec patches in armbian... for some time those were not actively developed in the libreelec project, and thus I did some bare fixes to keep them compatible with newer kernels, but they could have been broken somewhere in the middle.
I will try to give a shot in the weekend, but I'm sorry I can't promise actual results
-
I may guess that the HDMI timings in the kernel driver for HDMI are not suitable for uncommon resolutions like 800x480 is. I borrowed the actual timing from LibreELEC project which, in turn, were elaborated from other informed persons, and those timing greatly improved compatibility among regular monitors and TVs around, but indeed they could have broken uncommon resolutions.
This is the patch which, among other things, modifies the existing HDMI timings. I could try to compile and image without that patch to see if works for you, but remember that you won't be able to upgrade the kernel, otherwise it would break again
-
@robertoj I may guess there are some missing pieces in the armbian kernel for allwinner: for rockchip, there are some patches borrowed from libreelec to make it work correctly with all formats. I don't know what is the status for allwinner and if there are similar patches and fixes that are not include right now, you won't be able to get anything.
ffmpeg with v4l2request patches applied should work with any device which has a working v4l2request compliant drivers in the kernel, plus it also requires a properly working presentation framework for the DRM/DRMPrime and EGL parts, so there are several players involved: ffmpeg has to talk via v4l2-request to the kernel, the hardware decoding happens in the V4L2 drivers, but the presentation on screen happens within the kernel (DRM) and/or Mesa (EGL/OpenGL), bridged by DRMPRIME buffer sharing.
I guess Mesa is pretty ok, since both Lima and Panfrost have the necessary bits in place to present things on screen, yet the Cedrus hardware decoder driver has to properly support hardware decoding and buffer sharing via drmprime with the GPU driver. I made some simplifications here and omitted details, but as you see it is already a fairly complex communication setup, of which ffmpeg is just the "user" of all those other services.
-
@Ioan Bogdan Veringioiu hello, did you try any older image wth mainline kernel that was working for you, or just tried debian buster with kernel 6.6 and it just does not work?
HDMI compatibility is very hard to achieve, and fixing you problem may became very difficult.
-
-
I just had the chance to test an old Allwinner H3 (OrangePi One) with kernel 6.6.44 and can confirm that mpv fails to work correctly with hardware decoding, both via terminal and also in weston, both on kernel 6.6.44 and 6.10.8.
On rockchip64 instead it works pretty well in both terminal and weston on kernel 6.6.57.
I guess something broke in the kernel for allwinner platforms 😕
-
@Truong Thinh Chau hmmm, preferred mode is 10 which has no modeline but just hsync and vsync indications. i'm no expert in such material, but it doesn't look right to me and your monitor may be not exactly right telling the modeline to the kernel.
You may try to append extraargs=video=HDMI-A-1:1920x1080@60 in /boot/armbianEnv.txt to see if the console shows up. If it works, notice that this only forces the console framebuffer to handle such resolution and if you start a desktop environment it will go black again because you have to force the resolution the way the desktop environment wants (for example, xfce requires you to edit an XML configuration file if I recall correctly).
Some reference for the kernel command line flag: https://docs.kernel.org/fb/modedb.html
Examples: https://forum.armbian.com/topic/3749-how-to-change-resolution-hdmi-display-armbian527/?do=findComment&comment=66311 (here there is also an attempt to load a custom EDID, which I don't remember if it is enabled or not in the rockchip64 kernel)
-
@Truong Thinh Chau Your board has 2GB of RAM because the tv box has fake specs. My tv box also claims 4gb of RAM, but has 2.
About the HDMI issue, in 6.6 kernel there were some important patches to improve HDMI compatibility, but general HDMI raccomendations apply, so try another cable or try another monitor/TV.
There could be something related to the the device tree (a GPIO, mostly), but I had no time to check in detail, sorry.
What you can also do is try to use get-edid/parse-edid (google for tutorials) to try and read the EDID from the connected monitor to see if it gets detected
-
@Truong Thinh Chau I see that you are using an armbian image from a third-party source (ophub), I'm sorry but you have to ask them about issues; I'm not aware of their customizations and modifications. If you want help from this forum, please use an image from an official source.
-
@Truong Thinh Chau perfect, thanks fot the device tree, I had the chance to give a quick look into and I can't see anything very different about your board, so it should work out of the box. As long as dmesg looks ok to me, it could be an issue with HDMI. Did you try to access the box via SSH? Here are the instructions: https://forum.armbian.com/topic/34923-csc-armbian-for-rk322x-tv-box-boards/page/45/#comment-135407
In case HDMI is not accessible or is not working, the multitool can be operated via regular SSH access, just give a dozen seconds or more to boot. The board led should be blinking when ready and the device should be pingable.
-
@Truong Thinh Chau hello, happy to lend a hand, but you should be more specific on what is your problem... dmesg looks ok to me; your board is a new entry too, and it looks to me it has an unknown (to me) PMIC that could be a source of issues.
I will try to have a look into the dtb from your firmware (thanks for that), but lately I've been quite busy and can't promise anything
-
@Vladimir Trondin I see no issues about eMMC in that dmesg
-
@haven could not check right now, but nothing should have changed from the audio side. Perhaps the order of the devices changed and what was once the default, now it is not anymore?
Recently I enjoyed some Quake running on an rk3318 box and analog audio was the default.
Those errors also are not relevant, the audio devices will still work with no issues.
-
Hello @Vladimir Trondin, as @fabiobassa already pointed out, there is no driver for ssv6158. Doing some research, it seems that it may use the ssv6x5x driver, but it would require adaptation, plenty of time, plenty of patience and you would not be sure if it will finally work.
About the eMMC of your board, it would be handy to get the output of dmesg command, but in the meantime you could do some experimentation with the emmc parameters in rk322x-config withing this page:
In particular, try to enable emmc-pins and emmc-ddr-ph45 or emmc-ddr-ph180 or emmc-hs200 (these last three are alternative, only one should be enabled) and see if your emmc gets detected after a reboot.
Also your board r3229q is not listed within the led-conf options, but I see some similarities with r329q board (led-conf2) MXQPRO_V72 (led-conf6), so you may start trying with those ones, or stick with generic since your wifi is already detected despite being useless.
-
17 hours ago, robertoj said:
P.S. I see that the debian repo (through my web browser) does not provide mpv.deb, but Ubuntu Jammy does... does this mean that the armbian-bookworm mpv.deb does not need the patches?
Exacty, mpv in debian bookworm already has full support for drm-prime, so there is no need for a patched version of that
17 hours ago, robertoj said:I also see that the available debs are 11 months old... perhaps if you could point to some instructions that work, we could do it ourselves and share the outcome.
the instructions that work are there, in the meantime it can be that mpv changed some default, actually I didn't check recently
-
There is a post on the rk3318 tvboxes forum with a kernel dump and something that did not went good with work queues: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=203586
I did take a little look into the code, but could not spot anything wrong.
By the way @Jean-Francois Lessard wasn't it simpler to use .led_set_brightness_blocking in place of .led_set_brightness and let the led core do the job with the work queues?
-
@Parth the soc is slow, it is one of the slowest socs around with a modest amount of memory on board , so don't expect stellar performance.
The image with debian bookworm is a minimal image: small and good for servers.
For all the other questions, you can consult the official armbian documentation https://docs.armbian.com/ and related forums
-
-
-
17 minutes ago, Parth said:
@jock so i will first put the emmc in reset mode with shorting the pins, erase the emmc and then just simply connect the sd card with the image which you asked to download (its downloading) and simply test it, in terms of i shall get something on the UART right?
you should get the regular log on the uart and then kernel and systemd messages. You shoul also get proper HDMI output (except for R29/R2B/H10 boards, which require to be first configured with rk322x-config).
edit: ah, uboot is fully functional both via uart and via usb keyboard
-
6 minutes ago, Parth said:
@jock just to be sure, i should first flash the bootloader V1.10 given on first page of this forum then load the image which you provided in the sd card and try right?
You can burn it on an sdcard and test directly from sdcard if you blank your emmc with rkdeveloptool or a similar tool.
When emmc is empty (as well as when it is "masked", hence maskrom), the board will boot from sdcard and it is the suggested way to verify the board boots with armbian or has issues.
-
-
@Parth Yatin Temkar hello; I'm a bit confused about your journey.
First of all, as @RaptorSDS said, the specs of the rk3228a board are fake because the chip cannot support more than 2gb of DRAM. You have 1gb of DRAM and the proof is the ddrbin that is reporting the DRAM size.
A backup of the original firmware would have been really useful, I suspect you have some issue with the trust os. This:
makes me think there is some artificial in the proprietary trust os that is freezing the board.
You have to try with a bootloader with opensource optee but at the moment I don't have it at hand, but can give a chance to build an image with the older opensource trust os and see if it works for you.
As long as you have the serial working, could you please post the output of the multitool boot?
-
@SuperMaximus I just double checked on a pristine armbian installation on my tinkerboard and enabling pwm1, pwm2 and pwm3 does not incur in any inconvenience.
All the 4 pwms are available in my case:
root@tinkerboard:/sys/class/pwm# ls -lah total 0 drwxr-xr-x 2 root root 0 Oct 14 12:26 . drwxr-xr-x 66 root root 0 Oct 14 12:26 .. lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip0 -> ../../devices/platform/ff680000.pwm/pwm/pwmchip0 lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip1 -> ../../devices/platform/ff680010.pwm/pwm/pwmchip1 lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip2 -> ../../devices/platform/ff680020.pwm/pwm/pwmchip2 lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip3 -> ../../devices/platform/ff680030.pwm/pwm/pwmchip3
5 inch hdmi display not working
in Tinkerboard
Posted
Here: https://users.armbian.com/jock/rk3288/
I repackaged the libreelec patches, there was a very small change in a device tree and I don't know if it could be of any importance.
You can try rockchip-6.6 and/or rockchip-6.11 debs for your setup.
You need to install linux-dtb and linux-image packages for sure, linux-headers is only needed if you have kernel modules built by yourself.
Also you may also want to try to force the HDMI resolution adding extraargs=video=HDMI-A-1:800x480@60D to /boot/armbianEnv.txt and see if you get a framebuffer