Open JyuHo opened 6 years ago
Super !
Si j'ai encore quelques rapports dans le genre, je vais pouvoir clôturer ce bug vieux d'un an \(・ω・)/
...
...
( ●ω●)Vieux d'un an...
J'ai utilisé la procédure que tu donnes sur le Git pour le premier lancement,
puis j'ai fait quelques modifications. J'ai déplacé les ficviers.sh dans un nouveau dossier (usr/local/lib/rtk-bt/).
le fichier start_bt.sh ressemble à ceci maintenant:
#!\bin\sh
# If the GPIO are not yet configured
if [ ! -f "/var/run/rtk_bt/gpio_configured" ];
then
# We'll create the directory first
# So that, if the user is not root
# he'll get a user permission error
mkdir -p "/var/run/rtk_bt"
/usr/local/lib/rtk-bt/configure_bt_gpio.sh
echo 1 > /var/run/rtk_bt/configured
else
# 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.
# TODO
# - Check if that doesn't interfere with the WIFI Chip !
/usr/local/lib/rtk-bt/reset_bt_through_gpio.sh
fi
J'ai créé un nouveau service dans dans
/lib/systemd/system/tinker-bluetooth-waheup.service
avec ce contenu :
[Unit]
Description=Bluetooth wake up walkaround
After=rc-local.service
Before=tinker-bluetooth.service
[Service]
Type=oneshot
ExecStartPre=/bin/bash /usr/local/lib/rtk-bluetooth/reset_bt_through_gpio.sh
ExecStart=/usr/sbin/rfkill unblock all
ExecStartPost=/bin/bash /usr/local/lib/rtk-bluetooth/start_bt.sh
[Install]
WantedBy=rc-local.service
et j'ai juste modifier le tinker-bluetooth.service
comme ceci :
[Unit]
Description=Realtek H5 bluetooth support
Before=bluetooth.service
After=tinker-bluetooth-wakeup.service
[Service]
ExecStart=/usr/bin/rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5
Restart=on-failure
[Install]
WantedBy=multi-user.target
J'ai ensuite activé fait un :
sudo systemctl daemon-reload
Activé mon nouveau service avec "enable"
Ah j'ai aussi donner les droits à mon user en modifiant
sudo nano /etc/dbus-1/system.d/bluetooth.conf
et j'ai ajouté ceci :
<policy user="tinker">
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.Agent1"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
</policy>
Juste en dessous du <policy user="root">
Et dernière chose :
sudo modprobe -r r8723bs
sudo modprobe -a r8723bs
sudo depmod -a
et un reboot pour que tout se lance
Voilà j'espère que tout ceci pourra aider et que tu pourras clôturer du coup
Jyu
Note qu'il y avait un bug dans mon ./start_bt.sh . Le fichier vérifie est /var/run/rtk_bt/gpio_configured
mais le script créé /var/run/rtk_bt/configured
ce qui fait que la première vérification foire à chaque fois.
Ça serait peut être mieux de créer une variable d'environnement, généré si non réglé à la base. Je crois qu'il y a un nom de variable d'environnement standardisé pour les RUN file, surtout avec systemd
. RUNFILE peut être ?
Je vais voir ça.
Du coup j'ai récupéré le scripts start_bt.sh
à jour.
J'ai quand même modifier un peu pour que ça reste bon dans ma configuration actuelle.
start_bt.sh
#!/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"` `/usr/local/lib/rtk_bt/configure_bt_gpio.sh || die_on_error "Could not configure the Bluetooth GPIO"` `echo 1 > $GPIO_CONFIGURED_CHECK_FILE || die_on_error "Could not write to $GPIO_CONFIGURED_CHECK_FILE !"` `else` `# 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.`
# TODO
# - Check if that doesn't interfere with the WIFI Chip !
/usr/local/lib/rtk_bt/reset_bt_through_gpio.sh || die_on_error "Could not reset the Bluetooth chip"
/usr/bin/rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5 || die_on_error "Could not create hci0 through rtk_hciattach"
fi
J'ai supprimer mon service rinker-bluetooth-wakeup.service
Et j'ai modifier le service tinker-bluetooth.service
tinker-bluetooth.service
[Unit]
Description=Realtek H5 bluetooth support
Before=bluetooth.service
`
[Service]
ExecStartPre=/usr/sbin/rfkill unblock all
ExecStart=/bin/bash /usr/local/lib/rtk_bt/start_bt.sh
Restart=on-failure`
[Install]
WantedBy=multi-user.target
Du coup tout fonctionne correctement.
Le fichier run_rtk_hciattach.sh
ne me servant pas je l'ai viré et remplacé par cette ligne dans le start_bt.sh
par cette ligne
/usr/bin/rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5 || die_on_error "Could not create hci0 through rtk_hciattach
As mentioned on the armbian forums, I found the else block was causing it not to actually set up bt on boot, only the gpio. Got rid of else, moved fi and all is well. :-)
committed changes to Armbian development branch, rolled out on both next and default, it's way better than the Rockchip code in this case for 4.4 bsp kernel. https://github.com/armbian/build/commit/ac8d0d86687007c894caf18b0ba85d99c38eb8b1 https://github.com/armbian/build/commit/daf80053e8a1eda8ee2f95d879ec525f1d92fbe0
Oh, one last bit: Tinker 4.14 now supports everything except 4k and the vcodec. :-)
Okay, okay, I'll get to the vcodec :3
Still, I'm starting to test Vulkan with the Mali T760 drivers for Firefly systems provided by ARM and... the first steps are working ! https://github.com/Miouyouyou/Vulkan_Steps/tree/devel/First_Code
Still, just querying the devices and displaying information, with a minimal error handling, takes ~300 lines of code... If I can get to the point where I can allocate a buffer, display with DRM and write in it with Vulkan, I'll take a look at the vcodec, once again.
The 4K issue is an HDMI resolution thing ?
The 4K issue is an HDMI resolution thing ?
I'm not sure to be honest.
I'm starting to test Vulkan with the Mali T760 drivers for Firefly systems provided by ARM
Awesome!
J'ai utilisé les fichiers fourni sur ton git et verdict le bluetooth est fonctionnel. Scan, Pair, Discover, Connect.
Niveau de Armbian c'est un fresh install, donc just fait un apt update et upgrade. Niveau des paquet j'ai juste installé python pour les librairies gpio fourni sur le git tinkerboard
Voilà j'espère que ce petit retour pourra aider
Jyu