Device-tree improvements

This is for any ARMv7 device that we do not officially support.

Re: Device-tree improvements

Postby summers » Sat Jul 27, 2019 12:19 pm

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 ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Sun Jul 28, 2019 6:02 am

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

I found the worst history case :(
The producer left to the crowd to solve the problem, as it was stated as open source, they're supposing that support is not necessary. Who (user) got a bit of interest is only putting up patches that doesn't seem last for real. So i'd say these patches are merely tests.

Let me say that is a frustrating situation. I have the only option to hope for Armbian to give something that fits my expectations. My capabilities are very poor, so I'd have to rely to someone better than me.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sun Jul 28, 2019 2:39 pm

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>;
+ };
}; ')
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Mon Jul 29, 2019 8:28 am

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.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Mon Jul 29, 2019 9:48 am

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 ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Tue Jul 30, 2019 7:54 am

Hey Summers, have you noted that this discussion has reached 14K++ visit? :D. 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
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby TheSaint » Sat Aug 17, 2019 4:13 am

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 :P
Attachments
Report.txt.7z
(14.87 KiB) Downloaded 1607 times
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby TheSaint » Sat Aug 17, 2019 11:59 am

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

I saw something on the Armbian which try to patch the serial for the BT

$this->bbcode_second_pass_code('', '#!/bin/bash

GPIO_CONFIGURED_CHECK_DIRECTORY="/var/run/rtk_bt"
GPIO_CONFIGURED_CHECK_FILE="/var/run/rtk_bt/gpio_configured"

function die_on_error {
if [ ! $? = 0 ]; then
echo $1
exit 1
fi
}

# Kill any rtk_hciattach actually running.
# Do not complain if we didn't kill anything.
killall -q -SIGTERM rtk_hciattach

# If the GPIO are not yet configured
if [ ! -f "$GPIO_CONFIGURED_CHECK_FILE" ];
then
# We'll create the directory first
# So that, if the user is not root
# he'll get a user permission error
mkdir -p "$GPIO_CONFIGURED_CHECK_DIRECTORY" || die_on_error "Could not create$GPIO_CONFIGURED_CHECK_DIRECTORY"

echo 146 > /sys/class/gpio/export
echo 149 > /sys/class/gpio/export
echo 151 > /sys/class/gpio/export
echo high > /sys/class/gpio/gpio146/direction
echo high > /sys/class/gpio/gpio149/direction
echo high > /sys/class/gpio/gpio151/direction

echo 1 > $GPIO_CONFIGURED_CHECK_FILE || die_on_error "Could not write to $GPIO_CONFIGURED_CHECK_FILE !"
fi

# If you run the rtk_hciattach once
# you cannot run it again before`
# resetting the device.
# Since resetting the device before
# the first launch generates no issue,
# we always reset the device.

echo "Resetting the Bluetooth chip"
echo 0 > /sys/class/gpio/gpio149/value &&
echo -e "\tBluetooth chip power down..." &&
sleep 1 &&
echo 1 > /sys/class/gpio/gpio149/value &&
echo -e "\tBluetooth chip power up..." &&
sleep 1
echo -e "\tResetting done"

/usr/bin/rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5 || die_on_error "Could not create hci0 through rtk_hciattach"
')
Can this be added to the dts and inform the kernel that the UART0 is assigned to the Bluetooth ?
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sat Aug 17, 2019 3:25 pm

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 ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Sun Aug 18, 2019 3:49 am

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.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

PreviousNext

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 2 guests