fabiobassa Posted October 28, 2022 Posted October 28, 2022 For EVERYBODY on this 3ad: Me and jock and orhers authors know PERFECTLY that could be tedious ready ALL BUT ALL pages but the problem of fake printing on chips including CPU have been discussed severals but severals times. And many times has bene suggested to have AT LEAST a USB/TTL converter to interact with uart. @Max Sterg Let me understand : Is multitool booting ??? 0 Quote
handymenny Posted October 29, 2022 Posted October 29, 2022 (edited) 16 hours ago, fabiobassa said: Me and jock and orhers authors know PERFECTLY that could be tedious ready ALL BUT ALL pages but the problem of fake printing on chips including CPU have been discussed severals but severals times. 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 Edited October 29, 2022 by handymenny Add usb-uart-dmesg log 0 Quote
jock Posted October 29, 2022 Author Posted October 29, 2022 @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. 0 Quote
handymenny Posted October 29, 2022 Posted October 29, 2022 (edited) 1 hour ago, jock said: Also from the log I see you're using an image that is at least one year old 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 Edited October 29, 2022 by handymenny 0 Quote
Max Sterg Posted October 29, 2022 Posted October 29, 2022 @jock ok thank you my friend, I think there isn't any other forum with the S905L but i will double check, Is there any alike board like S905L? i mean is there any SAME board as S905L? at least i will try different versions !!!! 😜 0 Quote
jock Posted October 29, 2022 Author Posted October 29, 2022 @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. 0 Quote
handymenny Posted October 30, 2022 Posted October 30, 2022 (edited) 14 hours ago, jock said: Also you may try to rename the kernel modules directory from /lib/modules/<your-kernel-version> 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 Edited October 30, 2022 by handymenny 1 Quote
jock Posted October 30, 2022 Author Posted October 30, 2022 5 hours ago, handymenny said: 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 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!! 1 Quote
handymenny Posted October 30, 2022 Posted October 30, 2022 (edited) 36 minutes ago, jock said: even because the legacy kernel is working right. 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. Edited October 30, 2022 by handymenny 0 Quote
jock Posted October 30, 2022 Author Posted October 30, 2022 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. 0 Quote
handymenny Posted October 30, 2022 Posted October 30, 2022 (edited) 4 hours ago, jock said: 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. 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.... Edited October 30, 2022 by handymenny 1 Quote
radiant98 Posted October 31, 2022 Posted October 31, 2022 Hello. Good day! When I connect my box via wifi (chipset is ssv6051), I can't seem to communicate to it via SSH, or access admin web interface when I setup pihole. The internet and network works well on the box through wifi, except for this. On windows, I get "Destination host unreachable" error when I ping the box that is connected to wifi; however, when I try to ping my pc on the box (vice-versa), it works perfectly well. Is there any configuration that I need to modify, or this function only works through LAN? Any help is really appreciated. Many many thanks! 0 Quote
handymenny Posted October 31, 2022 Posted October 31, 2022 (edited) @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. Edited October 31, 2022 by handymenny 0 Quote
jock Posted October 31, 2022 Author Posted October 31, 2022 @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. 0 Quote
handymenny Posted November 1, 2022 Posted November 1, 2022 (edited) 13 hours ago, jock said: 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 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: Spoiler Frame 172416: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface \Device\NPF_{XXX}, id 0 Section number: 1 Interface id: 0 (\Device\NPF_{XXX}) Interface name: \Device\NPF_{XXX} Interface description: Wi-Fi Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2022 21:30:23.706271000 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667248223.706271000 seconds [Time delta from previous captured frame: 0.571755000 seconds] [Time delta from previous displayed frame: 0.571755000 seconds] [Time since reference or first frame: 7696.139623000 seconds] Frame Number: 172416 Frame Length: 42 bytes (336 bits) Capture Length: 42 bytes (336 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: AA_xx:xx:xx (AA:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: AA_xx:xx:xx (AA:xx:xx:xx) Address: AA_xx:xx:xx (AA:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: AA_xx:xx:xx (AA:xx:xx:xx) Sender IP address: 192.168.9.233 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.9.244 Frame 172417: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface \Device\NPF_{XXX}, id 0 Section number: 1 Interface id: 0 (\Device\NPF_{XXX}) Interface name: \Device\NPF_{XXX} Interface description: Wi-Fi Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2022 21:30:24.197854000 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667248224.197854000 seconds [Time delta from previous captured frame: 0.491583000 seconds] [Time delta from previous displayed frame: 0.491583000 seconds] [Time since reference or first frame: 7696.631206000 seconds] Frame Number: 172417 Frame Length: 42 bytes (336 bits) Capture Length: 42 bytes (336 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: AA_xx:xx:xx (AA:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: AA_xx:xx:xx (AA:xx:xx:xx) Address: AA_xx:xx:xx (AA:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: AA_xx:xx:xx (AA:xx:xx:xx) Sender IP address: 192.168.9.233 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.9.244 Frame 172418: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface \Device\NPF_{XXX}, id 0 Section number: 1 Interface id: 0 (\Device\NPF_{XXX}) Interface name: \Device\NPF_{XXX} Interface description: Wi-Fi Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2022 21:30:24.689007000 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667248224.689007000 seconds [Time delta from previous captured frame: 0.491153000 seconds] [Time delta from previous displayed frame: 0.491153000 seconds] [Time since reference or first frame: 7697.122359000 seconds] Frame Number: 172418 Frame Length: 42 bytes (336 bits) Capture Length: 42 bytes (336 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: AA_xx:xx:xx (AA:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: AA_xx:xx:xx (AA:xx:xx:xx) Address: AA_xx:xx:xx (AA:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: AA_xx:xx:xx (AA:xx:xx:xx) Sender IP address: 192.168.9.233 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.9.244 Packets received by ssv6051: Spoiler Frame 64: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface wlan0, id 0 Section number: 1 Interface id: 0 (wlan0) Interface name: wlan0 Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2022 21:30:23.863956722 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667248223.863956722 seconds [Time delta from previous captured frame: 0.573442855 seconds] [Time delta from previous displayed frame: 0.573442855 seconds] [Time since reference or first frame: 45.014632027 seconds] Frame Number: 64 Frame Length: 66 bytes (528 bits) Capture Length: 66 bytes (528 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:llc:data] [Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] IEEE 802.3 Ethernet Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: AA_xx:xx:xx (AA:xx:xx:xx) Address: AA_xx:xx:xx (AA:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Length: 52 Logical-Link Control DSAP: Unknown (0x7d) 0111 110. = SAP: Unknown .... ...1 = IG Bit: Group SSAP: NULL LSAP (0x01) 0000 000. = SAP: NULL LSAP .... ...1 = CR Bit: Response Control field: I, N(R)=80, N(S)=0 (0xA000) 1010 000. .... .... = N(R): 80 .... .... 0000 000. = N(S): 0 .... .... .... ...0 = Frame type: Information frame (0x0) Data (48 bytes) Frame 65: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface wlan0, id 0 Section number: 1 Interface id: 0 (wlan0) Interface name: wlan0 Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2022 21:30:24.355487586 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667248224.355487586 seconds [Time delta from previous captured frame: 0.491530864 seconds] [Time delta from previous displayed frame: 0.491530864 seconds] [Time since reference or first frame: 45.506162891 seconds] Frame Number: 65 Frame Length: 66 bytes (528 bits) Capture Length: 66 bytes (528 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:llc:x25:data] [Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] IEEE 802.3 Ethernet Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: AA_xx:xx:xx (AA:xx:xx:xx) Address: AA_xx:xx:xx (AA:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Length: 52 Logical-Link Control DSAP: ISO 8208 (X.25 over 802.2) (0x7e) 0111 111. = SAP: ISO 8208 (X.25 over 802.2) .... ...0 = IG Bit: Individual SSAP: NULL LSAP (0x01) 0000 000. = SAP: NULL LSAP .... ...1 = CR Bit: Response Control field: I, N(R)=80, N(S)=0 (0xA000) 1010 000. .... .... = N(R): 80 .... .... 0000 000. = N(S): 0 .... .... .... ...0 = Frame type: Information frame (0x0) X.25 Data (45 bytes) <Frame 66: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface wlan0, id 0 Section number: 1 Interface id: 0 (wlan0) Interface name: wlan0 Encapsulation type: Ethernet (1) Arrival Time: Oct 31, 2022 21:30:24.847014658 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667248224.847014658 seconds [Time delta from previous captured frame: 0.491527072 seconds] [Time delta from previous displayed frame: 0.491527072 seconds] [Time since reference or first frame: 45.997689963 seconds] Frame Number: 66 Frame Length: 66 bytes (528 bits) Capture Length: 66 bytes (528 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:llc:data] [Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] IEEE 802.3 Ethernet Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: AA_xx:xx:xx (AA:xx:xx:xx) Address: AA_xx:xx:xx (AA:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Length: 52 Logical-Link Control DSAP: ISO 802.2 (0x7f) 0111 111. = SAP: ISO 8208 (X.25 over 802.2) .... ...1 = IG Bit: Group SSAP: NULL LSAP (0x01) 0000 000. = SAP: NULL LSAP .... ...1 = CR Bit: Response Control field: I, N(R)=80, N(S)=0 (0xA000) 1010 000. .... .... = N(R): 80 .... .... 0000 000. = N(S): 0 .... .... .... ...0 = Frame type: Information frame (0x0) Data (48 bytes) TEST 2 (Open) Packet sent to Brodcast: Spoiler Frame 2152: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface \Device\NPF_{XXX}, id 0 Section number: 1 Interface id: 0 (\Device\NPF_{XXX}) Interface name: \Device\NPF_{XXX} Interface description: Wi-Fi Encapsulation type: Ethernet (1) Arrival Time: Nov 1, 2022 12:24:49.413379000 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667301889.413379000 seconds [Time delta from previous captured frame: 0.008009000 seconds] [Time delta from previous displayed frame: 1.848025000 seconds] [Time since reference or first frame: 114.428035000 seconds] Frame Number: 2152 Frame Length: 42 bytes (336 bits) Capture Length: 42 bytes (336 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: BB:xx:xx:xx (BB_xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: BB:xx:xx:xx (BB_xx:xx:xx) Address: BB:xx:xx:xx (BB_xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: BB:xx:xx:xx (BB_xx:xx:xx) Sender IP address: 192.168.43.118 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.43.60 Packet received by ssv6051: Spoiler Frame 146: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface wlan0, id 0 Section number: 1 Interface id: 0 (wlan0) Interface name: wlan0 Encapsulation type: Ethernet (1) Arrival Time: Nov 1, 2022 12:24:49.359594497 ora solare Europa occidentale [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1667301889.359594497 seconds [Time delta from previous captured frame: 0.174150059 seconds] [Time delta from previous displayed frame: 1.848057094 seconds] [Time since reference or first frame: 42.616040768 seconds] Frame Number: 146 Frame Length: 42 bytes (336 bits) Capture Length: 42 bytes (336 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: BB_xx:xx:xx (BB:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: BB_xx:xx:xx (BB:xx:xx:xx) Address: BB_xx:xx:xx (BB:xx:xx:xx) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: BB_xx:xx:xx (BB:xx:xx:xx) Sender IP address: 192.168.43.118 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.43.60 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? Edited November 1, 2022 by handymenny 0 Quote
jock Posted November 1, 2022 Author Posted November 1, 2022 49 minutes ago, handymenny said: Some questions: Do you know if "official" Android roms have this issue? Does the other driver, svv6x5x, work with ssv6051p? 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. 0 Quote
fabiobassa Posted November 1, 2022 Posted November 1, 2022 @handymenny Where you from, if i might ask? " Orario Europa occidentale..." Seems you tzdata Is in italian 😉 0 Quote
handymenny Posted November 1, 2022 Posted November 1, 2022 @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 0 Quote
jock Posted November 1, 2022 Author Posted November 1, 2022 @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. 0 Quote
fabiobassa Posted November 1, 2022 Posted November 1, 2022 @handymenny A beh, benvenuto nel gruppo di italiani...molto numeroso really 😉 0 Quote
handymenny Posted November 1, 2022 Posted November 1, 2022 (edited) @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 Edited November 1, 2022 by handymenny 0 Quote
jock Posted November 1, 2022 Author Posted November 1, 2022 @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. 0 Quote
fabiobassa Posted November 1, 2022 Posted November 1, 2022 @handymenny Check your inbox please 0 Quote
Orcus Posted November 1, 2022 Posted November 1, 2022 (edited) Hi. Someone could help me with running Linux on my tv box MXQ Pro 4k 2gb RAM on the rk3229 processor. During the whole day I tried many options, looked at a lot of manuals, but did not get a result. Initially, I wanted to run Linux from a memory card. But none of the images from the link above started. My TV box just won't start. The monitor enters the HDMI/Analog mode several times and goes into sleep mode. Now I have installed a multitool on the memory card and started a backup. Although the backup is working, but my monitor is constantly flashing. I also don't know what it's related to Edited November 1, 2022 by Orcus 0 Quote
ArkhanLK Posted November 1, 2022 Posted November 1, 2022 2 hours ago, handymenny said: is there any way to run android from sdcard My friend, should you find an asnwer for this, please let me know!!! 0 Quote
ilmich Posted November 2, 2022 Posted November 2, 2022 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. 1 Quote
handymenny Posted November 2, 2022 Posted November 2, 2022 @jock Broadcast traffic is correctly decrypted with this hack: Force MAC80211 broadcast decrypt Multicast traffic is still corrupt though 3 Quote
handymenny Posted November 2, 2022 Posted November 2, 2022 (edited) Fixed multicast too: https://github.com/HandyMenny/ssv6xxx/commit/5ff256e8c84665253379e43e2608f7debef2d1b4 Edited November 2, 2022 by handymenny 2 Quote
jock Posted November 2, 2022 Author Posted November 2, 2022 @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 2 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.