[Les sources] Bytecode et compilateur

J'avoue ne pas avoir regardé tous les fichiers... je vais voir ça tout de suite...
EDIT: ce fut bref... (un peu comme le nom du fichier).. et j'ai rien compris...

Code:

Dans nbz : vm => bc
Un bc de boot ensuite on passe à un bc nominal

compilateur = simulateur
Lorsqu'on compile bc : le bin + le cpp
.cpp recompilé permet d'obtenir bc de boot

Donc il me faut un .cpp que je recompile... je vais chercher ça...

Dans le meme repertoire il y a une description du langage metal

edit LoL ça pour être bref :d

Mais aucun fichier ne me dit comment crypter le firmware pour lui donner une forme acceptable par le lapin.

Et quand je parle de cryptage... c'est qu'il y en a un, puisque le bootcode sait aussi lire un firmware, et voici comment:

Code:

var firmwarelimit="-violet-";;



fun getbinary bin src i off len=

   if i<len then

   (

      strset bin i (htoi strsub src off 2);

      getbinary bin src i+1 off+2 len

   );;



fun getfirmware req=

   let strstr req firmwarelimit 0 -> i0 in

   if i0!=nil then let i0+8->i0 in

   let htoi strsub req i0 8 -> len in

   let i0+8->i0 in

   let strsub req i0+len 8 -> end in

   if !strcmp end firmwarelimit then

   let strnew len>>1 -> bin in

   (

      Secholn "getbinary";

      setleds 0xff0000;

      getbinary bin req 0 i0 len>>1;

      uncrypt bin 0 nil 0x47 47;

      bin

   );;

On voit clairement le uncrypt(chaine, index, taille, clef, delta) (d'après le SY_nabaztagtagvm_native.xls)
Donc il faut que je crypte mon fichier ... puis que je mette la taille au début, et que j'entoure ca de "-violet-"

Dans la meme veine Hardware.zip\Hardware\Outils\bc-demo

il y a le Hello world du langage metal je pense

edit :

Hardware.zip\Hardware\Outils\SolutionDe¦ümo\readme.txt :
Le fichier php permet de convertir les fichier vasm.mtl en C. ??

J'ai trouvé un fichier mkfirmware.mtl
qui dit dans son entête

Code:

/*
  Used to create a new firmare.

    Place the firmware, renamed in "firmware.sim", next to this script,
    and launch metal vm.
*/

Mais pour l'instant, je ne prend que des "syntax error"

Les syntax error sont "logiques", puisque mkfirmware.mtl utilise une fonction "strnthchar" qui n'existe nulle part (elle n'apparait ni dans les sources du compilateur, ni dans celles du simulateur... ni dans aucune documentation)

Je lance une idée à la con hein, mais on ne pourrait pas avoir un projet github bien refait et documenté ?

Perso je ne pige rien à cette partie là, j'aurais besoin que quelqu'un qui a joué avec fasse un truc un peu clair, avec un readme pour bootstrapper.

Pixel, Funfoo, l'un d'entre vous serait assez sympa ?

(je parle des sources firmware nabaztag hein, je vois qu'il existe déjà une ou deux repos github gouleillantes)

Je n'ai internet que par intermittence en ce moment, donc je ne suis pas trop dispo.
Mais rapidement, pour linux :

Il faut récupérer les sources "hardware" sur le projet google fait par mindscape

Ensuite, il faut prendre tout ce qui correspond au bytecode.

Il faut arriver à compiler le "parser" (pas certain que ca soit obligatoire), et le "mtl_linux"
Ensuite, il suffit de le lancer :
./mtl_linux -s source.mtl firmware.bin
le -s sert à signer le bytecode

J'ai réussi à le faire dans une debian Lenny, avec gcc 4.3.2
Sur une ubuntu trop récente, avec un gcc 4.4 .. ca ne marche pas.

bon courage,

J'espere avoir le net rapidement pour vous aider un peu plus.

Je suis à la recherche du bytecode compilé, la version qui était diffusé par Mindscape. Je ne le trouve pas ni dans les sources ni sur internet.
Quelqu'un aurait-il celui-ci?

Merci!

Pixel a donné un lien pour ça quelquepart

Sinon, il est dispo sur le dépot Git d'OJN (le fichier bootc)

Merci, je ne savais pas si ce fichier était l'os était officiel.

Je vient de retourner sur le blog karotz, y a eu des réponses à certains commentaires, je sais pas si tout le monde a vu.
Du coup ils ont donné un accès SVN aux sources (plutôt que l'adresse vers l'interface Google Code):

http://nabaztag-source-code.googlecode.com/svn/trunk/

Dans tous les cas, la documentation est vraiment maigre... C'est assez impressionnant O_O

ezeta a écrit:

Du coup ils ont donné un accès SVN aux sources (plutôt que l'adresse vers l'interface Google Code):
http://nabaztag-source-code.googlecode.com/svn/trunk/

Et on y gagne quoi de plus ? Sur l'interface google y'a e lien pour pouvoir cloner le dépôt svn ^^
+1 pour les docs.

pour le moment je suis comme vous j'arrive a compiler mais j'obtiens un segfault lors de l'exécution.

Bonjour,

est-ce que quelqu'un travail à faire un document expliquant le principe global de fonctionnement du lapin ?

J'ai compris que
- le code du lapin est fait en Méta Langage, et qu'il existe 2 partie (boot et nominal)
- qu'il y a des outils de simulation pour tester le fonctionnement du code

Ce que je ne sais pas, c'est si ce langage est interprété ou compilé ?
Si le code est chargé en RAM au démarrage ou si il est flashé ?

Quelqu'un a-t-il des réponses à ces points, cela me permettrait de mieux analyser chaque partie.

Merci d'avance.

Lis l'autre topic à ce sujet, ca t'aidera un peu je pense

Mais, non, je ne crois pas que quelqu'un s'amuse à documenter le lapin.

bonjour à tous,

bon comme mon lapin est mort et comme les codes sources ont été diffusés. je me suis penché dessus pour essayer de comprendre mon lapin. Avec tous ce que j'ai pu lire voici une synthèse.

- Le lapin est équipé d'un microprocesseur arm7 avec une rom interne de 128 kb
- dans cette rom interne on vient flasher le bc-boot (flash en wifi à partir du pc distant)
- le bc-boot est programmé en METAL (mtl) puis compilé pour générer un fichier .sim (pour charger le firmware à l'époque de Violet on utilisait un fichier en .sim.txt)
- dans ce bc-boot, il y a la programmation native du wifi, de l'interface de configuration et la requète pour charger le bc-nominal à partir d'un server.
- Ensuite on charge le bc-nominal compilé qui se trouve sur le serveur dans la sram du lapin (512kb*16 =1Mb)
- le bc-nominal contient toute la prog pour le fonctionnement du lapin. dans les codes sources, on trouve chaque fonctions séparés dans le répertoire nominal_splitted


Par contre j'ai une question qui me trotte dans la tête:

Pourquoi avoir créer un langage de programmation spécifique Metal ?

voila n'hésiter pas à me dire si j'ai fait une erreur

Salut,

suite aux réponses faite par "funfoo" sur divers post et surtout sur "Demande d'aide Funfoo - Firmware / ByteCode du lapin", ainsi que mon analyse des codes.

Le "firmware" est développé en langage C (présent dans le projet Projet-IAR), il contient:
- tous les drivers de chaque élément de la carte
- une sorte d'OS (j'ai pas regardé encore de quel type c'est)
- une machine virtuelle exécutant le code Metal compilé (Metal = Méta langage crée par funfoo)
- le "bc-boot" compilé présent sous forme de tableau (fichier bc.c)

Tel que j'ai compris le fonctionnement au démarrage
1° le code en flash est lancé
- il initialise tous les drivers
- il copie le tableau "bc-boot" en RAM (1Mo de disponible au total)
- il lance la machine virtuelle

2° la machine virtuelle exécute le code présent en RAM soit le "bc-boot" (présent à ce moment)

3° le "bc-boot" vérifie si on appui sur le bouton
- si le bouton est appuyé il se met en mode serveur web pour la configuration du lapin
- si non il lance une requête au serveur pour charger en RAM le "nominal.mtl" compilé (à confirmer si c'est le "bc-boot" qui fait cette partie de demande et copie)

4° le nominal s'exécute


L'intérêt d'avoir cette structure (le fonctionnel du lapin est sur un serveur que le lapin doit charger en RAM au démarrage) est de permettre de mettre à jour rapidement les lapins et que les lapins soient dépendant d'un serveur (on ne pouvait pas faire autrement que de passer par les serveurs de Violet).

La machine virtuelle offre l'avantage de gérer la mémoire et donc d'éviter les problèmes. Elle offre aussi une API fixe permettant l'évolution du hardware sans évolution du code "nominal". Le langage C compilé pour l'ARM aurait pu être utilisé mais cela n'apportait pas les garanties de la machine virtuelle et cela complexifiait énormément la mise en place. Donc voila le pourquoi du Metal, à savoir aussi que "funfoo" avait développé ce langage avant de se lancer dans l'aventure du lapin.

Le Metal doit être compilé pour être exécuté sur le lapin. Le compilateur est l'outil du répertoire "Projet-VS" (outil fait sous Visual C++ Studio et donc re-générable sous Windows). La compilation par cet outils d'un fichier ".mtl" (Metal) donne un fichier qui est celui à envoyer au lapin. L'envoie doit se faire par un serveur. Les codes du serveurs sont aussi disponibles.

J'espère avoir répondu à ta question et à d'autres.

Pour ma part, j'ai un lapin V1 et comme les codes fournis (firmware et nominal) correspondent au V2, je désespère de le voir revivre un jour.

PS:Si je me trompe n'hésitez pas à le dire.

Très bon résumé qu'il faudrait mettre en valeur sur un wiki ou ailleurs.

J'aurai rajouté que le langage Metal (mais sans doute pas sa VM) semble avoir évolué dans les dernières versions (cf mtl_linux et le changement de mot-clés).

La V1 est très différente, et utilise une VM qui se programme directement dans un pseudo-assembleur (VASM=Violet Asm), dont les specs avaient été publiées par violet en 2005 ou 2006.
Contrairement à la V2, le réseau est géré par le firmware et non la VM ; on ne peut donc changer ce comportement qui consiste à faire du polling sur le serveur, en http. Le résultat de ce polling est généralement un nouveau bytecode pour la VM (le bytecode est donc mis à jour pour chaque message reçu, contrairement à la V2 où le bytecode est téléchargé généralement uniquement au démarrage).
La dernière version de l'assembleur se trouve visiblement dans le fichier : Server\violet\OS\net\violet\platform\vasm\Vasm.java
et les fichiers Vasm sont à côté.

Chaque bytecode contient le ou les fichiers audio, encodés en une sorte d'adpcm, et non en mp3.
Pour faire une version V1 de nabizdead.net, il faudrait que le serveur traite lui-même les mp3 reçus du TTS, les convertisse en adpcm, et les serve aux lapins. Ca pourrait marcher car il y a peu de lapins V1, mais ça crée quand même une charge importante.

Merci Funfoo pour cette réponse.

La lecture de la doc sur le VASM montre que la machine virtuelle (VM) du V1 ne semble pas prendre en compte la possibilité de reprogrammer le "firmware".

Il reste à voir si le contournement de la machine virtuelle par action directe sur les registres du micro est possible ou non mais je crains que non.

L'autre seul moyen de reprogrammer le "firmware" de la V1 est de passer par une sonde JTAG ce que seul les fondus de programmation de micro possède.

Mon projet de modifier le V1 afin qu'il fonctionne tout seul semble donc très très compromis, surtout que même si j'achète une sonde, la description de la carte électronique du V1 n'est pas disponible et donc un recodage du "firmware" serait très difficile (pas impossible au vu que les codes des drivers du V2 semblent pouvoir être réutilisés).

Bon, je vais continuer à regarder tout ça mais pas longtemps je pense.

Dgi45 a écrit:

L'autre seul moyen de reprogrammer le "firmware" de la V1 est de passer par une sonde JTAG ce que seul les fondus de programmation de micro possède.

Le v1 c'est un PIC18 de chez Microchip il me semble. Donc pas besoin d'une sonde JTAG. Seulement, je ne sais pas si il est reprogrammable c'ui là...

Dgi45 a écrit:

Mon projet de modifier le V1 afin qu'il fonctionne tout seul semble donc très très compromis, surtout que même si j'achète une sonde, la description de la carte électronique du V1 n'est pas disponible et donc un recodage du "firmware" serait très difficile (pas impossible au vu que les codes des drivers du V2 semblent pouvoir être réutilisés).

La carte du v1 est très très simple par rapport à celle du v2. En prenant le temps, j'pense qu'il doit être possible de se faire le schematic à la main.

Après, au niveau prog, on a deux headers en bord de carte. Un 4 pins et un 5 pins. Le 4pins doit être le port série je pense, le 5 celui pour l'ICSP (prog in situ du pic).

J'me suis pas encore penché sur le hardware. Mais si le pic est reprogrammable, c'est qu'une question de temps pour refaire un firmware valable (et exit les VM en cas... plus simple.)

Merci.

Il est vrai que je n'ai pas regardé les entrailles du V1 pensant que le V1 et V2 était très proche l'un de l'autre. Va falloir que je trouve un tournevis à embout triangulaire pour l'ouvrir afin d'avoir les références exactes de chaque composants et me faire une idée de l'architecture de la carte.

hmm ... va falloir que je documente tout ça si je continue

Merci encore.

Dgi45 a écrit:

Il est vrai que je n'ai pas regardé les entrailles du V1 pensant que le V1 et V2 était très proche l'un de l'autre. Va falloir que je trouve un tournevis à embout triangulaire pour l'ouvrir afin d'avoir les références exactes de chaque composants et me faire une idée de l'architecture de la carte.

Prend un tournevis plat ca suffit. T'appuies bien histoire qu'il ripe pas en tournant et ca s'ouvre (pareil sur les v2, mais avec plus de vis :p)

Dgi45 a écrit:

hmm ... va falloir que je documente tout ça si je continue

Si tu documentes, c'est mieux

Merci effectivement avec un tournevis plat ça marche et ... confirmation je suis un idiot , j'ai un V2 et J'avais juste à lire correctement sous le lapin.
Par contre une amie à moi possède bien un V1, il faudrait que je vois ce qu'elle va en faire.

Bon je n'y connais rien dans cette partie mais comme j'ai trouvé ça je le mets la

au cas ou cela aiderai pour les V1 https://www.c3pb.de/_media/wiki/nabaztag/nabaztag-vasm-revb.pdf

Ahah La ref du VASM.

Très utile pour les fonctions de base
Assez mal expliquée pour l'inclusion de fichiers midi
Il lui manque une opcode (non documentée, mais on se doute de son code quand on regarde de près ^^)
Elle ne sert à rien pour les fichiers Wav qui sont à inclure
Elle ne détaille pas les macros utilisées par l'assembleur Violet (et donc, dans les sources fournies par Mindscape)

Sinon, c'est sympa' comme doc' ^^

Merci d'avoir partagé