DeGRuS 4.2.2 : Tests pour résoudre les derniers problèmes

steveJC · 8 octobre 2013

@SteveJC,

J'ai remis les fichiers mais ça ne marche pas (attention aussi à la glib.so qui fait crasher l'appli mms.apk !).

Il y a probablement un problème de droits. Je sais pas.
static int bt_sock_create(struct net *net, struct socket *sock, int proto, int kern)
{
    int err;
 
    if (proto == BTPROTO_RFCOMM || proto == BTPROTO_SCO ||
    proto == BTPROTO_L2CAP) {
    if (!current_has_bt())
        return -EPERM;
    } else if (!current_has_bt_admin())
        return -EPERM;
Merci

J'ai cela dans le ram disk,

chmod 0600 /dev/ttyMT1

chmod 0660 /sys/class/rfkill/rfkill0/state

chown bluetooth bluetooth /dev/ttyMT1

Je vais essayer en mettant plus de droit

chmod 0660 /dev/ttyMT1

ok alors maintenant prend le fichier modem.img du 4.1 dans systeme\etc\firmware et met le dans le 4.2.2.

pourquoi ?

Les connexions GSM 3G sont OK

Tiens je viens de comparer avec le ROM du ZTE il y des permissions en plus dans Platform.xml

une piste ?

Modifié 8 octobre 2013 par steveJC

DMBFR · 8 octobre 2013

Salut steve au taquet!!! lol

Je me duis posé aussi la question du pourquoi il y a 2 dossiers permission sur la rom 4.22, un avec un "s" et l'autre sans? Sur les autres ROM il n'y en a qu'un en principe, même sur les autres tel d'ailleurs. Et dnas le sans "s" il n'y a qu'un fichier pour le GPS, bizarre.

Modifié 8 octobre 2013 par DMBFR

steveJC · 8 octobre 2013

Salut steve au taquet!!! lol

Je me duis posé aussi la question du pourquoi il y a 2 dossiers permission sur la rom 4.22, un avec un "s" et l'autre sans? Sur les autres ROM il n'y en a qu'un en principe, même sur les autres tel d'ailleurs. Et dnas le sans "s" il n'y a qu'un fichier pour le GPS, bizarre.

C'est une erreur ;)

DMBFR · 8 octobre 2013

Je pense aussi, mais je me demande s'il faut garder avec "s" ou sans, faut que je regarde sur mon htc mais normalement il me semble que c'est sans

steveJC · 8 octobre 2013

Je pense aussi, mais je me demande s'il faut garder avec "s" ou sans, faut que je regarde sur mon htc mais normalement il me semble que c'est sans

non c'est /system/etc/permissions

new_profile · 11 octobre 2013

Salut,
Je remarque le fait suivant entre la 4.2.2 et la 4.1.1:

4.1.1

# cat /data/system/packages.list | grep blue
com.android.bluetooth 10002 0 /data/data/com.android.bluetooth

4.2.2

# cat /data/system/packages.list | grep blue
com.android.bluetooth 10077 0 /data/data/com.android.bluetooth
com.mediatek.bluetooth 10046 0 /data/data/com.mediatek.bluetooth

A mon avis, le problème du BT réside dans l'utilitaire "brcm_patchram_plus" qui ne se lance pas. En effet, sur le 4.1.1, nous avons bien les processus suivant:

bluetooth 108   1     1636   920   ffffffff 00000000 S /system/bin/dbus-daemon
bluetooth 415   1     1112   448   ffffffff 00000000 S /system/bin/brcm_patchram_plus
bluetooth 483   1     2416   1448  ffffffff 00000000 S /system/bin/bluetoothd

Seulement voilà, sous la 4.2.2 ce processus n'y est pas. De plus, le lancement de la commande suivante échoue (se bloque) sous la 4.2.2

/system/bin/brcm_patchram_plus --enable_hci --enable_lpm --no2bytes --tosleep50000 --baudrate 1500000 --use_baudrate_for_download --patchram /etc/firmware/BCM4330B1.hcd /dev/ttyMT1 --bd_addr 43:29:b1:55:56:01

Ceci indique que le firmware n'est pas correctement mis en RAM.

J'ai fait du "strace" et ce que je remarque c'est que l'utilitaire est bloqué dans la lecture à partir du device "/dev/ttyM1" !!!

Sous 4.1.1

writev(7, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"itoa_buff=[d0:b3:3f:7a:8f:81]\n\r\0", 32}], 3) = 52
writev(7, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"optarg=[43:29:b1:55:56:01]\n\r\0", 29}], 3) = 49
open("/dev/ttyMT1", O_RDWR|O_NOCTTY|O_LARGEFILE) = 17
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(17, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
sigaction(SIGALRM, {0x4002d349, [], SA_RESTART}, {SIG_DFL}, 0x40048129) = 0
write(17, "\1\3\f\0", 4)                = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={4, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0

Sous 4.2.2

writev(3, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"itoa_buff=[d0:b3:3f:7a:8f:81]\n\r\0", 32}], 3) = 52
writev(3, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"optarg=[43:29:b1:55:56:01]\n\r\0", 29}], 3) = 49
mprotect(0x4008a000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x4008a000, 4096, PROT_READ)   = 0
open("/dev/ttyMT1", O_RDWR|O_NOCTTY|O_LARGEFILE) = 10
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
sigaction(SIGALRM, {0x40077349, [], SA_RESTART}, {SIG_DFL}, 0x400f325d) = 0
write(10, "\1\3\f\0", 4)                = 4
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={4, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
read(10, 0x4007a200, 3)                 = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
write(10, "\1\3\f\0", 4)                = 4
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={4, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
sigreturn()                             = ? (mask now [])
read(10, 0x4007a200, 3)                 = ? ERESTARTSYS (To be restarted)

Et comme vous le remarquez, la première différence provient du retour de la fonction write() qui

dans le cas de la 4.1.1 elle retourne 0 ==> Ecriture OK mais 0 octets réellement inscrit
dans le cas de la 4.2.2 elle retourne 4 ==> Ecriture OK mais 4 octets effectivement inscrit

Edit 1:
C'est la fonction hci_reset() qui échoue:

uchar hci_reset[] = { 0x01, 0x03, 0x0c, 0x00 };
 

void
proc_reset()
{
    signal(SIGALRM, expired);
 
    hci_send_cmd(hci_reset, sizeof(hci_reset));
 
    alarm(4);
 
    read_event(uart_fd, buffer);
 
    alarm(0);
}

Edit 2:

la commande "lsof" montre que le processus "mtkbt" qui est supposé se lancer une seule fois et disparaitre après (oneshot) est toujours vivant. Sur la 4.1.1 ce n'est pas le cas !

Par contre, il n'y a pas de différences entres les devices de la 4.1.1 et de la 4.2.2 (cat /proc/devices)

Décidément, je pense qu'il y a un problème avec le sous-système HCI qui est bloqué ou bien qui n'est pas arrivé à ce lancer. Malheureusement, le buffer de commande "dmesg" est trop limité et j'arrive pas à avoir des traces kernel significatives. Je n'ai pas l'impression qu'un tel problème a été rencontré de la même manière chez xda :(

Merci

Modifié 12 octobre 2013 par new_profile

new_profile · 13 octobre 2013

Salut,

Est-ce que que quelqu'un a t-il essayer de compiler le kernel du repo: https://github.com/wiko-sources/cink-slim

En effet, je bute sur une erreur que j'arrive pas à résoudre:

  LD      mediatek/source/kernel/kernel/built-in.o
  LD      mediatek/source/kernel/built-in.o
scripts/Makefile.build:44: ~/Android/cink-slim-master/kernel/mediatek/custom/out/s8073/kernel/Makefile: No such file or directory
make[1]: *** No rule to make target `~/Android/cink-slim-master/kernel/mediatek/custom/out/s8073/kernel/Makefile'.  Stop.

Mes commandes de compilation:

export PATH=$PATH:~/Android/prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin
export TARGET_PRODUCT=s8073
export MTK_ROOT_CUSTOM=../mediatek/custom
cd ~/Android/cink-slim-master/kernel
cp mediatek-configs .config
make

Merci bien pour votre aide.

kookesam · 13 octobre 2013

bonjour pour le kernel regarde du coter du peax:https://forum.frandroid.com/topic/164484-wcp-kernel-34-from-sources/page-2

degrus · 13 octobre 2013

Salut,

Je remarque le fait suivant entre la 4.2.2 et la 4.1.1:

4.1.1

# cat /data/system/packages.list | grep blue
com.android.bluetooth 10002 0 /data/data/com.android.bluetooth

4.2.2

# cat /data/system/packages.list | grep blue
com.android.bluetooth 10077 0 /data/data/com.android.bluetooth
com.mediatek.bluetooth 10046 0 /data/data/com.mediatek.bluetooth

A mon avis, le problème du BT réside dans l'utilitaire "brcm_patchram_plus" qui ne se lance pas. En effet, sur le 4.1.1, nous avons bien les processus suivant:

bluetooth 108   1     1636   920   ffffffff 00000000 S /system/bin/dbus-daemon
bluetooth 415   1     1112   448   ffffffff 00000000 S /system/bin/brcm_patchram_plus
bluetooth 483   1     2416   1448  ffffffff 00000000 S /system/bin/bluetoothd

Seulement voilà, sous la 4.2.2 ce processus n'y est pas. De plus, le lancement de la commande suivante échoue (se bloque) sous la 4.2.2

/system/bin/brcm_patchram_plus --enable_hci --enable_lpm --no2bytes --tosleep50000 --baudrate 1500000 --use_baudrate_for_download --patchram /etc/firmware/BCM4330B1.hcd /dev/ttyMT1 --bd_addr 43:29:b1:55:56:01

Ceci indique que le firmware n'est pas correctement mis en RAM.

J'ai fait du "strace" et ce que je remarque c'est que l'utilitaire est bloqué dans la lecture à partir du device "/dev/ttyM1" !!!

Sous 4.1.1

writev(7, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"itoa_buff=[d0:b3:3f:7a:8f:81]\n\r\0", 32}], 3) = 52
writev(7, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"optarg=[43:29:b1:55:56:01]\n\r\0", 29}], 3) = 49
open("/dev/ttyMT1", O_RDWR|O_NOCTTY|O_LARGEFILE) = 17
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(17, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, TCFLSH, 0x2)                  = 0
ioctl(17, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
sigaction(SIGALRM, {0x4002d349, [], SA_RESTART}, {SIG_DFL}, 0x40048129) = 0
write(17, "\1\3\f\0", 4)                = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={4, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0
read(17, "", 3)                         = 0

Sous 4.2.2

writev(3, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"itoa_buff=[d0:b3:3f:7a:8f:81]\n\r\0", 32}], 3) = 52
writev(3, [{"\3", 1}, {"brcm_patchram_plus\0", 19}, {"optarg=[43:29:b1:55:56:01]\n\r\0", 29}], 3) = 49
mprotect(0x4008a000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x4008a000, 4096, PROT_READ)   = 0
open("/dev/ttyMT1", O_RDWR|O_NOCTTY|O_LARGEFILE) = 10
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, TCFLSH, 0x2)                  = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
sigaction(SIGALRM, {0x40077349, [], SA_RESTART}, {SIG_DFL}, 0x400f325d) = 0
write(10, "\1\3\f\0", 4)                = 4
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={4, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
read(10, 0x4007a200, 3)                 = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
write(10, "\1\3\f\0", 4)                = 4
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={4, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
sigreturn()                             = ? (mask now [])
read(10, 0x4007a200, 3)                 = ? ERESTARTSYS (To be restarted)

Et comme vous le remarquez, la première différence provient du retour de la fonction write() qui

dans le cas de la 4.1.1 elle retourne 0 ==> Ecriture OK mais 0 octets réellement inscrit
dans le cas de la 4.2.2 elle retourne 4 ==> Ecriture OK mais 4 octets effectivement inscrit

Edit 1:

C'est la fonction hci_reset() qui échoue:

uchar hci_reset[] = { 0x01, 0x03, 0x0c, 0x00 };
 

void
proc_reset()
{
    signal(SIGALRM, expired);
 
    hci_send_cmd(hci_reset, sizeof(hci_reset));
 
    alarm(4);
 
    read_event(uart_fd, buffer);
 
    alarm(0);
}

Edit 2:

la commande "lsof" montre que le processus "mtkbt" qui est supposé se lancer une seule fois et disparaitre après (oneshot) est toujours vivant. Sur la 4.1.1 ce n'est pas le cas !

Par contre, il n'y a pas de différences entres les devices de la 4.1.1 et de la 4.2.2 (cat /proc/devices)

Décidément, je pense qu'il y a un problème avec le sous-système HCI qui est bloqué ou bien qui n'est pas arrivé à ce lancer. Malheureusement, le buffer de commande "dmesg" est trop limité et j'arrive pas à avoir des traces kernel significatives. Je n'ai pas l'impression qu'un tel problème a été rencontré de la même manière chez xda :(

Merci

est ce tu peux essayer avec ca :: /dev/ttyMSM0 0600 bluetooth bluetooth

il faut l'ajouter dans le fichier ueventd.rc dans la rmdisk

Modifié 13 octobre 2013 par degrus

Lannig · 13 octobre 2013

@Degrus : évite de citer entièrement un post de 3km de long quand tu réponds STP. Ne garde dans la citation que ce qui est nécessaire.

--Tapatalk

new_profile · 13 octobre 2013

Salut Bassem,

Ok Je vais essayer dès que finis d'installer la SS1 (j'étais depuis longtemps sur la S1).

Cependant, je ne crois pas que ce device est valable: voici le listing des devices disponibles sous la 4.1.1 et la 4.2.2 (cat /proc/devices):

4.1.1

Character devices:
  1 mem
  2 pty
  3 ttyp
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
 10 misc
 13 input
 14 sound
 29 fb
 90 mtd
108 ppp
116 alsa
128 ptm
136 pts
160 Vcodec
169 ttyC
178 ccci_fs
180 usb
182 sec
183 CCCI_IPC_DEV
184 ccci
188 M4U_device
189 usb_device
196 devmap
204 ttyMT
216 rfcomm
225 devapc
226 pvrsrvkm
227 ttyGS
228 camera-resmgr
229 camera-sysram
230 camera-eis
231 camera-isp
232 kd_camera_hw
233 DumChar
234 mt6575-smimon
235 mt-mdp
236 accdet
237 mtk-adc-cali
238 TV-out
239 MTK_MAU
240 FM52AF
241 FM51AF
242 FM50AF
243 watchdog
244 MT_pmic_adc_cali
245 mtk_jpeg
246 mtkg2d
247 kd_camera_flashlight
248 mtkfb_vsync
249 sched
250 btn
251 mmp
252 camera-fdvt
253 BOOT
254 rtc

Block devices:
259 blkext
  7 loop
  8 sd
 31 mtdblock
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 device-mapper

4.2.2

Character devices:
  1 mem
  2 pty
  3 ttyp
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
 10 misc
 13 input
 14 sound
 29 fb
 90 mtd
108 ppp
116 alsa
128 ptm
136 pts
160 Vcodec
169 ttyC
178 ccci_fs
180 usb
182 sec
183 CCCI_IPC_DEV
184 ccci
188 M4U_device
189 usb_device
196 devmap
204 ttyMT
216 rfcomm
225 devapc
226 pvrsrvkm
227 ttyGS
228 camera-resmgr
229 camera-sysram
230 camera-eis
231 camera-isp
232 kd_camera_hw
233 DumChar
234 mt6575-smimon
235 mt-mdp
236 accdet
237 mtk-adc-cali
238 TV-out
239 MTK_MAU
240 FM52AF
241 FM51AF
242 FM50AF
243 watchdog
244 MT_pmic_adc_cali
245 mtk_jpeg
246 mtkg2d
247 kd_camera_flashlight
248 mtkfb_vsync
249 sched
250 btn
251 mmp
252 camera-fdvt
253 BOOT
254 rtc

Block devices:
259 blkext
  7 loop
  8 sd
 31 mtdblock
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 device-mapper

Merci

SteveJC,

Je regarde le lien sur le peax et le source sous github (https://github.com/skritchz/s9091_jb) contient la config pour s9091_jb mais pas pour s8073. Je vais faire un merge et voir ce qui ma manque dans le code source.

Merci bien.

new_profile · 14 octobre 2013

Même la compilation du kernel est difficile avec MediaTek !! Je ne sais pas pourquoi il y a plusieurs sources au lieu d'avoir une seule et unique branche. Bizarre !

Le portage du kernel de PEAX vers le SLIM nécessite plus de temps vu que seul celui de la 4.0.4 est dispo pour le slim.

Ce qui m'intrigue surtout ce sont les flags suivant:

# Disable MTK Bluetooth stack and enable Broadcom Bluetooth
BCM_BT_SUPPORT=yes
MTK_BT_SUPPORT=no
MTK_BT_CHIP=BCM4330

steveJC · 15 octobre 2013

Même la compilation du kernel est difficile avec MediaTek !! Je ne sais pas pourquoi il y a plusieurs sources au lieu d'avoir une seule et unique branche. Bizarre !

Le portage du kernel de PEAX vers le SLIM nécessite plus de temps vu que seul celui de la 4.0.4 est dispo pour le slim.

Ce qui m'intrigue surtout ce sont les flags suivant:
# Disable MTK Bluetooth stack and enable Broadcom Bluetooth
BCM_BT_SUPPORT=yes
MTK_BT_SUPPORT=no
MTK_BT_CHIP=BCM4330

Oui c'est normal, car notre Slim n'utilise pas le composant mediatek 4 en 1 qui gére le bluetooth, le wifi ,la FM et le GPS (comme le slimB)

Mais au lieu de cela, il utilise des composants broadcom d'ou le BCM_

Il y a le BCM4330 => Bluetooth et FM radio , révision BCM4330B1

et le BCM4751 ==> GPS

et dans le meme fichier on trouve :

# Disable MTK GPS and enable Broadcom GPS

BCM_GPS_SUPPORT=yes

MTK_GPS_SUPPORT=no

# Disable MTK FM and enable Broadcom FM

BCM_FM_SUPPORT=yes

MTK_FMRADIO_APP=no

MTK_FM_CHIP=BCM4330_FM

Modifié 15 octobre 2013 par steveJC

new_profile · 15 octobre 2013

Salut SteveJC,

Mon besoin pour recompiler le kernel est d'augmenter la taille du buffer circulaire pour le dmesg "CONFIG_LOG_BUF_SHIFT" qui est limité à 128K. J'aimerais l'augmenter à 1M pour avoir toutes les traces kernel et espérer débusquer le problème du BT.

Malheureusement pour nous, le ring buffer est crée en statique et non pas par un kmalloc (kernel/printk.c). Du coup, je n'ai pas le choix je dois recompiler.

S'il y a une meilleure idée je suis preneur.

Pour l'instant, j'intégre les modules petit à petit (ce n'est pas évident !).

Merci.

new_profile · 16 octobre 2013

Salut,

J'ai pu enfin reporter les modifs du kernel 3.0.13 (ICS) du slim et compiler un noyau en se basant sur le travail de skritchz pour le peax (https://github.com/skritchz/s9091_jb). Je vais tester le tester courant de la semaine.

Cependant, j'ai un gros souci avec le fichier "bluesleep.c" qui est carrément non fonctionnel avec la nouvelle stack bluez. Il va falloir faire un grand rework sur ce fichier.,De ce fait, je ne pense pas que le BT sera opérationnel :(

Je vais entre temps, migrer vers la nouvelle branche de skritchz disponible sous: https://github.com/skritchz/android_kernel_wiko_peaxjb

Pour info, voici le diff entre le branche initiale du peax et celle que j'ai compilé:

https://mega.co.nz/#!gpolhZpS!c-fmkna61SA_b-s0ikpAimS7vY8bweMyafPRY_4MSho

Compilations steps:

export PATH=$PATH:$HOME/Android//prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin
export CROSS_COMPILE=arm-linux-androideabi-
export TARGET_PRODUCT=s8073
cd kernel/
./build.sh release

Toute aide sera le bien venue.

Modifié 16 octobre 2013 par new_profile

degrus · 16 octobre 2013

bonjour,

J'ai une simple question pourquoi t'as utilisé les sources de peax et non pas les sources de king????

new_profile · 16 octobre 2013

Salut Degrus et bonne fête,

Loin de connaitre la diff entre les deux kernel et les 2 produits j'ai pris comme indication celle de SteveJC. Cependant, si tu peux m'indiquer le meilleur choix je peux reprendre le travail vu que j'ai pu isoler le code à rajouter.

Merci bien Degrus.

degrus · 16 octobre 2013

Je pense que le king est plus proche côté hardware du slim mtk6577 alors que le peax est un mtk 6589

Modifié 16 octobre 2013 par degrus

steveJC · 16 octobre 2013

Degrus, tu es sur que le peax est un 6589 ? (le peax 2 oui mais pas le premier)

Sinon pour bluesleep.c, peut etre voir sur une CM 10.1

en tout cas super boulot

beawulf · 16 octobre 2013

Oui, le peax tourne sur également sur un MTK6577.

Le 6589 est un quadcore.

degrus · 16 octobre 2013

Degrus, tu es sur que le peax est un 6589 ? (le peax 2 oui mais pas le premier)

Sinon pour bluesleep.c, peut etre voir sur une CM 10.1

en tout cas super boulot

Oui, le peax tourne sur également sur un MTK6577.

Le 6589 est un quadcore.

ok désolé j'ai fais une confusion

new_profile · 16 octobre 2013

Salut,

Je viens de tester rapidement le kernel généré et bien sur ça ne boote pas (le contraire m'aurait étonné). Donc, j'ai besoin de savoir quel sont les outils utilisé pour débuggué le kernel sous Android ?

Sous STLinux ou Intel Atom je suis plus habitué au JTAG et je ne sais pas comment progressé sans :(

Question pour un champion svp: y'a t-il qcq qui connait la liste des gpio pour le S8073 ?

Merci bien.

steveJC · 17 octobre 2013

Bonjour,

J'ai trouvé dans les sources d'android le fichier qui gére soit le Bluetooth avec les drivers mediatek ou pas

c'est le fichier

frameworks/base/core/jni/android_server_BluetoothService.cpp

cela dépend de la définition ou pas de HAVE_BLUETOOTH ou de __BTMTK__

static jint enableNative(JNIEnv *env, jobject object) {

#ifdef HAVE_BLUETOOTH

    LOGV("%s", __FUNCTION__);

    return bt_enable();

#endif
#ifdef __BTMTK__

    native_data_t *nat = get_native_data(env, object);
    LOGI("[GAP][API] enableNative");

    if(nat)

    {

        nat->state = BTMTK_POWER_STATE_TURNING_ON;

        if (btmtk_gap_power_on(nat))

        {

            btmtk_gap_init(env, object);

   btmtk_hdp_init(env, object);

            nat->state = BTMTK_POWER_STATE_ON;

            return 0;

        }

        else

        {

            nat->state = BTMTK_POWER_STATE_OFF;

    return -1;

}

    }

#endif

    return -1;

}

le lancement du Bluetooth par les fonction hci se fait dans :

./system/bluetooth/bluedroid/bluetooth.c

int bt_enable() {

    LOGV(__FUNCTION__);
    int ret = -1;

    int hci_sock = -1;

    int attempt;

#ifdef RDA_BT_SUPPORT

 sleep(4);

#endif
    if (set_bluetooth_power(1) < 0) goto out;
    LOGI("Starting hciattach daemon");

    if (property_set("ctl.start", "hciattach") < 0) {

        LOGE("Failed to start hciattach");

        set_bluetooth_power(0);

        goto out;

    }
    // Try for 10 seconds, this can only succeed once hciattach has sent the

    // firmware and then turned on hci device via HCIUARTSETPROTO ioctl

    for (attempt = 1000; attempt > 0;  attempt--) {

        hci_sock = create_hci_sock();

        if (hci_sock < 0) goto out;
        ret = ioctl(hci_sock, HCIDEVUP, HCI_DEV_ID);
        LOGI("bt_enable: ret: %d, errno: %d", ret, errno);

        if (!ret) {

            break;

        } else if (errno == EALREADY) {

            LOGW("Bluetoothd already started, unexpectedly!");

            break;

        }
        close(hci_sock);

        usleep(100000);  // 100 ms retry delay

    }

    if (attempt == 0) {

        LOGE("%s: Timeout waiting for HCI device to come up, error- %d, ",

            __FUNCTION__, ret);

        if (property_set("ctl.stop", "hciattach") < 0) {

            LOGE("Error stopping hciattach");

        }

        set_bluetooth_power(0);

        goto out;

    }
    LOGI("Starting bluetoothd deamon");

    if (property_set("ctl.start", "bluetoothd") < 0) {

        LOGE("Failed to start bluetoothd");

        set_bluetooth_power(0);

        goto out;

    }
    ret = 0;
out:

    if (hci_sock >= 0) close(hci_sock);

    return ret;

}

Modifié 17 octobre 2013 par steveJC

new_profile · 17 octobre 2013

Salut SteveJC,

Dans ce cas il va falloir qu'on reprend la "libandroid_runtime.so" de la 4.1.1 ?

Je crains aux impact vis-à-vis des autres modules.

mazik · 17 octobre 2013

Salut,

Je viens de tester rapidement le kernel généré et bien sur ça ne boote pas (le contraire m'aurait étonné).

Tu as bien rajouté le kernel header ? :

https://forum.frandroid.com/topic/127420-pour-ce-qui-veulent-cyanogen-ou-autres-rom-custom-cest-par-ici/page-11#entry2305767

Connexion

DeGRuS 4.2.2 : Tests pour résoudre les derniers problèmes

Recommended Posts

Lien vers le commentaire

Partager sur d’autres sites

Top forumeurs sur ce sujet

Jours populaires

Top forumeurs sur ce sujet

Jours populaires

Posts populaires

steveJC

steveJC

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Rejoignez la conversation

Annonces