Reprise du message précédent :
utilise Canti ou comics2reader

Pour le touchscreen, quand on fait un strace depuis le début on voit

 
en quoi c'est grave la ligne de commande, il s'agit d'actions sequentielles, c'est donc plus lisible d'utiliser des verbe et des mots (commande et parametres) que de remontrer ou refaire à chaque fois la manip à la souris.

Bon j'ai récupéré des infos depuis le touchscreen. Le bout de code est là https://github.com/2PetitsVerres/e6 [...] o-world-ts
 
Vous killez MainApp. lancez le hello-ts et avec le stylet vous vous amusez. Ça lira 1000 event (ou attendra 10 000 secondes, si vous mettez plus de 2 heures à sortir le stylet)
 

Bon ok, il y a une faute à eraser

Si tu couples ça à ton code pour "écrire" sur l'écran, tu nous fais un télécran ?

pas avant la semaine prochaine j'ai des trucs à faire avant (comme essayer de changer de boulot, mais écrire un peu de code était plus attirant qu'écrire un cv ce soir   )

Je compatis

non mais il n'y a rien à compatir hein, j'ai un boulot. Là je veux juste en changer, si j'envoie pas mon cv ce ne sera que ma faute   (mais pas trop grave quoi)

Cool !
 
Maintenant, si on sait comment écrire sur l'écran et lire le stylet et les touches, on va pouvoir commencer à faire des choses intéressantes !

Ce n'est pas le mystère de la Grande Pyramide, mais bon...

Il y avait 2 points a priori non liés, que je ne comprenais pas :

• il n'y a pas sur le PCB de  connecteur de type "JTAG" qui permette de programmer la mémoire Flash in situ. D'habitude sur ce genre de carte, il y en a toujours un, qui sert aussi souvent pour le debug et le test "Boundary Scan" (test des liaisons entre composants)
• il y a sur le dessous du PCB cet étrange alignement de points de soudures en dessous du surligné rouge

ou de plus près en haut  à droite de l'image:

Au début je croyais qu'il s'agissait simplement de "jumpers" de configuration. benoar pensais lui qu'il s'agissait du JTAG...

Eh, bien, je pense avoir trouvé la réponse à ces 2 points, en regardant le "Service Manual" et la nomenclature (Section 5.2) : la mémoire Flash utilisée sur la carte est une mémoire Flash NAND, de référence KLM2G1DEFD-A301, de 2Goctets ou 16Gbits,en boîtier BGA. En recherchant un peu sur le Web, je suis tombé sur cette page, qui est la plus technique que j'ai pu trouver sur ce composant :
http://www.samsung.com/global/busi [...] iNAND.html
Il s'agit de mémoire "moviNAND" qui est un composant contenant de la mémoire Flash NAND MLC (Multi-Level Cell) et un contrôleur de mémoire Flash intégré, fournissant une interface de type MultiMediCard ou "MMC"... En gros, il ne s'agit ni plus, ni moins, que d'une sorte de SDCard soudée sur le PCB !

Mais ce qui est intéressant dans le lien sur la page ci-dessus, c'est l'image vers la fin décrivant le brochage du circuit, qui comprend :

• un bus 8 bits DAT[0..7]
• 1 signal d'horloge CLK
• 1 signal de commande CMD
• des alimentations Vccq et Vssq

... soit 10 signaux utiles. Et je vous le donne dans le mille, combien y-a-t-il de points de soudures alignés   ?

Donc, je pense que les 10 points de soudures constituent un port de programmation (interface "MMC" ) de la mémoire Flash initialement montée vierge sur le PCB : ces points de soudures sont alors non présents et il est possible de programmer via une "planche à aiguilles". Une fois la programmation effectuée, les points de soudure sont peuplés et réalisent ainsi la liaison avec le CPU   .

Mystère (presque) résolu: d'après le PPT de présentation, il s'agit d'un port de debug (diapo 11), qui devait être enlevé plus tard    
 
Dommage, il n'y a pas le brochage    
 
Dans la série "Les Mystères du PCB", il reste donc :

• l'utilité du MAX232 et s'il est utilisé pour la console, où sort-il ?
• à quoi sert l'empreinte minuscule "S1" de 2 x 5 broches, non loin de là ?
• à quoi sert l'interrupteur à glissière non monté "SW15", du côté opposé aux boutons de réglage du volume ?

Ah ben je me disais bien qu'il y avait un truc de ce genre, et ça explique le /dev/mmcblk0
 
Merci !

Bon moi j'ai essayé :
- de changer l'image de boot, avec pas trop de succès, mon Tux n'est pas à la bonne taille et il y a un blanc entre chaque ligne , mais au moins on le reconnaît, donc ça progresse...
- de booter avec un kernel 2.6.37 de base, seulement configuré pour prendre en charge le proc et l'écran du E60, sans aucun patch. Ben ça marche pas OK pas vraiment une surprise mais bon fallait essayer quand même
- d'exécuter des binaires debian-armel sur le E60 : ça roule !
 
Donc la bonne nouvelle :

 
Donc voilà on peut faire ça, c'est super simple :  
- installer debian-armel dans une image qemu en suivant les instructions de http://geekboy.fr/geek/installing- [...] -on-a-mac/
- monter le filesystem de l'image qemu sur sa machine
- utiliser mksquashfs pour générer une image squashfs
- la transférer sur le e60
- monter l'image et chrooter dedans pour bénéficier d'un environnement debian complet
 
On peut aussi recopier les binaires et librairies de la debian armel sur le rootfs du firmware pour avoir des softs en plus...
 
Et surtout, ce que je vais essayer de faire maintenant (enfin dans qq jours), c'est de mixer un rootfs debian et le kernel / les drivers blobs binaires du firmware, même si ça risque d'être limité en taille...

Je vous ai dis à quel point c'est cool ce debian sur le firmware ?
 

 
Et oui mpd, fonctionne, moyennant quelques bidouilles, en passant directement par OSS, car esd c'est un peu plus compliqué avec le FS en lecture seule...
 
Bon sinon OSS c'est pas génial, mais heureusement le constructeur du chipset fait de l'opensource et le driver de ce chipset son est intégré depuis le kernel 2.6.31. Je crois que à part la puce wifi (base de bcm43xx ptet?) qui se base sur un blob je crois, le reste me semble soit facilement intégrable dans le kernel par nous de manière un peu plus propre qu'actuellement, ou alors c'est déjà intégré. Je pense qu'on peut arriver à faire un kernel nous même, mais il faut que je comprenne déjà pourquoi mon kernel démarre pas...

Comment changer le volume des enceintes / du casque ?
 
echo reg [register] [value] > /proc/audio_wm8960
 
Ou register peut être :
- 2 : sortie gauche du casque
- 3 : sortie droite du casque
- 40 : enceinte gauche
- 41 : enceinte droite
 
[value] doit être un binaire transformé en décimal, comme ceci :
- bits 0 à 6 : volume, de 48 à 127 (décimal, = -73dB à +6dB), en dessous de 48 c'est considéré comme "mute"
- bit 7 : Left Output Zero Cross Enable, 0 = Change gain immediately, 1 = Change gain on zero cross only
- bit 8 : Output PGA Volume Update Writing a 1 to this bit will cause left and right output volumes to be updated
 
Je n'ai pas trop compris à quoi sert le bit 7, dans mes tests ça change pas grand chose, mais le bit 8 comme c'est expliqué ça update le volume des deux, par exemple :
 
echo 2 90 > /proc/audio_wm8960
 
Là le volume à gauche ne va pas encore changer.
 
echo 3 363 > /proc/audio_wm8960
 
Là le volume des deux voies sera mis à jour.
 
Attention à vos oreilles, le maximum qu'on peut mettre, 127, est bien plus fort que le maximum atteignable par le bouton VolumeUp ! De même je ne suis pas sûr que les petites enceintes le supportent beaucoup, attention donc.

beau boulot

=> console série  

Je n'arrive pas à envoyer un message à traver l'interface webmail du "Samsung Open Source Release Center"
 
Avec 2 OS et 3 navigateurs différents, ça bloque sur le numéro de téléphone avec le message "you can type the numbers only", que j'y mette rien, des nombres de longeur variable, ou autre chose !
 
Si quelqu'un a déjà réussi à envoyer quoi que ce soit, peut-il envoyer le message suivant ?

 
Envoyé. Même message d'erreur (email invalide, et tél. non reconnu), mais ouverture d'une fenêtre avec :
 

 
Ensuite, reçu un accusé de réception de oss.request at samsung point com
 
 

Merci samyb !
 
Il ne reste plus qu'à attendre...

 
 
Je vous tiens au jux.
Mais rien ne s'oppose à une piqûre de rappel : oss.request@samsung.com  

 
Le plus triste c'est que leur toolchiante utilise gcc 4.2.2 et que le Cortex A8 n'était pas encore reconnu par gcc....
 
J'essaye de refaire une toolchain avec les mêmes versions qu'eux mais ce n'est visiblement pas si simple... j'ai du mal.
Sur le principe, je déteste le /usr/local/arm qui n'est pas compatible FHS. Soient ils l'intègrent dans l'arborescence "normale", ce qui semble compliqué vu le mode de diffusion et le contenu, soit ils le packagent dans /opt...
 
Après, si MainApp disparaît, on pourra utiliser un gcc un peu plus récent !

Comics2reader est exactement le type de logiciel que je recherche, mais il plante très souvent chez moi...
Canti, j'avais essayé mais abandonné car je trouvais l'utilisation trop compliquée    
 

Surement, mais je sais me servir de la souris, pas des lignes de commande  
 
 
 
EDIT : quelqu'un connait il un tuto (en Francais ou en Anglais) pour Canti ?

Pas de problèmes pour faire un recovery après le changement de noyau, donc ? (je ne vois pas pourquoi, mais on ne sait jamais)
Je regarderai un peu ce que je peux essayer de faire sur le noyau si j'ai du temps(en même temps depuis que je ne suis plus en coloc, je n'ai même plus de fer à souder, donc je ne pourrai pas brancher de console série /o\ )
 
Il faudrait virer le code de samsung pour la gestion de l'écran, parce que ça existe déjà de base dans le noyau, un framebuffer géré par l'epson, puis il y a surement d'autres trucs pas propre dans le code de samsung.

Cf. mon message dans ce thread :
 

Si on veut pouvoir compiler un noyau qui marche sur le E60, il faut récupérer la "substantifique moelle" des modifs faites par Samsung dans le noyau 2.6.29.4 et les appliquer dans le dernier 2.6.37, en enlevant les cochonneries et les choses qui ont été depuis ré-intégrées ou rajoutées au noyau entre-temps, dont effectivement le driver broadsheet.
 
Si tu le sens bien, tu peux te coller au driver écran ! Déjà, est-ce que l'API entre le driver Samsung E60 et le broadsheet mainstream est compatible ? Si oui, il faut essayer d'annuler les différences entre les 2. Si non, il faut peut-être rajouter l'API Samsung au driver broadsheet, à toi de voir !
 
De mon côté, je pense que je vais essayer de faire le ménage dans le "samsung-e60-kernel-video.patch", qui contient a priori un gros paquet de code récupéré par Samsung à un moment donné, et qui depuis a été intégré au noyau principal, et re-modifié depuis...
 
Moins les "vrais" patches seront importants, plus cela sera facile de comprendre ce qui a été réellement fait et donc de les reporter dans un noyau récent.

Bon, pour me dernier contact avec Samsung HK CR, ça n'a pas été très percutant. Samsung HK CR m'a redirigé vers Samsung FR en leur transférant mon mail, et Samsung FR m'a dit qu'ils ne comprenaient rien à l'anglais - langue d'origine du message adressé avant tout à Samsung HK CR - et qu'il fallait que je prenne contact avec Samsung UK.

En tout cas, bravo à ceux qui avancent sur le E60, je vois qu'il y a des choses sympathiques qui se profilent. Même si j'arrive à suivre sur la direction que tout ça est en train de prendre, je suis complètement largué techniquement pour y participer  

Moi aussi je suis largué, mais j'ai noté une chose dans les échanges précédents :
la dalle EMR (stylet) a une résolution plus importante que l'écran en lui même.

Il sera donc prévu par ceux qui vont développer le driver sans doute un système permettant de ramener la résolution à celle effective de l'écran.

Sauf qu'il pourrait être pas mal dès le début de récupérer l'information en résolution native* de la dalle pour par exemple faire une tablette graphique wifi
*selon la méthode utilisée pour l'appel au driver réponse soit en résolution native, soit en résolution écran

l'idée du message est que l'idée ait été soulevée en amont pour éviter de devoir réécrire du code plus tard

Je vote +1 pour la tablette graphique En plus ça semble gérer la pression.

  Heu, je ne comprends pas pourquoi tu as contacté Samsung HK ?!? Samsung est Sud-Coréen...

Mais non, mais non, c'est justement la bonne occasion pour apprendre !  

Voici un début : le eBook "Programming with Qt 4" (dispo ici) : à mettre d'urgence sur le E60 !!!

En tous cas, l'idée d'un mode lecture stylet "brut" avec la résolution d'origine est excellente, et je confirme : cela gère la pression !

Bonjour,
Je viens d'avoir le E60 Carrefour et j'ai un problème avec la mise à jour du firmware.
J'ai bien téléchargé la version 1.02 : http://downloadcenter.samsung.com/ [...] 1002.0.zip  
renommé le fichier en E60k.bin mais lorsque je déconnecte le E60 et que je vais dans MAJ Micrologiciel il m'indique qu'aucun fichier existe...?

Bienvenue    
 
Veuillez lire attentivement le premier post de ce thread : http://forum.hardware.fr/hfr/gsmgp [...] tm#t604724
 
Et ensuite, les 66 pages qui suivent  

Pour la pression du stylet, ça reste à prouver, moi dans le debug je ne vois qu'un seul niveau de pression renvoyé par le debug du driver, mais peut-être que le driver ne le gère pas vraiment ceci dit, il faudrait voir un peu plus.
 
Pour un mode tablette graphique, oui on peut imaginer ça, simplement en faisant un driver sur le E60 pour qu'il soit reconnu en tablette graphique par le l'ordi sur lequel il est branché (à la place du mode mass storage), en tout cas je ne vois pas d'objection technique. Et ça serait super cool

Bonjour.
 
J'ai un petit problème avec mon E60.
Quand je le branche sur mon pc je n'ai plus la boite de dialogue qui apparait pour activé le transfère de données, mais il se charge bien.
 
Le problème pourrait venir d'où ?

Ça me le fait parfois, débranche, éteint-le et réessaye.

Pour le niveau de pression, cf. l'appli de  test de Maître Yoda:

Pour info, la résolution "brute" est de 6144 x 8192 (ramené à du 600 x 800, soit 10,24 unités de stylet par pixel ), la pression est sur 10 bits (0 à 1023).

 
ça me paraît énorme en fait    
c'est la résolution réelle de la dalle (celle des caractéristiques de la dalle) ? elle sait réellement faire la différence entre un appui sur le point 6000 et 6001 ?

D'après le PowerPoint "Training Manual", diapo 24 (et suivantes), la résolution est de 1700 ppi, soit 1/67 mm  

 
en fait du coup je pense que ça risque d'être "trop" donc il faudra prévoir des résolutions intermédiaires pour que cela soit exploitable  

 
Bon, ça marche ici aussi!
En émulation avec qemu-system-arm,

J'ai installé sur l'image

, fbreader (soyons fous), xdm, et d'autres petits trucs, puis j(ai recréé l'image debian.squashfs avec mksquashfs :

Transféré

sur le E60,
Monté avec  

Chrooté avec

 
J'exécute

et là, rien !
J'exécute

La sortie est :

 
Evidemment, un

m'apprend que la boucle chroot est en lecture seule :

 
Apparemment, la solution serait de monter le système debian en lecture-écriture, mais chroot ne le permet pas, semble-t-il.
 

@bohwaz
J'ai fait cette manipulation une dizaine de fois et toujours pas de message
 
ps : Il est où le bouton pour cité sur ce forum ?

 
SquahFS est par définition en lecture seule, c'est un système de fichier compressé... Il faudrait utiliser une image ext2/vfat plutôt pour pouvoir monter en rw, mais je crois qu'il n'y a plus de périphériques loop dispos, il faudrait en recréer dans le rootfs.
 
Sinon, tu peux très bien fonctionner en ro, voici une astuce :