jock

Looking at the log all those sdiohal messages does not seems right at all, you should understand why you get all those messages. The bus seems to have been probed correctly, although the frequency of 200MHz looks a bit too high to me. I would reduce it to 100MHz to exclude possible data integrity issues at first. Anyway I'm no expert with the rockchip_wlan framework, but it really looks to me there is something wrong with the communication with the chip. Maybe some wrongly configured gpio pins (check the pullup/pulldown configurations), maybe the frequency is too high, or the chip is somehow in reset state - if you use the rockchip framework don't use the sdio-pwrseq; surely the chipid should be rightly detected, otherwise the driver won't go anywhere.

Could you be so magnanimous to share how did you solve the issue?

Please read the first post It may be related to some clocks, but until you provide the working dtb I can't say more and surely can't fix anything.

So you did something noone told you to do and now are lamenting the multitool does not work? 🙄 I understand the monitor blinks, but you can access even via network; also if that dtb provides a stable signal maybe you could post it for analysis and comparison? Did you try another HDMI cable or another monitor?

@Orcus did you change the dtb of the multitool with something else?

Photos of the board would be very useful too

Hello, obviously we don't know what you're doing wrong, because if you don't post some logs or other details there is no chance to help with anything. Maybe your emmc is faulty and it will just never work... Once run, multitool will drop a file on the FAT partition called dmesg.multitool.log with the kernel dmesg log you can post here for inspection. However I would rather erase the internal emmc and try armbian from sdcard instead of burning on emmc.

Yes, I mean the armbian patched one This is one of the reasons to stay away, whenever possible, from the "proprietary" kernels: they use customizations in place of standard kernel sunsystems. Sometimes there is no other way, but that rockchip_wlan is a duplicate framework that has been superseded by kernel "power sequence" (pwrseq) framework. Anyway the two frameworks can coexist. The driver in the armbian trunk works fine without the rockchip_wlan framework and you should not try to integrate it into. No idea 🤷‍♂️

That phandle is absolutely spurious and not needed, it is possible that it has been left there. Well, you can use either wl-reg-on or sdio-pwrseq, but sdio-pwrseq is better to do because it is non-proprietary and kernel is informed about the on/off switch and can control it via rfkill. wl-reg-on is "simpler" though, because does not involve another node and subsystem and you may start with this to avoid an unnecessary bring-up complication IMHO. There is no "kernel paradigm" though: the device tree properties are actually interpreted by the driver and not by the kernel itself. The kernel will read some "common" properties like compatible, pinctrl-names, and some others. You have to use the nodes and properties you found in the 5.10 device tree because you took the driver from there and ported in your 4.19 kernel. Actually I don't remember exactly, I should check back the discussion with Igor and which one was hinted by Orange Pi people themselves. I had several headaches with 5.10 driver because there were issues with either newer kernels and firmware. I remember also that the 5.10 driver was having issues with recent wpa_supplicant revisions (ubuntu jammy was able to connect to wifi, for example). At last, the driver which is in the 5.15 rockchip64 kernel flavor is the best choice, is working quite well and I would suggest to go with that.

@NicoD Hello, no bothering at all, I'm happy to help! That pull request adds the libreelec patches to rockchip64 branch that provide several fixes and multimedia enhancements to mainline kernel so it is possible to use an "almost" mainline ffmpeg/gstreamer for h.264/hevc/vp8/vp9 hardware decoding, DRM fixes, support for 10-bit HDR videos, more DRM planes, etc... etc... There was an old thread where I provided a ready-to-go mpv executable with hardware acceleration on mainline kernel, but should be rebuilt for recent distros since it is quite old now. It could be a nice idea to try mainline kernel with wayland based desktop environment. I may build an Opi800 image with kernel 5.19 from that branch, maybe with a fully-fledged KDE, rebuild ffmpeg/mpv and give instructions for a cutting edge test if you think it is reasonable

@handymenny Cool, thanks! Maybe the broadcast decrypt can be fixed adding a proper -DUSE_MAC80211_DECRYPT_BROADCAST directive in the kernel module makefile nearby the other conditionals that relate to hardware/software encryption and decryption, without hardcoding the conditional. Anyway thanks, do what you prefer and if you open a pull request I will accept and rebuild the armbian patches to fix the problem

@handymenny hmmm, that line is very interesting! To let things work on mainline kernel, hw encryption and decryption have been disabled and everything is handled by the mac80211 layer in the kernel, which has fast enough algorithms to provided enough throughput without taxing the system too much. Maybe that block inside the ifdef is not compiled because the macro is not defined. Unfortunately the driver is filled with such ifdef conditionals which are very hard to track.

@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/