handymenny

Just send the one you used to fix HDMI issue. 
This?

Just send the one you used to fix HDMI issue. 
This?

Fixed multicast too: https://github.com/HandyMenny/ssv6xxx/commit/5ff256e8c84665253379e43e2608f7debef2d1b4

@jock Broadcast traffic is correctly decrypted with this hack: Force MAC80211 broadcast decrypt 
Multicast traffic is still corrupt though

@jock Done. I wonder if it's a hw/firmware issue or it's the driver itself the cause. But so many flags linked to SW decryption, makes me think that even the authors didn't trust the HW capabilities...

@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

@jock Broadcast traffic is correctly decrypted with this hack: Force MAC80211 broadcast decrypt 
Multicast traffic is still corrupt though

Fixed multicast too: https://github.com/HandyMenny/ssv6xxx/commit/5ff256e8c84665253379e43e2608f7debef2d1b4

@jock Broadcast traffic is correctly decrypted with this hack: Force MAC80211 broadcast decrypt 
Multicast traffic is still corrupt though

hi @handymenny, benvenuto nel club 😃
 
congratulations on your findings, as @jock said we managed to get wifi running on new kernels, but for me a lot of things are obscure.
As for Android from sd card, technically it's possible. Never tried, but if you have a backup I think a dd to the sd card is enough.
From an update image it's more complicated because you should explode it with the tools and flash the various pieces (boot, system, userdata) with the right offsets.

X96-mini_rk322x_Android_Linux-3.10.dts
 
I tried to include rockchip_thermal in the 5.15 kernel, it just crashes 4-5 seconds after "Starting kernel...". Then I reversed the polarity and lowered the shutdown temperature (10°) and it crashed exactly after 4-5 seconds. So definitely my board needs a reversed polarity. I guess the newer driver does some initialization, thus setting a wrong initial state.
 
You could set an invalid polarity (rockchip_thermal.c#L1295) so that this mechanism is disabled. A reboot isn't so helpful in lowering temperatures anyway....
 

Other suggestions were not helpful, but this one was very helpful (I was going to recompile the kernel randomly disabling the subsystems/drivers)
The module causing the crash is rockchip_thermal, double checked by renaming it + blacklist in modprobe.d/blacklist.conf + modprobe rockchip_thermal
 
 
EDIT:
I tried to flip some bits in dtb/dts to make that driver incapable of issuing shutdowns. I found one that allowed me to load the driver: rockchip,hw-tshut-polarity = <0x00>
After this edit and once the driver is loaded, I can read the temperature and it is correct