emyway/rt6 Ingénierie inverse du RT6

Bonjour,

 

un effort de décorticage a été réalisé sur les modèles d'autoradio/cafetière précédents, mais je n'ai rien trouvé concernant le RT6. Ce post vise à récapituler l'ensemble des informations que j'ai pu obtenir par ingénierie inverse sur le RT6, dans le but de mieux comprendre l'appareil qui équipe nos véhicules. Je mettrai à jour mon message au fur et à mesure de l'avancement de mes efforts, et selon l'intérêt.

 

Je présente mes résultats sous forme chronologique, sans mettre d'ordre dans les hypothèses.

 

Méthode: Étude du CD d'upgrade firmware 2.20

 

Travaux précédents

 

Le RT6, développé par Magneti Marelli, semble à première vue être assez similaire au RT3, pour lequel un effort de documentation a déjà été fait.

On est en présence d'une plateforme VxWorks 5.5.1 avec Tornado 2.2.1. La carte mère est probablement une WindRiver d'architecture PowerPC. (liste des produits potentiels: http://www.windriver.com/products/bsp_web/bsp_architecture.html?architecture=PowerPC ) La carte est-elle la même que le RT3 ? Je pensais que le RT3 était en MIPS mais http://fr.viadeo.com/fr/profile/cyrille.lohier indique le contraire.

Les binaires semblent être produits avec GCC: (GNU) gcc-2.96 (2.96+ MW/LM) AltiVec VxWorks 5.5.

 

Le RT4 a une architecture très similaire et a été l'objet d'efforts d'ingénierie inverse menés par différentes personnes dont plusieurs ont posté sur ce forum. On notera qu'il existe une version RT6 des "mira scripts", en cours de développement. http://mira308sw.altervista.org/en/index.htm

 

 

Arborescence

 

On trouve sur le CD:

• des fichiers ".inf" (voir ci-dessous, comment on fait un lien interne à un post ?)
  
• des fichiers ".CMD" et ".ini"
  
• des fichiers ".out"
  
• des fichiers ".gz"
  
• ...
  

 

Fichiers .inf

 

Ce sont des fichiers décrivant un binaire, le binaire semble porter le même nom que le fichier mais sans le ".inf" (a.bin.inf décrit le fichier a.bin).

Exemple :

 

Pour obtenir la liste exhaustive des champs utilisés par le firmware :

On trouve :

 

 

1ère ligne : 2 valeurs hexa sur 16 bits chacune (4 caractères). La première valeur est un "CRC" (voir plus bas) du fichier INF lui même. On l'obtient en calculant le CRC sur ce fichier à partir de l'octet n.5 inclus (seek de 4).

La deuxième valeur est un "CRC" (voir plus bas) du fichier binaire correspondant au INF, calculé sur l'intégralité du binaire (compressé s'il est compressé).

 

VER : version du fichier

TYPE : soit "DATA" (données ?) soit "RELOCABLE" (code exécutable)

COMPRESSED : indique si le fichier binaire correspondant est compressé ou non. Le format de compression est DEFLATE tel qu'implémenté par zlib (outil zpipe), avec une petite subtilité au niveau du format (cf. plus bas).

SIZE : taille du fichier tel que stocké (compressé ou non)

USIZE : taille du fichier après décompression (présent uniquement sur les COMPRESSED)

ENTRY: YES ou NO... (aucun idée de ce que c'est, à vérifier)

SUBVER : "sous version" ??

ID: "sous sous version" ??

 

Fichiers .CMD et .ini

 

On dirait que c'est une habitude soit chez MM soit chez WindRiver d'utiliser des extensions pour des types de fichiers qui ne correspondent pas du tout.

Les .CMD et .ini sont... du code C ! Est-ce qu'il est compilé à la volée à l'exécution ? En tout cas ce code contient de nombreux symboles et algorithmes qui permettront de comprendre beaucoup.

 

Fichiers .out

 

Il s'agit d'exécutables.

 

Architecture PowerPC, BigEndian, 32 bit. Désassemblable avec les binutils GNU compilés pour PowerPC... ils ont même laissé les noms des fonctions !

 

Fichiers .gz

 

Ce sont des exécutables comme les .out, mais compressés. Voir plus bas.

 

Bootrom

 

Il semble y avoir un fichier spécial, qui est un exécutable non compressé qui n'est pas ELF. C'est probablement le "bios" de la carte. C'est le fichier Application/Boot/RNEG2010_EUR_2_20/DG4/BOOTROM.DAT. Ce fichier contient un certain nombre de chaînes de caractères intéressantes. Sa version est BSP_PPC-SECT83#BSP_PPC_6.86k1:project:SECT39#1.

C'est probablement du code binaire sans structure particulière, il faudra essayer de le désassembler comme si c'était du code machine brut.

 

BootRom.sym

 

Attention ce fichier n'est pas le même que dans la section précédente. C'est un exécutable PowerPC statique dont les symboles n'ont pas été supprimés : on peut le désassembler pour l'étudier. C'est lui qui semble fournir la majorité des fonctions utilisées dans le firmware, par exemple CheckCRCFile.

 

Hash des fichiers

 

Les fichiers .inf ont au début une valeur qui correspond à un hash "CRC". J'ai essayé plusieurs possibilités - CRC32 avec divers polynômes connus, Adler32, sans succès. La formule de calcul du hash n'est donc pas évidente - mais en lisant le code on se rend compte que c'est un hash sur 16 bits et non 32 bits.

Si on regarde dans le code de BootRom.sym on se rend compte que CheckCRCFile appelle CheckCRCInf (comme ".inf"...) qui le même fait deux appels :

l'un à ReadINFCRC__FPCcR9Crc16Type l'autre à ComputeCRCFile. Le nom bizarre correspond au "mangling" tel que fait par GCC. Cela correspond à la signature : ReadINFCRC(char const *, Crc16Type &)

Donc on est en présence d'un "CRC16".

 

J'ai manuellement recréé le code de calcul du hash à partir du code machine.

Il opère par tranche de 8 bits, avec deux tables de lookup, et des échanges... ce n'est pas un Adler16.

Il peut s'agir d'un algo "maison", dans ce cas le code ci-dessus associé au contenu des tables (que j'ai) permettra de recréer les hash si on veut faire des modifs. Voici un programme Linux (compatible Windows) pour calculer les hashs :

#include 
#include 
#include 
#include 

uint8_t table_h[256] = {
0x00, 0xdf, 0xbe, 0x61,  0x7c, 0xa3, 0xc2, 0x1d,  
0xd3, 0x0c, 0x6d, 0xb2,  0xaf, 0x70, 0x11, 0xce,  0x8d, 0x52, 0x33, 0xec,  0xf1, 0x2e, 0x4f, 0x90,  
0x5e, 0x81, 0xe0, 0x3f,  0x22, 0xfd, 0x9c, 0x43,  0x1a, 0xc5, 0xa4, 0x7b,  0x66, 0xb9, 0xd8, 0x07,  
0xc9, 0x16, 0x77, 0xa8,  0xb5, 0x6a, 0x0b, 0xd4,  0x97, 0x48, 0x29, 0xf6,  0xeb, 0x34, 0x55, 0x8a, 
0x44, 0x9b, 0xfa, 0x25,  0x38, 0xe7, 0x86, 0x59,  0x1f, 0xc0, 0xa1, 0x7e,  0x63, 0xbc, 0xdd, 0x02, 
0xcc, 0x13, 0x72, 0xad,  0xb0, 0x6f, 0x0e, 0xd1,  0x92, 0x4d, 0x2c, 0xf3,  0xee, 0x31, 0x50, 0x8f, 
0x41, 0x9e, 0xff, 0x20,  0x3d, 0xe2, 0x83, 0x5c,  0x05, 0xda, 0xbb, 0x64,  0x79, 0xa6, 0xc7, 0x18, 
0xd6, 0x09, 0x68, 0xb7,  0xaa, 0x75, 0x14, 0xcb,  0x88, 0x57, 0x36, 0xe9,  0xf4, 0x2b, 0x4a, 0x95, 
0x5b, 0x84, 0xe5, 0x3a,  0x27, 0xf8, 0x99, 0x46,  0x15, 0xca, 0xab, 0x74,  0x69, 0xb6, 0xd7, 0x08, 
0xc6, 0x19, 0x78, 0xa7,  0xba, 0x65, 0x04, 0xdb,  0x98, 0x47, 0x26, 0xf9,  0xe4, 0x3b, 0x5a, 0x85, 
0x4b, 0x94, 0xf5, 0x2a,  0x37, 0xe8, 0x89, 0x56,  0x0f, 0xd0, 0xb1, 0x6e,  0x73, 0xac, 0xcd, 0x12, 
0xdc, 0x03, 0x62, 0xbd,  0xa0, 0x7f, 0x1e, 0xc1,  0x82, 0x5d, 0x3c, 0xe3,  0xfe, 0x21, 0x40, 0x9f, 
0x51, 0x8e, 0xef, 0x30,  0x2d, 0xf2, 0x93, 0x4c,  0x0a, 0xd5, 0xb4, 0x6b,  0x76, 0xa9, 0xc8, 0x17, 
0xd9, 0x06, 0x67, 0xb8,  0xa5, 0x7a, 0x1b, 0xc4,  0x87, 0x58, 0x39, 0xe6,  0xfb, 0x24, 0x45, 0x9a, 
0x54, 0x8b, 0xea, 0x35,  0x28, 0xf7, 0x96, 0x49,  0x10, 0xcf, 0xae, 0x71,  0x6c, 0xb3, 0xd2, 0x0d, 
0xc3, 0x1c, 0x7d, 0xa2,  0xbf, 0x60, 0x01, 0xde,  0x9d, 0x42, 0x23, 0xfc,  0xe1, 0x3e, 0x5f, 0x80, 
0x4e, 0x91, 0xf0, 0x2f,  0x32, 0xed, 0x8c, 0x53
};

uint8_t table_l[256] = { 0x00, 0x2b, 0x57, 0x7c,  0xaf, 0x84, 0xf8, 0xd3,  
0xf6, 0xdd, 0xa1, 0x8a,  0x59, 0x72, 0x0e, 0x25,  0x45, 0x6e, 0x12, 0x39,  0xea, 0xc1, 0xbd, 0x96, 
0xb3, 0x98, 0xe4, 0xcf,  0x1c, 0x37, 0x4b, 0x60,  0x8b, 0xa0, 0xdc, 0xf7,  0x24, 0x0f, 0x73, 0x58, 
0x7d, 0x56, 0x2a, 0x01,  0xd2, 0xf9, 0x85, 0xae,  0xce, 0xe5, 0x99, 0xb2,  0x61, 0x4a, 0x36, 0x1d, 
0x38, 0x13, 0x6f, 0x44,  0x97, 0xbc, 0xc0, 0xeb,  0xbe, 0x95, 0xe9, 0xc2,  0x11, 0x3a, 0x46, 0x6d, 
0x48, 0x63, 0x1f, 0x34,  0xe7, 0xcc, 0xb0, 0x9b,  0xfb, 0xd0, 0xac, 0x87,  0x54, 0x7f, 0x03, 0x28, 
0x0d, 0x26, 0x5a, 0x71,  0xa2, 0x89, 0xf5, 0xde,  0x35, 0x1e, 0x62, 0x49,  0x9a, 0xb1, 0xcd, 0xe6, 
0xc3, 0xe8, 0x94, 0xbf,  0x6c, 0x47, 0x3b, 0x10,  0x70, 0x5b, 0x27, 0x0c,  0xdf, 0xf4, 0x88, 0xa3, 
0x86, 0xad, 0xd1, 0xfa,  0x29, 0x02, 0x7e, 0x55,  0xd4, 0xff, 0x83, 0xa8,  0x7b, 0x50, 0x2c, 0x07, 
0x22, 0x09, 0x75, 0x5e,  0x8d, 0xa6, 0xda, 0xf1,  0x91, 0xba, 0xc6, 0xed,  0x3e, 0x15, 0x69, 0x42, 
0x67, 0x4c, 0x30, 0x1b,  0xc8, 0xe3, 0x9f, 0xb4,  0x5f, 0x74, 0x08, 0x23,  0xf0, 0xdb, 0xa7, 0x8c, 
0xa9, 0x82, 0xfe, 0xd5,  0x06, 0x2d, 0x51, 0x7a,  0x1a, 0x31, 0x4d, 0x66,  0xb5, 0x9e, 0xe2, 0xc9, 
0xec, 0xc7, 0xbb, 0x90,  0x43, 0x68, 0x14, 0x3f,  0x6a, 0x41, 0x3d, 0x16,  0xc5, 0xee, 0x92, 0xb9, 
0x9c, 0xb7, 0xcb, 0xe0,  0x33, 0x18, 0x64, 0x4f,  0x2f, 0x04, 0x78, 0x53,  0x80, 0xab, 0xd7, 0xfc, 
0xd9, 0xf2, 0x8e, 0xa5,  0x76, 0x5d, 0x21, 0x0a,  0xe1, 0xca, 0xb6, 0x9d,  0x4e, 0x65, 0x19, 0x32, 
0x17, 0x3c, 0x40, 0x6b,  0xb8, 0x93, 0xef, 0xc4,  0xa4, 0x8f, 0xf3, 0xd8,  0x0b, 0x20, 0x5c, 0x77, 
0x52, 0x79, 0x05, 0x2e,  0xfd, 0xd6, 0xaa, 0x81
};

void crc_16(uint8_t in, uint8_t ptr[2])
{
uint8_t r8, r10, r0, r11;

r10 = ptr[1];
r8 = ptr[0];
r10 ^= in;
r0 = table_h[r10];

r0 ^= r8;
r11 = table_l[r10];

ptr[1] = r0;
ptr[0] = r11;
}
int main(int argc, char **argv)
{
if (argc != 3) {
	fprintf(stderr, "Usage: %s  \n", argv[0]);
	exit(1);
}

FILE *f = fopen(argv[1], "r");
fseek(f, atoi(argv[2]), SEEK_SET);
char buf[4096];
uint8_t crc16[2] = {0, 0};
int sz = 0;
while ((sz = fread(buf, 1, 4096, f))) {
	int i;
	for (i = 0; i 			crc_16(buf[i], crc16);
	}
}

fclose(f);
printf("Computed CRC16 %#.2x %#.2x\n", crc16[1], crc16[0]);

return 0;
}

 

Je ne souhaite pas passer plus de temps sur ce point - je sais maintenant recréer un CRC après avoir modifié un fichier, ce qui me suffit.

 

Exemple sur /mnt/hd/Application/BTL/File_Search.gz.inf - le hash en début de fichier est 0c622f64.

0c62 est le hash du .inf, 2f64 est le hash du binaire, comme on peut le voir :

~/src/RE_RT6$ ./crc_rt6 /mnt/hd/Application/BTL/File_Search.gz.inf 4

Computed CRC16 0x0c 0x62

~/src/RE_RT6$ ./crc_rt6 /mnt/hd/Application/BTL/File_Search.gz 0

Computed CRC16 0x2f 0x64

 

Compression des binaires

 

La plupart des exécutables sont des fichiers .gz compressés. Un peu d'étude du code nous amène à la fonction inflate qui est utilisée pour décompresser ces binaires. Malheureusement cette fonction ne semble pas avoir le comportement standard de la zlib.

Un peu de Google nous mène à http://read.pudn.com/downloads58/sourcecode/embed/205887/src/util/inflateLib.c__.htm tout en bas du fichier, la fonction inflate semble correspondre au code source de celle que j'ai étudiée. Il reste à vérifier en quoi cette fonction diffère de ce que fait la zlib nativement et nous pourrons décompresser (et je l'espère recompresser) les binaires du RT6. Avec décompression + CRC, on pourra commencer à s'amuser à tout casser.

 

J'ai trouvé la solution : VxWorks ajoute un octet de "bourrage" au début de chaque fichier compressé (qui sert pour calculer un checksum, mais uniquement si la variable inflateCksum est définie - 0xff4cf04 dans BootRom.sym qui est l'exécutable principal, et elle ne l'est pas pour l'instant). Cet octet fait que le format n'est pas reconnu par l'outil zpipe inclus dans zlib. Il faut donc faire une petite modification sur zpipe dans main():

 /* do decompression if -d specified */
   else if (argc >= 2 && strcmp(argv[1], "-d") == 0) {
	if (argc == 3) {
		int sz = atoi(argv[2]);
		char buf[sz];
		fread(buf, sz, 1, stdin);
	}
       ret = inf(stdin, stdout);
       if (ret != Z_OK)
           zerr(ret);
       return ret;
   } 

 

Cela permet de passer un "seek" en argument. La valeur de seek à utiliser est 1. On peut ensuite décompresser n'importe quel binaire du RT6 de la manière suivante :

zpipe -d 1  file.bin

 

J'ai fait cela sur tous les binaires compressés du firmware. Pas de surprise, ce sont bien des binaires PowerPC.

 

Question Bluetooth

Je souhaite savoir quelle version du profil Bluetooth AVRCP mon véhicule supporte. Cette information n'est disponible nulle part mais l'étude du module Bluetooth pourra répondre à la question.

On trouve dans Application/BCM/t2bf/bcm_t2bf.bin (note: je nomme .bin les fichiers obtenus par décompression du .gz) les chaînes suivantes :

AVRCP version 1.0 supported

AVRCP version 1.3 supported

AVRCP unknown version

Donc le RT6 supporte la version 1.3 d'AVRCP. Il y a une version 1.4 qui ajoute une fonction recherche et la possibilité de gérer plusieurs "players" (par exemple deux téléphones simultanément pour streamer de la musique). http://en.wikipedia.org/wiki/Bluetooth_profile#Audio.2FVideo_Remote_Control_Profile_.28AVRCP.29

 

sdptool sous Linux liste les profils supportés par un appareil Bluetooth... mais "BT_CAR_SYSTEM" (le RT6) ne répond pas aux requêtes. En tout cas cela m'a permis de détecter la version d'AVRCP sur mon Blackberry et mon YP-P2 - mes deux appareils sont donc en 1.0, donc la voiture ne pourra pas afficher les méta données ni m'indiquer la liste des pistes. Conclusion il vaut mieux brancher ces appareils en USB (sauf que le Blackberry n'est pas accepté par le RT6 en USB, "média illisible", probablement à cause de la table des partitions - en effet le BB expose une table des partitions avec une seule partition, alors que la plupart des clés n'ont pas de table des partitions, à vérifier si c'est effectivement le souci, dans ce cas on serait en présence d'une erreur/oubli de la part de MM).

Je vais faire fonctionner ce script dans la voiture pour vérifier.

 

Upgrade firmware

 

À faire : détails du fonctionnement de l'upgrade firmware. Questions: est-ce qu'on peut ne mettre à jour qu'un seul fichier ? Est-ce qu'on peut faire des changements et revenir en arrière sur une version officielle du firmware ?

 

Le système reconnaît que le média est une mise à jour du firmware à travers la présence d'un fichier CD.inf, et il exécute le binaire /upg/flasher/flasher.rom.

 

Upgrade POI

 

Détails du fonctionnement. Questions : pourquoi est-ce que ça boucle à l'infini chez certaines personnes sans plus d'infos ? Est-ce qu'on peut y faire quelque chose ? RE du format peut-être déjà fait car il existe des POI non-officiels issues de SCDB pour le RT6.

 

Le système reconnaît que le média est une mise à jour des points d'intérêt à travers la présence d'un fichier POI_VER.POI, et il exécute le script upg/poi_upgrade.cmd.

 

Upgrade Carto

 

Détails du fonctionnement. Questions : Est-ce que le format est compréhensible ? Est-ce qu'on peut envisager de mettre à jour les cartes à partir d'Openstreetmap ? Que signifie exactement "mise à jour pas compatible avec les véhicules après août 2011" ?

 

Le système reconnaît que le média est une mise à jour des points d'intérêt à travers la présence d'un fichier CD_VER.NAV, et il exécute le script NAV_UPGRADE.CMD.

 

Besoin d'aide

 

Si vous voulez aider cet effort, et que vous n'êtes pas informaticien, voici quelques idées de choses à faire :

• photographies détaillées de l'extérieur et intérieur du RT6, avec repérage de tous les composants (afin de connaître les caractéristiques du matériel)
  
• plus spécifiquement, déterminer quel médium de stockage est dans le RT6 (disque dur, si oui marque et modèle, flash, si oui amovible ou pas, si oui marque et modèle, ...)
  
• prêt d'un RT6 pour test (non, je veux pas la voiture avec)
  
• prise de contact avec MM pour solliciter le code source ou la documentation (très peu de chances d'aboutir et c'est à double tranchant, réservé à des gens très diplomates)
  
• récupérer d'autres versions du firmware/POI/carto (attention aux aspects légaux) pour me les envoyer
  
• tester pour moi certaines fonctionnalités ("cheat codes" que j'indiquerai, etc.), voire plus selon votre courage
  

Modifié le 24 janvier 2021 par Nicolas

Bonjour,

Et bien bon courage ! C'est un travail compliqué le reverse engineering et peut-être qu'un jour ce travail aidera (entre-autre) à débloquer tout ceux qui sont coincés avec leur RT6 notamment avec la boucle infinie "Chargement en cours" durant les mises à jour...

Pour le dernier point pas beaucoup de chance de réussir car c'est une fonction interne qui bloque

@Sven

 

Vas-y fonce, je trouverais génial de pouvoir "jailbreaker" le RT6 et y mettre enfin des applications dépourvues de gros bugs ...

Bonjour,

j'ai l'intention d'ouvrir mon RT6 pour essayer d'y trouver un point SPDIF ou sortie aux (pensez vous que j'ai une chance?).

J'en profitterai pour faire des photos. avez vous des désidératas particulier?

Cdlt

Bonjour,

 

pour la sortie aux, je n'en ai pas la moindre idée. Je pense que le RT6 intègre directement un amplificateur.

 

Pour les photos : toutes les coutures de l'extérieur comme de l'intérieur. J'aimerais que le marquage des composants soit lisible, pour pouvoir voir numéros de modèle etc.

Mes interrogations : quels systèmes de stockage (disque dur, chip flash, avec marque taille et modèle) sont présents, quel est le format de connexion du système d'input (format du connecteur et type de chip d'interface), idem pour le GPS (antenne et chip) et le bluetooth. Je m'intéresse aussi à la présence éventuelle d'un décodeur MP3/OGG/etc. hardware (donc un chip dédié). Tout cela je peux y répondre en ayant toutes les photos de toutes les puces avec leur marquage.

 

Bien sûr une photo de l'ensemble des connecteurs IN et OUT m'intéresse (qui sait on pourra peut-être y mettre de la vidéo).

 

J'allais oublier : je suis assez frileux vis à vis de mon RT6 car je ne suis pas propriétaire de la voiture. Si tu peux créer un espèce de manuel de démontage pour les nuls, je suis sûr que ca servirait à plein de gens !

Merci

Modifié le 9 août 2012 par sven337

Pas de disque dur dans les RT6

Pour la vidéo, le RT6 intègre (pas toujours ...) le nécessaire pour l'affichage de la vidéo, voir les images données par les caméras sur les DS5.

Pour le reste, je ne réponds pas.

D'après ce que m'a indiqué Mira par mail il y aurait 3 types de stockage dans le RT6.

Une EEPROM flash (bootloader + certains paramètres de config, à ne surtout pas toucher sous peine de briquage), un stockage système persistant (probablement de la flash, de l'ordre de 4Go pour pouvoir stocker la cartographique), et un stockage volatil qui est la RAM.

 

On se fiche bien sûr de la RAM (quoique... je ne sais pas si après avoir débranché la batterie et laissé la RAM se vider on ne doit pas entrer à nouveau le VIN ou je ne sais quel code d'activation dans le RT6 !). Les upgrades d'OS modifient à la fois le bootloader et le stockage système.

Modifié le 10 août 2012 par sven337

Bonjour

 

Sujet trés intéressant que je place en tête de gondole merci pour tes recherches qui feront nul doute avancé les connaissances sur le produit !

 

Je n'ai pour l'instant pas de RT6 à disposition, mais on ne sait jamais ! la prochaine fois j'y penserai.

Le stockage système fait plus de 4 Go pour pouvoir y mettre toute la cartographie européenne.

Pour le reste (RAM et bootloader), ça reste quasi identique aux RT4/5

je me suis attaqué au demontage et vous fais suivre les photos ASAP...

 

je trouve effectivement une carte SD de 8G0. Mais impossible de voir ce qu'il y'a dedans car celle-ci apparait comme "non formatée" dans le PC...

 

les photos sont là: http://dl.free.fr/gcnPJ548Y

une bien belle intégration... malheureusement trop dense pour y trouver les signaux audio sortie auxiliaire avant ampli ou mieux SPDIF...

à moins que ca inspire quelqu'un?

Modifié le 10 août 2012 par alunel

Sauf erreur de ma part, il n'y a pas de sortie SPDIF

Et c'est bien ce que j'avais dit pour la SD

Bonjour

 

Merci pour les photos ! 1er c4 PICASSO du forum avec du RT6 CAN

 

Je me permet pour les autres de les poster ici

 

http://citrotemp.cricou.net/RT6/technique/00 extracteurs.jpg

http://citrotemp.cricou.net/RT6/technique/01 dessus ext.jpg

http://citrotemp.cricou.net/RT6/technique/02 arriere ext.jpg

http://citrotemp.cricou.net/RT6/technique/03 connecteurs.jpg

http://citrotemp.cricou.net/RT6/technique/04 Fakra.jpg

http://citrotemp.cricou.net/RT6/technique/05 Fakra arriere.jpg

http://citrotemp.cricou.net/RT6/technique/06 int lect CD.jpg

http://citrotemp.cricou.net/RT6/technique/07 ventilo et carte SD.jpg

http://citrotemp.cricou.net/RT6/technique/08 dessous carte+2boutons.jpg

http://citrotemp.cricou.net/RT6/technique/09 vue générale carte mere.jpg

http://citrotemp.cricou.net/RT6/technique/10 detail carte mere (SIRF).jpg

http://citrotemp.cricou.net/RT6/technique/11 détail carte mere 2.jpg

http://citrotemp.cricou.net/RT6/technique/12 détail carte mere3.jpg

http://citrotemp.cricou.net/RT6/technique/13 détail carte mere 4.jpg

http://citrotemp.cricou.net/RT6/technique/14 detail carte mere 5.jpg

http://citrotemp.cricou.net/RT6/technique/15 detail carte mere 6.jpg

http://citrotemp.cricou.net/RT6/technique/16 carte fille dessous.jpg

http://citrotemp.cricou.net/RT6/technique/17 carte fille dessus.jpg

http://citrotemp.cricou.net/RT6/technique/18 carte fille dessus2.jpg

http://citrotemp.cricou.net/RT6/technique/19 ampli.jpg

http://citrotemp.cricou.net/RT6/technique/20 ampli extérieur.jpg

 

 

Je constate aussi qu'ils ont implantés un connecteur plat 4 broches de marque hirose en remplacement du 6 voies noir.... connecteur très cher en APV et pas encore trouvé ailleurs....

Très bonne initiative !

J’avais commencé à regarder le contenu du firmware également pour changer le bmp d'accueil par exemple, mais pas eu le temps d'aller plus loin.

 

Si besoin, je peux faire des tests

 

edit: il serait bien de déplacer les photos ou les miniaturisé, car le post devient illisible avec toutes ses grosses photos.

Merci sven pour ce partage très intéressant mais très pointu.

 

Je me permets de te demander de confirmer mon hypothèse que je me suis faite face au problème qu'on rencontre pour mettre à jour les radars.

 

Le problème est que certain RT6 (dont le mien ) accepte la 1er installation de radars qui a la base n'existe pas sur le rt6 et lors de la mise à jour pour remplacer les fichiers présents, cela ne fonctionne plus.

Alors mon hypothèse est qu'il se pourrait que le système copie la 1er fois les fichiers avec un CHMOD des fichiers uniquement en lecture et les fois suivante, le RT6 ne peut plus remplacer ces fichiers à cause de la mauvaise propriété des fichiers comme sur linux ou Mac.

 

Est-ce possible ou vois tu une autre raison plus plausible?

 

Merci d'avance.

Bonjour,

 

désolé d'avoir traîné pour répondre, les vacances...

 

je trouve effectivement une carte SD de 8G0. Mais impossible de voir ce qu'il y'a dedans car celle-ci apparait comme "non formatée" dans le PC...

 

Ça c'est parce que t'es sous Windows, je pense 8Go c'est un peu gros pour envoyer par mail malheureusement, mais j'aimerais vraiment en avoir une copie.

C'est une carte microSD en fait. En 8Go ça coûte une dizaine d'euros sur eBay.

Je vais regarder dans le code si je trouve de quel format il s'agit. EDIT: C'est du TFFS

 

J’avais commencé à regarder le contenu du firmware également pour changer le bmp d'accueil par exemple, mais pas eu le temps d'aller plus loin.

 

Je ne peux plus éditer mon post d'origine (??) donc je réponds ici.

 

Changer l'image d'accueil

 

Le BMP d'accueil est stocké sur le RT6 dans le chemin suivant : /F/Application/Boot/BootScreen.bmp. Il est, comme tous les fichiers du RT6, soumis à une vérification du CRC selon la procédure décrite dans mon message. Ce fichier ne semble pas présent sur le média d'install du firmware 2.20. Je ne sais pas encore où il est stocké.

C'est la fonction BootRomSplash qui le charge (je crois). Elle est appelée avec une valeur entre 0 et 5 qui décrit le type de splash - "please insert upgrade CD", "error detected", etc.

 

Le processus de flash

 

Le stockage

 

On a /F qui est la partition de boot. Probablement du flash, probablement soudé sur la carte mère, peut-être une carte SD, à voir.

ON a /SDC qui est la partition d'application. SDC comme SD Card, je suppose.

 

 

Initialisation

Lors de l'insertion d'un CD d'upgrade du firmware, le système réagit à la présence de CD.inf et exécute FlasherROMStart("/path/to/cd") dans /UPG/Flasher/FLASHER.ROM (indication de Mira non vérifiée). Celui-ci détecte la version de l'appareil et si c'est bien un RNEG il exécute le fichier /UPG/Flasher/FLASHER.ROM.RNEG.

Ici on trouve la fonction FlasherRomRNEGStart(char *sourcedrive) qui appelle GetHardwareConfiguration("CFG_HW_FAMILY") pour vérifier (à nouveau ?!) si c'est bien un RNEG, et écrit la réponse (1) dans deux variables - C_SETUP_HW::m_is_rneg_family et C_SETUP_HW::m_is_sd_present. Ensuite, C_SETUP_HW::m_is_preampli_present et m_is_mtb_present sont renseignés (todo: c'est quoi ? un truc de radio ? il y a une variable mtb_tuner_type... qui prend les valeurs 0 1 2 3).

 

Un affichage de "debug" semble être réalisé par Splash_PrintL1__FPCc (todo: désassembler).

 

Le stockage flash est sur "/F". La partition subit les appels suivants : KernelUnprotectFlash, UnMountPartition, MountAndCheckTffs, BootRomFormatTffs, KernelProtectBoot.

"TFFS" semble donc être le format du FS. http://en.wikipedia.org/wiki/Flash_file_system#TrueFFS sous entend que c'est un FS utilisé par VxWorks, donc c'est une possibilité très nette que ce soit bien notre FS.

 

Vérification du CD

Une fois le FS prêt, c'est la fonction LaunchSoftUpgrade qui prend le relais. Le RT6 utilise la bibliothèque EiC (http://www.linuxbox.com/tiki/node/149 merci à Mira) pour fournir des scripts dont la syntaxe est celle du langage C. EiC va définir un ensemble de fonctions C qui seront appelables depuis les scripts .CMD. La liste exhaustive de ces fonctions est présente ci dessous (indications Mira) TODO les documenter une à une (COUPÉE CAR TROP LONGUE POUR LE FORUM)

Ces fonctions sont exportées à travers EiC en appelant EiC_AddBuiltinFunc(const char *, void *(*func)(void)). (Par exemple, EiC_AddBuiltinFunc("MaFunctionAMoi", &MaFunctionAMoi)). On doit pouvoir en rajouter assez facilement de cette manière, mais Mira a utilisé une autre technique à mon avis plus compliquée.

 

Une fois EiC initialisée, le programme cherche le fichier /UPG/Command/CHECK_CD.CMD ( correspond à l'adresse du "device" contenant la mise à jour, je ne sais pas encore quels sont les points de montage). Ce script est très explicite, écrit par un certain Philippe Chapelet http://fr.linkedin.com/pub/philippe-chapelet/45/834/bb7 avec qui j'apprécierais de discuter en privé. TODO: le commenter (si nécessaire)

 

EiC_ExeFile(argc, argv), CHECK_CMD est appelé avec argv[2]="BOOTROM" (TODO vérifier s'il y a un appel avec "NORMAL" ou une autre valeur, il existe aussi "RECOVERY", voir comment c'est utilisé), les 2 autres arguments sont l'adresse source et le path du script lui même (ce qui est confirmé par le contenu du script).

 

Mise à jour

 

Le script de vérification retourne 0 si tout est OK. Dans ce cas, la mise à jour va avoir lieu. Le programme cherche le script d'upgrade, /UPG/Command/FLASHER.ROM.RNEG.CMD. Ce script est appelé avec les mêmes arguments qu'au-dessus.

C'est lui qui prend en charge l'essentiel du travail.

 

Après la mise à jour

 

Une fonction vérifie le flag g_Flasher_ROMERROR. 0 = pas d'erreur, 3 = message d'erreur + SetDBBootFlagError(), 1 2 4 message d'erreur, en cas d'erreur "emergency reboot".

 

Étude des photos

 

Je m'intéresse ici aux photos d'Alunel.

La puce GPS dans le RT6 est soit une Atmel, soit une SIRF, d'après le code. La photo n°10 nous montre un chip SIRF GSC2Xi, ce qui semble correspondre à leur SIRFStarII. Bien sûr, cette entreprise supprime de son site les anciennes références, et je n'ai pas pu trouver de datasheet.

En tout cas la photo n°10 représente la puce GPS.

 

Sur la photo n°12 et 14 on trouve un microcontrôleur. http://www.datasheetarchive.com/M30290FCTHP-datasheet.html Si on savait à quoi est relié le connecteur noir, on saurait à quoi il sert.

 

Photo n°13 et 15, la "carte son" SAF7741 http://www.nxp.com/documents/leaflet/75016755.pdf associée aux deux tuners TEF 7000 (en petit au dessus). Il faut que je trouve la datasheet du SAF7741, mais j'ai l'impression qu'il n'a que des sorties analogiques vers les HP (donc pas de SPDIF).

 

Photo n°17, un FPGA Altera Cyclone 3 http://www.altera.com/literature/hb/cyc3/cyclone3_handbook.pdf modèle EP3C25 package F324 vitesse A7. Ce FPGA sert très probablement de carte graphique pour piloter l'écran. La technologie utilisée semble être http://www.altera.com/support/examples/nios2/exm-tes-demo.html

Un chip flash 16Mo Spansion http://www.spansion.com/Support/Related%20Product%20Info/S29GL128N_overview.pdf GL128N90FFAR2 voila peut-être notre /F

3 chips Micron marqué 2DF42 D9GPD, probablement de la RAM (en haut pour le FPGA, en bas pour le CPU ?), à vérifier

Un CPU Freescale MPC5200B http://cache.freescale.com/files/32bit/doc/data_sheet/MPC5200.pdf (modèle exact très difficile à connaître, probablement SPC5200CVR400) PowerPC 32 bits 400MHz avec FPU, 16k cache, CAN (?!), USB, Ethernet, ...

 

Alors mon hypothèse est qu'il se pourrait que le système copie la 1er fois les fichiers avec un CHMOD des fichiers uniquement en lecture et les fois suivante, le RT6 ne peut plus remplacer ces fichiers à cause de la mauvaise propriété des fichiers comme sur linux ou Mac.

 

Est-ce possible ou vois tu une autre raison plus plausible?

 

C'est une hypothèse séduisante mais je n'y crois que moyennement (je compte bien étudier la question un jour). Déjà, vu que l'upgrade se fait en root, les droits seront probablement ignorés.

Ensuite, je ne suis pas bien sûr que le FS de stockage interne ne soit pas du VFAT.. je dois continuer à regarder le code ou observer une SD, puisque c'est apparemment une SD.

Enfin, certaines personnes ont indiqué que le problème nécessitait un remplacement du RT6. Je ne sais pas quel niveau de connaissances ils ont sur le hardware, mais ça me donne à penser que c'est un problème plus sérieux. Lequel, je ne sais pas encore.

 

 

Edit: je n'ai pas encore étudié l'upgrade des POI, c'est vrai que le problème se présente pour des POI et pas pour un firmware. D'après Mira, pour les POI, c'est le fichier /UPG/POI_UPGRADE.CMD qui va être lancé. C'est un script parfaitement lisible (y compris pour un débutant, je pense), donc tu peux peut-être l'étudier toi même.

En tout cas les POI sont sur la partition d'application /SDC (à confirmer mais 95% sûr), donc sur la carte SD... donc une hypothèse crédible serait que la carte SD meurt, et que ca ne se manifeste que lors de la prochaine tentative d'écrire dessus (ça s'est déjà vu).

Modifié le 31 août 2012 par sven337

Mtb = motherboard

Rebonjour,

 

Je me permet de remailer ici pour mon probleme de RT6 qui ne s'allume plus avec bruit d'ejection CD, car j'ai acquis la conviction qu'il ne s'agit pas d'une panne matérielle, mais bien d'un plantage, donc cela a un rapport avec son ingénierie interne:

 

Si je met une clé USB contenant le firmware 2.20 (j'esperai que cela lui permettrait peut etre de repartir), l'ecran s'allume, affiche "Check Disc"; malheureusement suivi d'un "error during flasher loading" puis un redémarrage automatique; ce qui ne regle donc en rien mon probleme, mais prouve bien que l'ecran fonctionne et que l'UC tourne et qu'il s'agit semble t'il d'un défaut logiciel et non matériel...

 

La question reste de savoir pourquoi et comment le systeme est arrivé à se corrompre tout seul? d'autant que je ne suis pas le seul puisque NightBird cite exactement le meme pb ayant necessité remplacement... il y'a donc une sensibilité de ce coté là

Pb matériel sur la flash

Etrange le support d'AVRCP 1.3 car les iPhones supportent l'AVRCP 1.4 et mon RT6 n'affiche pas les metadonnées pour autant quand j'écoute de la musique en streaming.

De même, on ne peut pas connecter plusieurs appareils à la fois (le système force la déconnexion du téléphone connecté quand on veut en connecter un nouveau).

Dommage n'avoir un module bluetooth qui supporte des fonctionnalités non exploitées :(

Pas trop de rapport avec le titre de la discussion ...

Et il est tout à fait normal de ne pas pouvoir avoir 2 appareils connectés en même temps

Euh je ne suis pas d'accord... sauf si j'hallucine mais quand je suis avec mon amie, son téléphone fait du streaming audio et le miens est connecté pour la téléphonie. Le tout fonctionne bien !

Etrange le support d'AVRCP 1.3 car les iPhones supportent l'AVRCP 1.4 et mon RT6 n'affiche pas les metadonnées

 

C'est intéressant comme constatation. Je n'ai pas pu vérifier que l'AVRCP 1.3 fonctionne, j'ai simplement vu que le code y faisait référence. On peut en déduire que ça existe dans le RT6, mais c'est dur d'être certain.

 

Est-ce que quelqu'un a déjà réussi à utiliser le RT6 en streaming Bluetooth avec le nom des chansons affiché à l'écran du RT6 ?

 

Euh je ne suis pas d'accord... sauf si j'hallucine mais quand je suis avec mon amie, son téléphone fait du streaming audio et le miens est connecté pour la téléphonie. Le tout fonctionne bien !

 

Cela effectivement va fonctionner car tu utilises deux profils Bluetooth différents. Ce qui est impossible, c'est d'avoir deux appareils en téléphone ou deux appareils en streaming audio en même temps, ce qui est logique.

 

Par contre il y a apparemment quelques soucis avec les iPhone, mais c'est de la faute de l'Iphone (cherche un peu sur le forum, je crois qu'il faut explicitement désactiver le streaming audio, sinon l'iPhone va déconnecter l'autre appareil lors de l'appariement avec le RT6).

Modifié le 17 janvier 2013 par sven337

ok, merci de l'éclaircissement

Par contre il y a apparemment quelques soucis avec les iPhone, mais c'est de la faute de l'Iphone (cherche un peu sur le forum, je crois qu'il faut explicitement désactiver le streaming audio, sinon l'iPhone va déconnecter l'autre appareil lors de l'appariement avec le RT6).

 

Cela serait possible avec l'AVRCP 1.4 en fait.

 

Sinon pour les métadonnées, la doc dit clairement que leur affichage n'est pas pris en charge