handymenny

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

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

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

@fabiobassa Grazie @jock is there any way to run android from sdcard or read the contents of the backup made by multitool? Reflashing android isn't that fun Anyway I found this config, which has a very interesting name: https://github.com/paolosabatino/ssv6xxx/blob/83caf9feae2efc87bf5c837af8d1f9a363090b74/smac/dev.c#L1192

@fabiobassa And it doesn't lie, I'm Italian @jock Android doesn't have any issues with broadcast traffic, so it should be possible to make ssv6151p work properly

Yes, that's the consequence. I did two tests, one with WPA2-PSK and another with an open network. TEST 1 (WPA2-PSK) Packets received by other LAN devices: Packets received by ssv6051: TEST 2 (Open) Packet sent to Brodcast: Packet received by ssv6051: This leads me to conclude that the issue is decrypting broadcast packets (also because unicast ARP works). I'm not very familiar with wpa2, but I remember that they are encrypted differently Some questions: Do you know if "official" Android roms have this issue? Does the other driver, svv6x5x, work with ssv6051p?

@radiant98 I've the same problem and that's exactly what I'm debugging now. The incoming broadcast/multicast traffic is "corrupted", I've no idea why. A simple test to check if it's the same issue: ping your pc from the tvbox and then try accessing ssh, it should work (for a few minutes). With ethernet everything works perfectly.

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....

Yes, this's the most interesting part. I tried to see if there were any big differences between linux 4.4 and 5.10 (I also tried builds with 5.10) and I didn't find anything interesting in thermal management. 4.4 has rockchip_thermal inegrated (not an external module), right? I wonder if it's the cause of this strange behavior.

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

Is Apt-upgrade enough? I've already tried that. I've also tried using the latest (legacy) stable, apt upgrade and switch kernel. I tried latest nightly too If you're referring to the uboot version, maybe it's because I've the 4.4 kernel on the emmc? The only writings on the board are X96-mini and FDX 2029. Android reports the board as r30, but I don't know if it can be trusted I don't know if it's useful, but I can boot into systemd's emergency mode, but not into rescue mode. Note: by latest stable I mean the one available here: https://users.armbian.com/jock/rk322x/armbian/stable

Sorry I didn't want to start a discussion about "fake printing", it was just a note for those wondering why I was asking for help here with an "Amlogic" In any case UART log here: usb-uarth.txt I don't think it's useful though. After "Starting kernel..." I see video output, then it shuts down and starts booting again EDIT: UART log with ttyS2 as default console: usb-uart-dmesg.txt

I've the same issue. I've tried lastest nightly and stable images (both SD and emmc) but only those with legacy kernel boot successfully. I also tried changing power supply, changing kernel after initializing the legacy version (via armbian-config) and all the workarounds mentioned here: Board Pics: Yes SoC has a fake label... It's RK3228a/b