Device-tree improvements

[summers]

Well think the problem is that tinkerboard isn't officially supported by many link distributions. E.g. ArchLinux Arm.

So ArchLinux Arm typically does have patches for boards its supports. But my gut feeling is if a patch is correct, it should be mainlined. And mainlining tinkerboard patches is whats been slowly being done. That to me is the better way, one mainlined it is far easier to support a board; not that ArchLinux Arm goes in that direction - but is possible for the user to maintain the board without too much hassle ...

[TheSaint]

$this->bbcode_second_pass_quote('summers', ' ')tinkerboard isn't officially supported by many link distributions

[summers]

Just notice that serdev basic support has been added to the kernel https://github.com/torvalds/linux/commit/ce945552fde4a09f0bd4c0a33b8694b8515e2bd9 make me wonder if my serdev patch to device tree may work now.

$this->bbcode_second_pass_code('', '&uart0 {
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
+
+ bluetooth {
+ clocks = <&rk808 RK808_CLKOUT1>;
+ reset-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
+ device-wake-gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
+ host-wake-gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
+ vcc-18-supply = <&vcc_18>;
+ vcc-io-supply = <&vcc_io>;
+ };
}; ')

[TheSaint]

Well, I switched to the stock dtb, which doesn't give much problem.
Over all I very happy to the point I achieve. But a bit late that took about one year long.

[summers]

Yes - and looking at that dtb, it doesn't specify to load the h5 bluetooth driver, and also the h5 bluetooth driver doesn't have the handles yet such that it can be loaded.

Still should be a simplish change. just needs someone to do the work. The serdev patch came out of redhat - so don't know if they are active ...

[TheSaint]

Hey Summers, have you noted that this discussion has reached 14K++ visit? . That means somebody had interest on what is the matter.
Well, to do with bluetooth, they used some patch along the booting procedure as they done with HDMI. Probably what the patch doing is not fine grained as you want to.

Undocumented product is a bad common behavior from eastern manufacturer. That's a lesson I have to learn.

[TheSaint]

I got a new kernel which at the first starting created some problem for wireless. I read some information stating certain changes on wireless, so I thought it might happen to the arm architecture.
My case is that after some amount of time the netctl brakes and the module doesn't respond.
I'm testing if I overseen it or it's really a constant effect.
Enclosed the three cases with the different setting.

EDIT
Indeed here is it
$this->bbcode_second_pass_code('', '$ sudo netctl status wlrouter
* netctl@wlrouter.service - A simple WPA encrypted wireless connection
Loaded: loaded (/usr/lib/systemd/system/netctl@.service; enabled; vendor pre>
Drop-In: /etc/systemd/system/netctl@wlrouter.service.d
`-profile.conf
Active: active (exited) since Sat 2019-08-17 12:13:27 +08; 7min ago
Docs: man:netctl.profile(5)
Process: 721 ExecStart=/usr/lib/netctl/network start wlrouter (code=exited, s>
Main PID: 721 (code=exited, status=0/SUCCESS)
Status: "online"
Tasks: 2 (limit: 4645)
Memory: 6.7M
CGroup: /system.slice/system-netctl.slice/netctl@wlrouter.service
|-1550 wpa_supplicant -q -B -P /run/wpa_supplicant-wlan0.pid -i wlan>
`-1667 dhcpcd -4 -q -t 30 -L wlan0

Aug 17 12:13:28 alarm dhcpcd[1606]: wlan0: probing address xxx.xxx.xxx.5/24
Aug 17 12:13:34 alarm dhcpcd[1606]: wlan0: leased xxx.xxx.xxx.5 for infinity
Aug 17 12:13:34 alarm dhcpcd[1606]: wlan0: adding route to xxx.xxx.xxx.0/24
Aug 17 12:13:34 alarm dhcpcd[1606]: wlan0: adding default route via xxx.xxx.xxx.1
Aug 17 12:13:34 alarm dhcpcd[1606]: forked to background, child pid 1667
Aug 17 12:13:34 alarm network[721]: Started network profile 'wlrouter'
Aug 17 12:18:15 alarm dhcpcd[1667]: route socket overflowed - learning interfac>
Aug 17 12:18:15 alarm dhcpcd[1667]: wlan0: carrier lost
')
Well, I might presume that is caused by the high traffic of home-assistant. But with Summers dtb it keeps going flawlessly

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'J')ust notice that serdev basic support has been added to the kernel

[summers]

Looks like armbian is twiddling gpio pins for bluetooth, so not using a kernel to set things up.

IIRC my patch to the kernel tied the bluetooth to a uart using serdev, this wasn't accepted, as the blue tooth kernel model (h5 iirc, which was 3 wire, even though your board is 5 wire), which has been written didn't have a method of pulling it into the kernel. I didn't have time to add the flags to the kernel module so a dtb could load the driver.

Now without these changes, it didn't look to me like it would work. The kernel needs to know which driver to attach to the end of a uart when done via serdev, and this didn't exist.

Anyway let me see if I can find the blob, so you can see the structure of what is needed, and why it doesn't work ...

[TheSaint]

OK, I don't have much hope. Everybody might have dropped the issue. I suppose that even Asus might look for a brad new SBC, competitor on the market, so the current model could exist only on the shelves.

I just highlighted this to have a little glimmer to the case. Anyway I see that the latest kernel brings problems, which are not related to which dtb is loaded, kernel one or yours.