CSC Armbian for RK322x TV box boards

RaptorSDS · October 28, 2022

@Max Sterg but i could be more stupid like picture of handymenny , when china store also fake the print o chip ( when thats true )

Max Sterg · October 28, 2022

@RaptorSDS They did WHAT? 😵 ooohh boy.....

fabiobassa · 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 ???

Max Sterg · October 29, 2022

@fabiobassa not at all!

handymenny · October 29, 2022

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

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

handymenny · October 29, 2022

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

Max Sterg · 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 !!!! 😜

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

handymenny · October 30, 2022

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

jock · 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!!

handymenny · October 30, 2022

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

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

handymenny · October 30, 2022

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

radiant98 · 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!

handymenny · October 31, 2022

@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

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

handymenny · November 1, 2022

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

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

fabiobassa · November 1, 2022

@handymenny

Where you from, if i might ask?

" Orario Europa occidentale..."

Seems you tzdata Is in italian 😉

handymenny · 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

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

fabiobassa · November 1, 2022

@handymenny

A beh, benvenuto nel gruppo di italiani...molto numeroso really 😉

handymenny · November 1, 2022

@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

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

fabiobassa · November 1, 2022

@handymenny

Check your inbox please

Orcus · November 1, 2022

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

ArkhanLK · 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!!!

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

handymenny · November 2, 2022

@jock Broadcast traffic is correctly decrypted with this hack: Force MAC80211 broadcast decrypt

Multicast traffic is still corrupt though

Sign In

CSC Armbian for RK322x TV box boards

Recommended Posts

RaptorSDS

Max Sterg

fabiobassa

Max Sterg

handymenny

jock

handymenny

Max Sterg

jock

handymenny

jock

handymenny

jock

handymenny

radiant98

handymenny

jock

handymenny

jock

fabiobassa

handymenny

jock

fabiobassa

handymenny

jock

fabiobassa

Orcus

ArkhanLK

ilmich

handymenny

Join the conversation

Forums

My Activity Streams

Download

Store

Important Information