jock

Just a note: there is no modified mpv. Ubuntu Jammy just requires an updated version which my repository provides. Debian bookworm works fine with the packaged version it comes with.

As said, you can either remove the eMMC or short the clock pin to ground. Otherwise learn how the rockchip vendor boot happens and use the multitool binaries to hack the armbian boot

@ToShuk it depends upon a tree of factors. mmc is totally invisible to the SoC The the SoC will automatically look for the sdcard - just plug armbian in the sdcard and it will work the above won't work if the sdcard slot is attached to the sdmmc_ext controller of the SoC; this depends on how the manufactured designed the board and, if this is your case, your only solution is to replace the onboard eMMC mmc is stuck in read-only mode the SoC will indeed execute the bootloader, if any was present in the eMMC when it went read-only If the existing bootloader is the stock one, then you're stuck with the possibilities of the stock bootloader (eg: see the rockchip boot process wiki page): multitool will boot, but not plain armbian images; tinkering with armbian images bootloader will let them boot though. You can either short permanently the eMMC clock pin to ground, so the eMMC is clock gated and actually excluded from the system, or phisically remove the eMMC chip, so you can reconduct to the "totally invisible" case above if the existing bootloader is the one provided with armbian, the you're lucky and it should be possibile to boot from sdcard and USB

@Francisco Hasuky it is a known problem: some boards are sent to "suspension" after one minute by the proprietary Trust OS; you need to build u-boot with an opensource Trust to overcome the problem. At the moment I'm unable to build an image or provide the binary, but will do in the forthcoming hours/days @Jota Ce if you got ssv6051p chip, then you should be ok using any recent armbian image with kernel 6.12 (you could upgrade to edge kernel via armbian-config, or use the beta.armbian.com APT repository). Also kernel 6.6 should work with ssv6051p because the (horrible) driver has been ported from 4.4 kernel.

@Riyadh Zaman from the first page:

@Fcn3 this what you can expect from such hardware. There is a chromium fork around with patches to allow v4l2request accelerated video decoding, but has never been tested on rk3318 and probably you have to built it yourself.

Hello @Francisco Hasuky, does the HDMI turns off but the board is still responsive or the board just drops dead?

Hello, exactly the same instruction, yes

@Budi Pekerti boot via sdcard with multitool, mount the block device where you installed armbian and then remove the overlays=... line from /boot/armbianEnv.txt If you don't know how to do this, you have to reinstall from scratch

Do you mean the led-conf9 device tree overlay? Does the wifi works even without this overlay applied?

Yes, it is correct. But I will enable the rtl8189es module in the armbian mainline so forthcoming kernels will have the module compiled in. Just not update the kernel in the meantime.

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.

@Obmor 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. 8189es.ko.gz

@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

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

@hmmm the board boots properly if the leds are blinking, but you need to run rk322x-config via SSH and select the proper led-config for R29 boards: these boards are known to turn off HDMI unless a specific GPIO is switched on.

@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

@haven did you just try a different TV/monitor to see if the missing audio persists? In my case I tested and checked I have HDMI audio working even with u-boot video output enabled.

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.

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.