jock
-
Posts
2172 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
here it is a module for kernel 6.6.67 and rtl8189es. Put this module in /lib/modules/6.6.41-current-rockchip/kernel/drivers/net/wireless directory, then run sudo depmod -a and reboot.
If everything went ok, you should get 8189es driver loaded after boot; perhaps you may need a firmware to put somewhere in /lib/firmware. In case, the driver should complain about in dmesg that something is missing or wrong, and that may serve as hint to proceed further.
-
@Obmor I see several issues within dmesg, but nothing about the wifi chip.
First, you should remove rk322x-wlan-alt-wiring from the overlays, which seems not suitable for your board.
With the current configuration of overlays, the SDIO chip (ie: the wifi chip) on mmc1 is detected, but no drivers are loaded as long as I see; are you sure you have an ssv6051?
If you run rk322x-config, you should have a line Wifi device: .... Device ID: .... if your board really has a ssv6051, you should get 3030:3030 as device ID
-
9 hours ago, Obmor said:
I checked, this module is not loaded in Armbian does it make sense in modprobe ssv6051?
Hello! No, it has no sense to modprobe the module because the kernel should autodetect the chip and load the module automatically.
The module is not loaded automatically because the chip is turned off and the kernel could not autodetect it.
Try to put this file: rk322x-led-conf9.dtbo
in /boot/dtb/overlay directory, then append led-conf9 to overlays line in /boot/armbianEnv.txt and see from dmesg if your wifi device gets detected.Send the dmesg log anyway, it is the first step to understand what is wrong.
-
@zzc @galenzhao @Obmor tvboxes have a huge amount of wireless chip on board and supporting all of them is very difficult and time consuming taks which I can't afford anymore; the APxxxx series is usually supported because they are basically broadcom chips and the driver is there, but their functionality also depends upon the board wiring, the firmware, the nvram, etc... as you see there are several pieces in the puzzle and it is not easy to fit them without some effort.
The best advice I could give you if you need basic wireless connectivity, is to buy a mediatek-based (mt7601) USB dongle; the next best advice is to buy SBCs with standard or premium support (not CSC) by armbian
-
@Doug Brewer perhaps you could try to compile chromium from this repository: https://github.com/amazingfate/chromium-debian-build/tree/mainline-v4l2-131
-
-
@Riyadh Zaman instructions are in the first page of this thread
-
@joeculler patches applied to ffmpeg are straight from the LibreELEC project repository: https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/multimedia/ffmpeg/patches
-
-
You're welcome in supporting the armbian project if you want and if you can. 😉
-
@haven just had the chance to check with Debian Bookworm with no DE at all, bare terminal.
In my case, on my IIyama monitor, I have no issues at all with HDMI sound. It works on kernel 6.6.60 (latest 6.6 release so far), double checked on older 5.19 kernel and it works the same way.
Perhaps the issue is more software related with pulseaudio/xfce rather than related to bare hardware?
As a side note, I only have a very loud default volume, since there is no volume control and so I get 100% volume.
Turning down volume configuring alsa with "softvol" plugin (following this) fixes the loud volume and HDMI audio works fine in bare terminal for me.
-
@Ioan Bogdan Veringioiu thanks a lot for testing and finding this bug. Since that patch was more an inheritance rather than a real necessity, I will remove it or cut to the very minimal pieces needed soon.
Thanks again!
edit: Pull request opened: https://github.com/armbian/build/pull/7479
the patch will be removed soon from mainline.
-
On 11/12/2024 at 1:26 AM, remlei said:
I wish this was the case but as soon as armbian is installed on emmc, any image in the community repo from github do not boot the SD card first, for it to boot to sd card, I need to short that maskrom to ground.
It could be that it is not working anymore since I upgraded to 2024.04 u-boot and had to practically rebuild the configuration from scratch.
This is indeed not intended and has to be considered as a regression.
-
8 hours ago, Ioan Bogdan Veringioiu said:
Do you know something about the patch above ?
I vaguely remember that it was inherited from somewhere when I merged rockchip 32 bit families (there was a separate family for rk322x).
It is actually an adaptation from a kernel submitted patch from a rockchip person: https://patchwork.kernel.org/project/linux-rockchip/patch/1569553244-3165-2-git-send-email-zhangqing@rock-chips.com/, but it actually never went into the mainline kernel.
-
14 hours ago, Ioan Bogdan Veringioiu said:
[ 17.456578] rockchip_rk3066_pll_set_rate: Invalid rate : 32690000 for pll clk pll_npll
Weird that 800x480@65Hz works despite the invalid rate warning, and 800x480@66Hz does not produce any warning but does not work at all.
By the way, the only "major" difference is the negative VSync for the native 800x480 mode.
You may want to compare those modelines against the kernel 4.4 to look for differences.
Perhaps there are some "restrictions" in the modeline on armbian kernel 6.6 that force the display with a vertical refresh rate (65.7 Hz) that is not supported by the display.
Did you try also to force display vertical refresh rate to 60Hz and 66Hz via kernel command line?
-
@Minoro Hamada Supposing you removed the sdcard from the slot, the only way to tell you what is happening is providing logs from the serial interface. You may have a broken/read only eMMC. Also you did not specify what image, what kernel, what board you have...
-
15 hours ago, remlei said:
this is expected specially for eMMC models unfortunately.
No, this is not expected at all. Unless there is a problem that may freeze the board at boot (like the optee issue that is coming up recently), when armbian is installed, boot priority is given to sdcard, then eMMC.
@Mr-TNT I guess you did not follow the instructions to first erase eMMC and test armbian on sdcard and later install into eMMC.
-
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
-
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 😕
CSC Armbian for RK322x TV box boards
in Rockchip CPU Boxes
Posted
That's because usually these drivers are suited for Android and they expose by default a "regular" interface and a "P2P" interface for direct connection.
Just use wlan0, or there should be a module option to disable the p2p interface.