20 réponses à ce sujet

[littlebalup]

Salut,

Alors voilà. ça fait longtemps que ça me trotte dans la tête. A savoir, seulement flasher la zone "perfirmware" d'une NOR plutôt que de flasher la NOR entière à chaques coups. Un peu sur le modèle du "differential flashing" sur NANDs.
Ceci est beaucoup plus safe étant donnée que l'on ne touche pas aux données "perconsole" si importantes. Je ne vais pas développer, tout le monde comprend bien l’intérêt de la chose.

Je sais depuis longtemps que norway est sensé être capable de flasher a partir d'une adresse donnée (d'un block donné) mais je ne m'étais jamais réellement penché sur la question. Peut être certains d'entre vous utilisent déjà cette fonction. Ci c'est le cas, les témoignages sont bien venus
Pour les heureux possesseur de E3 flasher.... je ne sais pas trop si c'est possible. Je ne connait pas la bête. En tout cas ce serait bien car ce sont eux qui en auraient le plus besoin. Progskeet, je ne sais pas non plus.

Pour ma part j'ai un peu gratté le sujet et je pense bien cerner le truc avec Teensy et norway. Bien que je n'ai encore fait aucun test grandeur réels (j'en suis dans l'incapacité pour le moment pour des raisons personnelles).

Je vous fait donc part ici de la théorie. Et une sorte de tuto "bêta" qu'il faudra néanmoins tester.



Commençons par le commencement. un simple rappel :

Les données perfirmwares sont constituées des TRKs (revokation packages et programs), des ROS (stockage des fichiers du Core OS). Il y a deux zones de chaque utilisés alternativements à chaque update. Ainsi que du vFlash (fichiers systèmes). Le vFlash ne nous concerne pas sur les NOR car il est stocké sur le HDD.

Quand on "patch" notre "dump", on modifie ces données. En fait on les remplace par celles provenant d'un CFW. (Tout du moins les ROS. Pour les TRVK ce n'est indispensable que pour un downgrade 3.55 via FSM. Mais là je m'égare déjà)

Conclusion : la différence entre un dump original est un dump patché ne réside que dans les données perfirmwares contenues dans la NOR. Donc, si on modifie seulement ces données directement dans la NOR, ça revient au même que de dumper la NOR entière, la patcher, et réécrire la NOR entière avec notre dump patché.
Note : bien que l'on puisse écrire directement les données perconsole, il est plus que très vivement conseiller de dumper et vérifier avant. Ne serait-ce que pour s'assurer du bon câblage.

J'espère que jusque là tout le monde est sur la même longueur d'onde.
Entrons maintenant dans le vif du sujet.

Ce que peut faire norway (basé sur la v0.7) :




Traduction :
On peut dire à Norway à partir de quelle adresse, dans la NOR, il doit commencer à écrire (ou effacer, ou vérifier). Par défaut c'est 0x0 (le début de la NOR. logique). Il est aussi indiqué que les adresses doivent être un multiple de 0x20000 (soit 131072 octets, soit 131072/1024 = 128ko. Ce qui représente la taille d'un block. J'y reviendrais plus loin.)

Ceci est un petit peu succin me direz-vous. Et je suis tout à fait d"accord.
Les questions en suspend sont du type:
- Il commence à écrire mais il s’arrête quand? (on a, entre autre, le booldr en fin de NOR et on ne veux pas y toucher)
- On flash en prenant le dump complet pour modèle? Ou un autre type de fichier?

Pour y répondre, il faut farfouiller dans le code de norway pour comprendre comment ça fonctionne. Attention, ça risque de piquer un peu les yeux de certains mais j'ai essayé de traduire en vulgarisant au mieux.
On y trouve donc, pour un "write":


Voilà pour la migraine. Mais si vous ne voulez pas trop vous torturer l'esprit, je résume:
- norway écrit block par block de 128KB (il y a des nuances pour les Samsung K8Q2815UQB mais je ne vais pas entrer dans ces détails inutiles).
- on peut lui demander de commencer à un block particulier en donnant son adresse (un multiple de 128KB, donc un multiple de 0x20000).
- norway écrira la totalité du contenu du fichier (dump), à partir de l'adresse définie, et ne s’arrêtera seulement que quand il aura écrit la totalité des données contenues dans ce fichier (ou jusqu’à ce qu'il arrive à la fin de la NOR...).
- Si la taille du fichier (dump) ne correspond pas à un multiple de la taille d'un block, il tronquera les dernières donnèes (il ne les écrira pas).

Fort de ce constat, il apparait que ce n'est plus un dump complet que l'on doit utiliser pour le write partiel, mais un morceau de dump (ou un assemblage de patch) regroupant les données perfirware que nous voulons écrire. Et pas plus. La taille de ce fichier devra être un multiple exact de 0x20000 (128KB).
 
 
 
Les données perfirmware:
 
Comme dis en préambule, ce sont les TRVKs ROSs. Regardons d'un peu plus près afin de voir si ça rentre dans les clous (adresse et taille d'un multiple de 0x20000):
D’après la bible (wiki), voici les données perfirmware, leur adresse et taille:
 
   Name                  Start Offset      End Offset       Size (h)
 trvk_prg0    0x040000    0x05FFFF   0x20000
 trvk_prg1    0x060000    0x07FFFF   0x20000
 trvk_pkg0    0x080000    0x09FFFF   0x20000
 trvk_pkg1    0x0A0000    0x0BFFFF   0x20000
 ros0         0x0C0000    0x7BFFFF   0x700000
 ros1         0x7C0000    0xEBFFFF   0x700000
 
Première bonne nouvelle, toutes ces données sont contiguës. Donc on peut les écrire en "one shot" à l'aide d'un seul fichier.
Deuxième bonne nouvelle, ces données commencent à une adresse qui est un multiple de 0x20000 ( 0x40000 )
Troisième bonne nouvelle, l'ensemble de ces données est également un multiple de 0x20000:
        0x20000 x 4 + 0x700000 x 2 = 0xE80000  (taille totale des données perfirmware)
        0xE80000 / 0x20000 = 116  (soit 116 blocks complets)
 
Toutes les conditions sont là
A noter que l'on pourrait aussi se contenter des ROSs avec une taille totale de 112 block commençant à l'adresse  0xC0000 (0x20000 x 6).
 
 
Voilà, niveau théorie c'est bordé. Passons à la pratique.
 
 
 
Création d'un fichier (dump) perfirmware:
 
On pourait en créer un de toute pièce à partir des patchs existants mais ce serait un peu pénible et il faudrait renseigner quelque données supplémentaires (ROS headers).
Bref, le plus simple est de partir sur un dump propre patché.
 
Le petit tuto, à l'aide de HxD:
 
- Dumpez votre NOR, vérifiez votre dump et patchez le comme vous avez l'habitude.
 
- Ouvrez votre dump patché avec HxD puis sélectionnez et copiez l'ensemble des données perconsoles (offset 0x40000, taille 0xE80000) :

 

 

 
- Créez un nouveau fichier, collez-y les données puis enregistrez:

 

 

 

 

 
 
C’est tout.
Nous avons désormais nos données perconsoles pour flasher. Un fichier d'une taille de 15204352 octets exactement (0xE80000). Soit 14848Ko ou encore 14,5Mo.
(Notez que les données perfirmware sont 90% du dump complet. On ne gagnera pas grand chose en temps de flash).
Ces données peuvent être flashées sur n'importe quelle console évidemment. Et il n'est pas besoin de refaire la manip pour chaque console temps que vous ne voulez pas changer de type de patch.
 
perfirmware patchés 4.75 no-fsm :  https://www.dropbox....atched.zip?dl=1
perfirmware patché 3.55 FSM :  https://www.dropbox....atched.zip?dl=1
 
C'est partie pour le flash:
 
Donc là, rien de sorcier. C'est un write classique, seulement on utilise le fichier de données perfirmware et l'adresse ou elles doivent être écrites. 0x40000 en l'occurence (ne pas oublier le "0x" devant et ne pas oublier de "0" sinon ça ne sera pas écrit là ou il faut...):

norway.py com6 vwrite perfw475_patched.bin 0x40000

Une fois fait, vous pouvez dumper à nouveau et comparer avec votre dump patché. Ils devraient être strictement identique.
 
 
 
Voici une petite démonstration en video:

Modifié par littlebalup, 03 août 2015 - 21:55.

[acide0]

Tres interressant tout ca !

j attends la suite.

[Red-J]

En gros tu veut juste ecrire ce qu'on patch c'est pas bete et pour le progskeet ya un option flash differentiel de memoire

[h7k3r]

Merci . à tester

[Red-J]

Avant on avait les patchs en separer en.bin dans le dossier de winskeet ou sur le wiki a lepoque 3.55 avec celui du ros0 le ros1 les trvchepukoi ca pourrait etre la bonne base de test little si tu veut un beta tester je suis dispo de dimanche a jeudi par intermitance pour tester si besoin par contre injouable avec un e3 qui write que du full dump et pas d'interface pc avec e3 mais ta methode permettrai d'eviter un nombre de brick incalculable meme si un dump full prealable pour verif du montage est effectivement primordial

Modifié par Red-J, 31 juillet 2015 - 11:32.

[littlebalup]

Avant on avait les patchs en separer en.bin dans le dossier de winskeet ou sur le wiki a lepoque 3.55 avec celui du ros0 le ros1 les trvchepukoi ca pourrait etre la bonne base de test little si tu veut un beta tester je suis dispo de dimanche a jeudi par intermitance pour tester si besoin par contre injouable avec un e3 qui write que du full dump et pas d'interface pc avec e3 mais ta methode permettrai d'eviter un nombre de brick incalculable meme si un dump full prealable pour verif du montage est effectivement primordial

Et un dump après flash pour vérifier que ça a écrit au bon endroit.

[Red-J]

Oui aussi mais ca boot pas tes fixé

Modifié par Red-J, 31 juillet 2015 - 12:28.

[littlebalup]

Voilà la suite. Bonne lecture.

De mon coté j'ai quand même pu tester rapidement. Et ça fonctionne... Je devrais pouvoir faire quelques screens demain.

 

Voici mon fichier perfirmware (patché 4.75 no-fsm + trvk) pour ceux qui voudraient l'utiliser ou comparer : https://www.dropbox....atched.zip?dl=1

Modifié par littlebalup, 31 juillet 2015 - 22:36.

[crash251]

Merci @littlebalup

[littlebalup]

Petite vidéo de démo.

(voir premier post)

Modifié par littlebalup, 01 août 2015 - 17:46.

[Tactik-knife]

Yop.

 

Je confirme les dires de Red-J pour l'E3, vu que nous  n'avons pas d'interface pour le dump ou le write, l'E3 dump tout.

Après pourquoi pas modifier les mises à jour de l'E3, je pense qu'il y aurait quelque chose à faire de ce côté-là mais bon

 

Par contre je ne crois pas t'avoir suivis complètement.

Le but étant de copier seulement les données perfirmware qui ne sont pas vitales et de ne pas toucher aux données perconsole qui elles le sont, ça d'accord.

Comme tu le dis les données perfirmware occupent ~90% de sur les 16M d'une NOR

 

L'avantage serait donc un temp de read/write plus rapide (bien que minim avec une différence de 10%) et + de sureté.

 

Au début de ton tuto tu dis:

 

 

- Dumpez votre NOR, vérifiez votre dump et patchez le comme vous avez l'habitude.

 

Donc au final il faudrait tout de même dumper la flash complète ou je me suis égaré?^^

Modifié par Tactik-knife, 01 août 2015 - 20:21.

[littlebalup]

Yop.

 

Je confirme les dires de Red-J pour l'E3, vu que nous  n'avons pas d'interface pour le dump ou le write, l'E3 dump tout.

Après pourquoi pas modifier les mises à jour de l'E3, je pense qu'il y aurait quelque chose à faire de ce côté-là mais bon

 

Par contre je ne crois pas t'avoir suivis complètement.

Le but étant de copier seulement les données perfirmware qui ne sont pas vitales et de ne pas toucher aux données perconsole qui elles le sont, ça d'accord.

Comme tu le dis les données perfirmware occupent ~90% de sur les 16M d'une NOR

 

L'avantage serait donc un temp de read/write plus rapide (bien que minim avec une différence de 10%) et + de sureté.

 

Au début de ton tuto tu dis:

 

 

Donc au final il faudrait tout de même dumper la flash complète ou je me suis égaré?^^

 

Dans l'absolu ce n'est pas nécessaire mais c'est vivement conseillé, d'une part pour avoir un dump complet de coté mais surtout pour s'assurer que la connexion teensy est bonne (pas d'inversion d'adresse).

Modifié par littlebalup, 01 août 2015 - 22:12.

[Tactik-knife]

Ok je vois, c'est sur que dans tous les cas c'est quand-même conseillé d'avoir un dump de la flash complète et être sure que celui-ci soit bon

[acide0]

Un dump c est assez rapide c est surtout au niveau du write que ca sera pratique mais bon a lire littlebalup on devrat quand même écrire 90% du dump.

Modifié par acide0, 02 août 2015 - 04:27.

[littlebalup]

Je vous ai mis à disposition les perfirware 4.75 no-FSM et perfirmware 3.55 FSM dans le premier post.

Modifié par littlebalup, 02 août 2015 - 14:48.

[crash251]

merci

[littlebalup]

Maintenant je réfléchit sur le comment mettre à jour mes applis (waylaunchers) avec cette nouvelle méthodes. Il y a plusieurs possibilités d'aborder le truc:

 

3 philosophies:

  - écrire depuis un fichier perfw générique (on utilise le même fichier à chaque fois)

  - écrire depuis un fichier perfw extrait du dump patché (on génère le fichier perfw à chaque fois)

  - écrire depuis le dump patché directement  (on charge les données perfw en mémoire directement depuis le dump patché, plus besoin de fichier supplémentaire). Cette solution nécessite une modification du code de NORway.

 

Petit sondage : que préfèreriez-vous?

 

 

Edit:

ça ne m’enchante pas vraiment de changer le code de norway. Mais voici quand même une version modifiée de NORway v0.7 à des fins de test : https://www.dropbox....MOD0.1.zip?dl=1

 

Toutes les fonction de NORway son conservées, plus:

 

Fonctionne avec les commandes "(v)write", "(v)writeword", "(v)writewordubm" et "verify".

A utiliser avec le .hex original de la v0.7.

Modifié par littlebalup, 02 août 2015 - 18:48.

[MisterTea]

 

Après pourquoi pas modifier les mises à jour de l'E3, je pense qu'il y aurait quelque chose à faire de ce côté-là mais bon

 

tu peux pas signer le code pour le fpga.

[littlebalup]

WAY-launchers mis à jour en v2.04 avec ajout option write perfirmware : http://www.psx-place....html#post19786

[Hackstore59]

Très intéressant. Merci pour ton taff l'ami