Nombre de visites sur cette page : 2723 Score au progrank : 38 Note actuelle : 8.5/10 noté 1 fois Vous devez être connecté(e) pour noter (inscription).
Le code source de l'OS de la calculatrice n'est pas ouvert (seul CASIO en dispose), mais on peut lire le binaire pour en comprendre le fonctionnement.
Il y a en particulier les syscalls, des fonctions de l'OS qu'on peut appeler comme une bibliothèque depuis les add-ins, qui sont une mine d'or d'indices sur le fonctionnement du matériel.
(Merci LephenixNoir pour cette explication rapide et claire <3 )
Je vous propose donc Vhex qui est un déassembleur "on-calc" pour SH3 et SH4; On peut se balader dans toute la mémoire Virtuelle (qui fait pas moins de 4 Go) pour essayer de comprendre comment fonctionne la calculatrice ainsi que l'OS de Casio.
C'est un petit projet qui m'aide à retracer les appelle système de Casio qui passe leur temps à chercher des informations dans la RAM (entre autres). Je suis persuadé que cette utilitaire pourra servir quelque personne donc je le mets en public (et sous la licence CC0 (donc faites en ce que vous voulez avec les sources )).
Installation:
Rien de plus simple, prenez vhex.g1a et transférez-le a la racine de la memoire de stockage.
Utilisation:
Vhex est basé sur le principe de fonctionnement de Vim, donc avec des "modes".
Il y a trois modes disponibles:
* UNUSED: la sessions actuelle est vide.
* NORMAL: vous pouvez vous balader dans la mémoire comme bon vous semble.
* COMMAND: Vous pouvez taper des commandes.
Choisir une adresse aléatoire dans 4 Go n'est pas super-intéressant (...fin des fois ) j'ai donc mis à disposition quelque commandes vous permettant d'optimiser vos déplacements:
* systab - saute là où les appelle système sont gérés.
* syscall - saute à l'entrée d'un appelle système (que vous avez choisi).
* vbrjmp - saute au different gestionnaire de Casio (exception, tlb miss, interruption).
* ram - saute au début de la RAM.
* rom - saute au début de la ROM.
* jmp - saute où vous voulez.
* help - Vous donne de l'aide.
Je vous conseille fortement de faire un help ou help <commande> car chaque commande prend un arguments.
J'ai aussi ajouté la notion de session, il y en a 6.
Ça permet d'être à plusieurs endroits "en même temps" ce qui est très pratique.
Les touches utilisées:
* se déplacer: [UP], [DOWN]
* changer de mode: [OPTN].
* afficher des lettres: [SHIFT] + [ALPHA]
* afficher des chiffres: [0 ~ 9].
* changer de session: [F1 ~ F6].
Aide:
Je suis assez mauvais en orthographe, et en formulation (ce qui m'attriste car j'adore écrire) et j'ai encore quelque difficulté en anglais, donc si jamais vous voyez quelque chose de mal expliqué ou mal orthographié (que se sois sur ce poste ou dans Vhex), dites-le-moi.
(Pour vous donner un exemple le code de vhex a été faits en 1 journée mais la documentation sur 1 semaine x_x).
Si vous voulez ajouter des commandes, regarder comment les fichiers ont été construits dans ./src/commands/*.c (où demandez-moi ).
Lephenixnoir, pourrais-tu, si tu as le temps bien sur, vérifier ce que j'ai écrit dans help jmp au niveau de l'organisation de la mémoire virtuelle ?
Yo ! Sympa, avec 6 sessions en plus, on sent que c'est utilisé en vrai ! Waouh ! Ça me donne envie de faire un fxos interactif, c'est pas bon pour ma TODO list...
L'aide de jmp est correcte à quelques inexactitudes près :
* Ce ne sont pas les adresses qui provoquent un crash, mais le fait que les adresses ne sont pas présentes dans le TLB qui provoque une TLB exception, pour laquelle il y a un handler, et celui du système fait des TLB ERROR qui sont les System ERRORs les plus classiques.
* La RAM est mappée en 0x08100000 et non en 0x08000000.
* Il y a un "ebable" au lieu de "enable" au niveau de P3.
* P3 ne contient que des données mappées au cas-par-cas au niveau matériel, typiquement des accès au cache ou au TLB. Il y a la RAM on-chip aussi je crois. Très spécifique et on n'y va jamais, mais pas nécessaire du crash. Comme le MMU est activé aussi, on pourrait y mettre n'importe quoi.
* P4 est plus tordu que ce que tu as représenté.
Ça me donne envie de faire un fxos interactif, c'est pas bon pour ma TODO list...
Tu as déjà fait un kernel modulaire je te rappelle (je suis incroyablement jaloux) x)
D'ailleurs combien de temps t'a pris la refonte de gint ?
La RAM est mappée en 0x08100000 et non en 0x08000000.
Ha oui mince, tu me l'as déjà dit pourtant >_<
P3 ne contient que des données mappées au cas-par-cas au niveau matériel, typiquement des accès au cache ou au TLB. Il y a la RAM on-chip aussi je crois. Très spécifique et on n'y va jamais, mais pas nécessaire du crash. Comme le MMU est activé aussi, on pourrait y mettre n'importe quoi.
Pour ce qui est de la RAM on-chip, je me suis basé sur la documentation du sh7724 et il y est écrit qu'elle est mappée dans P4, me serais-je trompé ?
La TLB est vraiment une des choses que j'ai encore beaucoup de mal à me représenter; si j'ai bien compris c'est un tableau qui contient tous les pages utilisés par le MMU ?
Il me semble que durant le boot de gint que tu force toutes les pages de l'userspace à se charger, pourquoi ? De mon côté je le fais pas et pourtant je ne plante pas.
(Au passage, ce n'est pas ce que fait le syscall hmem_setMMU ?)
P4 est plus tordu que ce que tu as représenté.
Je sais qu'il y a pas mal de registres et qu'il est mappé dans les ressources internes du MPU (?), donc il y a beaucoup de choses sympas dedans, mais je voulais faire au plus simple.
On n'a pas les sources ?
Ils étaient dans "faites en ce que vous voulez avec les sources", mais j'ai changé pour quelque chose de plus explicite
D'ailleurs combien de temps t'a pris la refonte de gint ?
Bientôt fini, mais j'ai pas compté les heures. Il y a des périodes de trou, donc c'est difficile à estimer. La longueur de la branche compat peut te donner une idée éventuellement...
Pour ce qui est de la RAM on-chip, je me suis basé sur la documentation du sh7724 et il y est écrit qu'elle est mappée dans P4, me serais-je trompé ?
La mémoire RS est en P4 (0xfd80*) mais la mémoire IL est en P3 (0xe520*).
La TLB est vraiment une des choses que j'ai encore beaucoup de mal à me représenter; si j'ai bien compris c'est un tableau qui contient tous les pages utilisés par le MMU ?
C'est deux tableaux. Le premier tableau contient les sources, le second les destinations. Essentiellement pour tout i, src[i] est mappé vers dst[i]. (Et c'est pas juste les adresses, y'a plein de paramètres autour. Mais c'est vraiment l'idée.)
Il me semble que durant le boot de gint que tu force toutes les pages de l'userspace à se charger, pourquoi ? De mon côté je le fais pas et pourtant je ne plante pas.
Parce que je ne veux pas toucher au TLB, je considère ça trop risqué. Donc si l'utilisateur accède à une page pas chargée, ça va me faire un TLB error que je voudrai pas résoudre. Tant que le système contrôle les interruptions, ça va. Tant que les pages sont chargées dans le TLB, ça va. J'ai opté pour la deuxième solution.
Soit dit en passant sur la Graph 90+E on ne peut pas mapper tout l'add-in d'un coup (trop gros) donc il me faudra une technique pour commuter vers le système et lui faire mapper la page au vol. Ça risque d'être un peu subtil.
(Au passage, ce n'est pas ce que fait le syscall hmem_setMMU ?)
Il initialise les mappings pour la RAM statique, je crois. Je ne suis pas sûr de connaître tous les détails.
Je sais qu'il y a pas mal de registres et qu'il est mappé dans les ressources internes du MPU (?), donc il y a beaucoup de choses sympas dedans, mais je voulais faire au plus simple.
Yup. Il n'y a quasiment pas de mémoire continue, juste des adresses individuelles avec des tailles d'accès spéciales, donc on pourrait pas trop le visualiser dans ton éditeur.
Ah oui, je suis con, j'ai cherché une archive comme d'habitude !
Nice, je vois que ça tourne avec ton système de boostrap, bien joué
Petite MAJ: j'ai ajouté toutes les instructions du FPU et corrigé quelque bug de clavier.
Nice, je vois que ça tourne avec ton système de boostrap, bien joué
Merci ! mais le "bootstrap" n'en est pas un (pour l'instant); là il se contente de faire le strict minimum (a savoir copier data en RAM et mettre a 0 la section BSS).
D'ailleurs il faudrait que je donne des nouvelles sur le kernel car je l'ai repris de 0 et il est bien mieux organisé et maintenable.
Ceci-dit pour l'instant il est de côté car je suis actuellement en train de réécrire un driver pour le KEYSC (et une documentation) donc ça prend du temps (qui devient de plus en plus précieux ).
Je compte aussi essayer de toucher à l'UBC sous SH4 car j'ai pour idée de réécrire un driver pour le SMEM (et j'ai besoin de suivre les syscalls instructions après instructions pour gagner du temps).
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
A cause du changement de processeur des nouvelles Graph 35+ USB, 75 et 95 SD, de nombreux addins sont incompatibles avec ces calculatrices.
)).
) j'ai donc mis à disposition quelque commandes vous permettant d'optimiser vos déplacements:
).
).