jock

@handymenny Maybe it is a makefile configuration option. Double check the kernel running on your android installation, because the driver in the rockchip 4.4 repository looks like an adaptation from something from kernel 3.x ported to 4.4 and then later ported by us to 5.x, so it could have happened something in the process has been lost.

About the android roms, I have no direct experiences but I may guess the same issue applies because the "original" driver in the legacy 4.4 rockchip kernel also behaves the same. The driver working on mainline kernel is nothing more than an adaptation from the legacy one. The other driver ssv6x5x, despite the name matching, does not work with ssv6051p. Me and @ilmich inspected both of them. We found that some parts are significantly different, and the result is ssv6x5x driver works only with ssv6256p chip (common on some "5G" boards) and ssv6051 driver works only with ssv6051p chip. Adapting ssv6x5x to work on ssv6051p apparently is not a trivial task, and is complicated by the lack of internal documentation.

AFAIR, the distro from the vendor came with kernel 5.10 and there uwe5622 was working right there. Yes, those 4 patches for the uwe5622 wifi/bluetooth bring support and fixes in the armbian rockchip64-5.15 patch directory. If you would want to go with vanilla 6.1, you should probably start with the other patches in rockchip64-5.19 directory though. About the device tree, there are three nodes (uwe-bsp, sprd-wlan and sprd-mtty) starting here: https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.19/add-board-orangepi-4-lts.patch#L361 And also notice the comment about the pwrseq that handles the power on/off of the chip with this line: https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.19/add-board-orangepi-4-lts.patch#L358 Notice also that the pwrseq reset-gpio property has to have the polarity reversed compared to the wl-reg-on property.

@handymenny For what I had the chance to observe in the past, the ssv6051 was not answering to ARP requests sent on the broadcast MAC address, so after some idle period the interface becomes unreachable until some outbound traffic is made. This problem although can be the consequence of a more deep issue, and problems with broadcast/multicast traffic can be a quite plausible cause.

Honestly, I think that kind of shutdown can even be disabled, because the kernel should already be able to do thermal throttling and shutdown the system by itself when the temperature reaches a threshold. The shutdown of the rockchip_thermal module is an emergency shutdown that is triggered on an interrupt I may guess, so it is immediately executed and does not pass through the kernel subsystems, but actually is redundant. If you have the chance to retrieve the original firmware dtb, it may be useful to get a look into to see if the polarity is set there.

Gotcha! I think we've spotted the bad one! I may guess that your board shutdown gpio has a reversed polarity, and thus the driver was immediately causing a shutdown because it was thinking your chip was overheating .@fukowaka may profit from this discovery, I will take a look into the dts and try to find a general solution to this, even because the legacy kernel is working right. Thanks!!

@handymenny totally new board to me, never saw anything like that. Ok, I got it about u-boot, then seeing 2021.04 is ok. Did you already try the suggestion to add cpu-stability to overlays= line into /boot/armbianEnv.txt ? I don't know what is the cause of the reboot, but surely that ttyS2 message is not related because it is usually one of the latest messages before prompting the usual login process and a lot happens between that message and the login prompt, it is just that it is does not produce any log data. Do you see something like a crash dump and a stack trace before reboot? Maybe adding panic=20 to the kernel command line could delay the reboot and may tell you something more about the problem. (add an extraargs=panic=20 line in /boot/armbianEnv.txt) Also you may try to rename the kernel modules directory from /lib/modules/<your-kernel-version> to anything different and see if you still have issues. I'm just suggesting a very blind approach, because I really I have no clue about, and also because sudden reboots without a stack trace always at the same point is very unusual.

@Max StergAll the hints are suggesting that you definitely have a S905L chip, not a rk322x one. This thread is not suitable for you and multitool will never boot, I think there isn't any kind of support for S905L in armbian. You'd better ask in this other forum: https://forum.armbian.com/forum/192-amlogic-cpu-boxes/ @handymennyYour Amlogic S905W is totally looking as a fake. In the photo the other printing of the other chips is in light gray over the dark gray of the plastic, but the S905W signature is much darker. You can compare with @Max Sterg post just above, where his S905L has the same light gray printing over dark gray just like the other sorrounding chips. Some front and back pictures of the board are useful, at least to understand what board you have (if it is an R29, it is already known they have problems). Also from the log I see you're using an image that is at least one year old. Maybe also try with a newer image.

@chakatunNo, it means that you can't run armbian with a mainline kernel from internal flash. If you want mainline kernel, you can still boot from sdcard or even usb stick installing jump start via multitool

@chakatunmultitool is clearly telling you the board has a NAND flash memory everywhere 🤷‍♂️

Vanilla means version 6.1 coming from git repository on kernel.org? Not sure why your compilation lacks sched_setscheduler symbol; it is indeed in the kernel, but maybe your .config misses some directives (looking at the source code, maybe you need CONFIG_SMP, even though it looks strange to me...) Couldn't just use the .config provided by armbian and see what happens?

@remlei ok this is better, but you still miss the important information: * what packages apt upgraded when you got the system broken? * what is the kernel version that broke the ethernet? I compiled a fresh image with latest kernel version at that time (5.15.74) and nothing happened on a MXQPRO_V73 board

@Max Sterg It's happening that the partition will be enlarged the first time you run the system. You should read a bit of the armbian documentation to grasp the basics, it has been written for a purpose: https://docs.armbian.com/

@remlei As expected, I download the latest 5.15.74 community image and there are no problems with ethernet at all 😑

Do you know if it is sufficient to install packaged falkon, qt and gstream packages on Ubuntu Jammy/Debian bullseye to get thing working or there is the need to compile something by hand? I ask because it would be nice to have some out-of-the-box solution to say that the path is traced and things are getting squared. Thanks!

Mmmh, that's rather strange, probably is not something related to the board itself but to the monitor, because I have exactly that board and it works fine on my full-hd monitor even on 5.19 without LE patches. However the LE patches introduce several fixes to timings and HDMI subsystem that it is very expected that compatibility is better all-around. What kind of monitor do you have?

@Max Sterg Yes the github repository is the best place to grab community images. Feel free to write questions here on the forum, even though this specific thread is specialized for rk322x support in armbian, so it is related mostly to hardware support and peripherals. edit: ah, don't expect great performance for the rk322x within graphical environment, it is a very limited device that is more suitable for server-like and command line tasks.

@Max Sterg Ok, no problems! From the previous post you let us think you were a total newbie, but yet you have some experience. However, if you want a desktop image, you have to go with an xfce image. Read carefully the first post for the instructions, also don't take the images from that directory you did the screenshot above, but follow the link to the community images built by armbian server. I suggest to use a mainline kernel (either "current" 5.15 or "edge" 5.19) with xfce if you want to experience a desktop environment. The difference is that "current" kernel is more stable, "edge" kernels are development ones and may potentially break, even though I don't usually push anything that deliberately breaks things even for edge kernels.

You should at least describe the issue before alarming people this way, and moreover you should post logs to let people understand if there is an issue with the image. I don't see logs and I don't see the filename of the image object of the problem, just a dubious procedure based upon a dubious hypothesis. And I say it is a dubious hypothesis because what you are stating can be only an issue related to the kernel (or possibly device trees), just because u-boot and related code has been frozen months ago. Everything is possible, and I will check soon, to me it looks very difficult that a newer minor release of the kernel could corrupt some ROM data about the ethernet that, even after reverting to a previous working image, you don't solve the problem. Maybe you have a broken cable or a broken router?

GPU is only doing 3D graphics. Media applications are accelerated by VPU, which is a totally different part of the chip. I think gstreamer is already quite capable of using the v4l2 interface to profit of media acceleration drivers already in mainline kernel (namely hantro and rkvdec for rk3318, both accelerating h.264, vp8, vp9 and hevc, but some codecs still have partial support on rockchip64 armbian branch). Ffmpeg needs to be built with patches and in a custom way because kernel interface for codecs has been made "stable" very recently (I guess in kernel 5.19). Also mpv has the capability to use hardware video decoding via v4l2, but still need a custom build because it uses in turn ffmpeg. There is this old thread where I provided a custom build binary of mpv, but it was for ubuntu hirsute and debian bullseye; surely it would require some adaptations and tinker if you want to run on newer distros. Accelarerating youtube in a browser is a whole different story. I don't know what is the current status (maybe @usual user has some clues?), but surely it is much more challenging than standalone video playing.

Out of the box: it means that is already installed and working and you have nothing to do except run you OpenGL/OpenGL ES application to profit.

Hardware GPU acceleration is working out of the box on mainline kernel images at least from two years via Lima driver. Nothing particular is required to set it to work, it just works out of the box.

This is not very helpful message. How much time you did wait to say it was blocked? Did you change the power adapter with something more suitable? Assuming you were trying to install armbian in the internal eMMC flash, it is very possible that the eMMC is broken. Also, what is your board? Do you have logs? Please read the instructions on first post, there is a paragraph with all the informations on how to contribute, they are very helpful to debug.

@Seth Thanks a lot for testing, it is very useful! That's not a bug, that's just a message that u-boot is trying to change the voltage for a device that is not there. It happens, for example, when you have installed it on eMMC and there is nothing in the sdcard slot: u-boot tries to change the voltage of the sdcard but since there is no sdcard it reports an error. The other error messages about audio things appeared in kernel 5.15 onwards and honestly I don't know what is wrong. All rockchip SOCs (from rk322x up to rk3399) show them, but functionality is not broken in any way.

Okay I made kernel deb packages 5.19 with libreelec patches to test an upgrade on a live system, as usual can be installed with dpkg -i Kernel 5.19.15 image kernel 5.19.15 dtb And also a ready-made debian bullseye testing image