Idée de projet - add-in pour debug
Posté le 28/05/2018 20:01
salut;
Je sais pas si vous programmez sur Casio mais si c’est le cas vous devez savoir à quel point programmer dessus c’est pratique: on programme un jeu, on le compile, on vérifie sur l’Émulateur si tout fonctionne, si tout fonctionne on le transfère sur la calto puis on peut transporter son jeu de partout.
Problématique
Si vous programmez un gros jeu il est possible que des petits bugs apparaissent APRÈS avoir compilé qui font planter la Casio.
Et pourtant le jeu fonctionnait sur l’Émulateur sauf que l’Émulateur ne sera jamais comme la console.
Et c’est là que ça devient méga chiant parce que, modifier un octet, compiler, connecter la calto et voir que ça ne fonctionne pas...on vient de perdre 5 minutes de notre vie à brasser de l’aire.
De plus si vos faites des jeux en multijoueur on ne peut pas vérifier via l’Émulateur, il faut donc tout se taper et c’est...long, trop long.
Idée
C’est pourquoi une idée m’est venue alors que j’écrivais la librairie “mySerail.h”.
Pourquoi ne pas créer un add-in qui récupère les données via le port USB puis exécute le jeu à la fin du transfère ?
Pour résumer éviter d’aller dans “LINK”, et attendre que la calto se connecte à l’ordi, attendre que l’add-in soit transféré.
En gros avoir un add-in de debug qui nous permet de ne pas avoir à toucher à la console pour tester ses programmes.
Théorie
Pour ça il nous faut une connexion directe entre la Casio et le PC...bon ya un port USB donc c’est rapide.
L’add-in se met directement en ‘Receive’ (elle attend un fichier).
Ensuite on vérifie s'il y a assez de place dans la RAM.
Si ya assez de place, on met tout le programme dans la RAM, puis on l’exécute.
(c’est tellement simple à dire^^)
Pourquoi la RAM ?
C’est un add-in de debug je vous rappelle donc on s’en fout que le programme soit stocké dans la ROM.
De plus la RAM est rapide à écrire, bien plus rapide que le ROM.
Possible ?
Oui MAIS seulement des petits programmes car la ‘vrai’ RAM disponible sur SH4 est de 12 ko (d’après
la doc de
Lephenixoir) OU 64 ko (d’après le
wiki).
Donc bon...
Oublions 2 secondes la taille de la RAM et le fait qu’il y en est pas autant sur les SH3 que sur le SH4.
1.On sait communiquer via le port USB (exemple :
P7 de
Cakeisalie5), du moins on sait communiquer PC->Casio par contre il me semble pas avoir entendu parler de syscall permettant de jouer avec le port USB (j’ai chercher mais je n'ai rien comprit
).
2.On sait exécuter du code Assembleur depuis la RAM (#sysCall) (
gint fait ça merveilleusement bien aussi <3).
3.On sait faire des interfaces par dégueux.
Donc oui c’est possible !
Es-ce que j’ai commencer a faire un truc ?
Non, déjà parce que j'ai pas beaucoup de temps en ce moment et j’ai déjà plusieurs projets à finir.
C’est juste pour signaler que c’est théoriquement possible donc s'il y a des personnes intéressées par ce projet...bah allez-y ça pourrait être sympa et il y a sûrement beaucoup de choses à apprendre
.
Citer : Posté le 01/03/2019 20:56 | #
N'oublie pas que le code doit être aligné à deux octets (la taille d'une instruction). En pratique, le code est toujours aligné, c'est rarement un problème.
Je crois pas avoir les sources de ces fonctions à part l'archive du 30 Janvier, qui ne semble pas trop correspondre.
0x304f3e c'est aligné pour du code...
Citer : Posté le 01/03/2019 22:11 | # |
Fichier joint
Je crois pas avoir les sources de ces fonctions à part l'archive du 30 Janvier, qui ne semble pas trop correspondre.
J'ai mis en fichier joint mes sources
N'oublie pas que le code doit être aligné à deux octets (la taille d'une instruction). En pratique, le code est toujours aligné, c'est rarement un problème.
Ha ! Mais oui je suis con...
Citer : Posté le 01/03/2019 22:49 | #
Ça a l'air compliqué. Est-ce que tu es sûr que la va_list marche et que c'est bien cet appel exact qui plante ?
Citer : Posté le 02/03/2019 11:29 | #
Est-ce que tu es sûr que la va_list() marche et que c'est bien cet appel exact qui plante ?
stdarg.h fonctionne parfaitement et si j'affiche ce que me renvoie va_arg() tout est bon donc ça ne viens pas de là :/
vfprintf_print_arg() plante à tous les coups et si je le mets en commentaire vfprintf() ne plante pas...
Citer : Posté le 02/03/2019 12:04 | #
Je ne vois pas de problème évident... tu peux toujours regarder le code assembleur, et pour éliminer les situations où une recompilation partielle te laisse dans un état inconsistent, renommer la fonction et tout recompiler.
Citer : Posté le 02/03/2019 12:58 | #
En fait le problème est encore plus bizarre que ça... o__o vfprintf() marche si je retire 1 fonction (n'importe laquelle)...bon...je vais tout réécrire à partir de 0 parce que la je suis vraiment perdu x)
Ajouté le 02/03/2019 à 16:55 :
J'ai refait un printf() et tout refonctionne
Je peux enfin passer au FS
Au passage j'en profite pour montrer l'avancement du projet via une vidéo
Citer : Posté le 02/03/2019 16:58 | #
Comment le système de fichiers de la mémoire de stockage est fait, je n'en ai pas la moindre idée. Ça doit être documenté par SimLo, je sais que Kristaba avait un driver pour sa Graph 85, mais lecture seule - et c'est déjà le bordel.
Personnellement j'utiliserais Bfile, mais... fais comme tu préfères.
Jolie vidéo ! Le shell est vraiment sympa.
Citer : Posté le 05/03/2019 21:15 | #
Comment le système de fichiers de la mémoire de stockage est fait, je n'en ai pas la moindre idée. Ça doit être documenté par SimLo, je sais que Kristaba avait un driver pour sa Graph 85, mais lecture seule - et c'est déjà le bordel.
Ha mais non je parlais pas de ça, je parlais d'un File System en RAM pour commencer à voir un programme qui ressemble à peu près de kernel. (avoir une console, un tty, etc...). J'ai commencé à faire quelque petite chose, regarder du côté de Fixos et lire des cours sur le FS d'Unix. J'ai peur d'avoir mal compris alors j'aimerait que tu m'aides au niveau de la "logique".
De ce que j'ai compris la structure du fichier en tant que tel ne contient pas grand-chose à part son nom, ses flags et un pointeur vers une inode. L'inode contient tout ce qui est important (en plus contenue du fichier) comme les fonctions d'ouverture, écriture, lecture et son type (dossier, fichier normal, ...). Il ne doit absolument pas être toucher par l'utilisateur...et je n'en sais pas plus...Du coup un FS est une liste chainée ? un arbre binaire ? Je n'arrive pas à comprendre comment son stockés les fichiers et ses informations... (je sais que c'est la base mais j'aimerai ne pas faire n'importe quoi en therme de structure et de convention...).
J'ai aussi lu (et Kristaba faisait pareil) que le FS doit être "monté" je dois avouer n'avoir pas bien compris son intérêt. Comme Kristaba monte son FS (celui RAM) et celui de Casio (en ROM) je suppose que cela sert à dire "La ya de la mémoire et des fichiers" (?) Quand un fichier est "monté" a-t-il une inode différente ou il garde la même ? (où il en a 2 ?)
De plus Kristaba différencie bien son FS de son VFS (et là je vois pas la différence
Ha oui, du coup j'en profite, c'est quoi les opérations atomiques ? (il me semble que c'est des types utiliser par les FS...(?)).
Citer : Posté le 06/03/2019 21:07 | #
Aha ! Je m'incline. Très bonne idée ça (par contre je te préviens je n'y connais pas grand-chose non plus !).
Pour ce que j'en sais, oui, toutes les informations importantes sont sur l'inode, ça c'est bon. Le FS lui-même est un arbre (pas forcément binaire) dans lequel les noeuds sont des répertoires, comme tu pourrais t'y attendre. Attention, si tu as des liens (symboliques ou pas), l'arbre devient un graphe donc il faut faire attention à tout un tas de choses en plus. (Si tu ne vois pas pourquoi pose-le au papier.)
Dans le jargon Linux, tu as ton système de fichiers principal qui commence à la racine / (souvent sur une partition, mais là ce sera dans la RAM pour toi) et tu peux "monter" d'autres systèmes de fichiers dedans. Par exemple si je branche mon disque dur en USB, il a 4 partitions, ce qui fait 4 systèmes de ficheirs en plus. L'opération de montage consiste à les attacher quelque part dans l'arbre principal (visualise ça comme un sous-arbre installé sur une feuille, si tu es familier avec ces choses-là). Ainsi Kristaba pouvait monter la mémoire de stockage dans son système racine en RAM pour y accéder.
Pour les opérations atomiques, je ne connais pas les détails. La notion générale est "une opération qui ne peut pas être interrompue pendant qu'elle se déroule". En gros elle se déroule trop vite pour que quelque chose se passe au milieu, ou alors les sources d'interruption potentielles sont ignorées ou désactivées jusqu'à ce qu'elle soit finie. Pour un système de fichiers il y a des questions importantes et non triviales comme maintenir la cohérence du système si une écriture se fait interrompre. Par exemple, tu as peut-être besoin que tes écritures sur les inodes soient atomiques.
Citer : Posté le 17/03/2019 18:04 | #
J'ai un peu avancé sur le kernel et voila ce que j'ai fait depuis la dernière fois:
* Mise en place du File Systeme en RAM.
* J'ai réécrit mon gestionnaire d'exception (en assembleur) qui me permet de gérer l'instruction TRAPA.
* Mise en place de 3 syscalls (pour l'instant): sys_write(), sys_stat(), sys_chdir().
* J'ai implémenté une petite partie de dirent.h et stat.h.
* Gestion de l'environement.
* J'ai écrit une petite dizaine de builtins: ls, cd, date, env, setenv, unsetenv et d'autre truc pour m'aider à débuger.
* J'ai sécurisé quelque endroit critique du boot. (Notamment le fait de checker le mpu avant d'entamer la phase de boot et de le bloquer si la calculatrice est autre chose qu'une SH4).
Voilà c'est à peu près tout ce que j'ai pu faire sur mon temps libre.Maintenant j'aimerais entamer la gestion des processus car je sais d'avance que ça va me prendre du temps et que, potentiellement, ça va me demander de changer l'architecture actuelle du code. Je me laisse encore une petite semaine pour sécuriser et corriger les fautes à droite à gauche (il y a une fuite de mémoire avec l'environnement et le FS n'est pas détruit quand je rends la main à Casio (d'ailleurs je suis surpris qu'elle ne plante pas à ce niveau la
J'ai une vague idée de comment implementer les différents processus. Je vais utiliser un timer et à chaque interruption je sauvegarde...tout ce qu'utilise le processus actuel (ouais il me manque les infos les plus importantes), puis je passe au processus suivant, je restaure ce que j'avais save sur ce "nouveau" processus, et ainsi de suite (donc je vais partir sur du Round-Robin
Je comptais lire la doc cette semaine mais comme je me suis déjà fait avoir avec le clavier je préfère demander avant: la doc (la section du MMU) est-elle bonne ? les addresses sont-elles bonne aussi ? (visiblement TEA, TRA, EXVT, etc. ont l'air d'être les même donc les autres registres du MMU aussi ?). L'ASID est-il présent sur le sh7305 ? Car ça me faciliterait bien la vie (de ce que j'ai zyeuté). Je sais que Kristaba ne l'avait pas trouvé, il faut que je regarde ce qu'il a fait pour pallier a ce manque. (au cas ou).
Pour l'instant je compte rien tester avant d'être sur à 100% de ce que je fais et que tout sois sécurisés. J'espère vraiment que le MMU est mieux documenté que le clavier car je n'ai vraiment pas envie de passer des mois à dé-assembler (GetKey() ?) l'OS de Casio. >_<
Si ça intéresse quelqu'un je pourrais donner un G1A (et les sources), une fois le code sera sécurisé (je vous préviens il n'y a pas grand-chose à voir)
(ça me fait penser qu'il faut que je trouve une licence pour ce projet, et je n'y connaît connaît absolument rien... >_<' ).
Citer : Posté le 17/03/2019 18:07 | #
Très bien ! Tu dois sauvegarder l'état des registres et de la mémoire. Essentiellement, tout ce qui est géré par le processus lui-même.
Note : en principe tu devrais charger dynamiquement les exécutables en mémoire et mapper avec le MMU, mais je te déconseille fortement de toucher au MMU sous risque de bricker ta machine. Si tu veux l'éviter tu vas devoir bricoler à mort. >_>
L'ASID est présent bien sûr, mais s'il n'est pas activé par le système par défaut tu ne devrais peut-être pas le faire.
Citer : Posté le 17/03/2019 21:39 | #
Très bien ! Tu dois sauvegarder l'état des registres et de la mémoire. Essentiellement, tout ce qui est géré par le processus lui-même.
Si j'ai bien compris (je n'ai toujours pas lu la doc) il faudrait que je sauvegarde, en plus de tous les registres, toutes les pages du TLB ? (si j'ai bien compris l'intérêt du TLB, c'est une sorte de grande liste qui répertorie les pages d'addresses virtuel vers les addresses physique d'un processus ?). Du coup il va valoir que je simule l'ASID ? ça me semble possible si la TLB est bien documentée...mais je vais être obligé de récupérer la configuration du MMU (au mois pour savoir la taille des pages), ça me semble pas trop risqué de lui lire les registres non ?
Dans la même lignée, si je me plante dans la TLB la calto devrai pas entierement casser ? (dans ce que j'ai compris non vu qu'elle est en RAM (?)). Et quand j'aurai un nouveau processus il va valoir que je crée de nouvelles pages ? Sans toucher au MMU ? ...je n'ai pas encore bien compris la TLB et ce que c'est réellement, mais je pense que c'est jouable (encore une fois je n'ai pas lu la doc)
Il me semble que gint debug la TLB, tu pourrais m'en dire plus ? : sry:
Citer : Posté le 17/03/2019 21:50 | #
Le TLB contient la liste des mappings des espaces virtuels vers la mémoire physique. À cause de l'ASID, deux processus différents ne peuvent pas avoir les mêmes mappings, mais si je me souviens bien le TLB ne spécifie pas l'ASID (c'est toujours l'ASID courant qui est utilisé). Donc oui, en principe il faudrait que tu sauvegardes puis restaures tous les mappings. Mais en principe tu utilises l'ASID, le simuler c'est pas très fun, pas très intéressant et pas très sécurisé.
gint est capable d'afficher les contenus du TLB mais pas de les lire. Pour faire simple :
* Modifier les paramètres du MMU et quitter l'add-in/crasher sans les restaurer peut bricker définitivement la calto.
* Le risque pris en modifiant le TLB n'est pas connu, mais SimLo le déconseille inconditionnellement (et moi aussi).
En gros tu ne peux quasiment rien faire avec le MMU et le TLB si tu ne veux pas risquer de casser le système. Ça veut dire que tu ne peux pas implémenter une gestion multi-processus évoluée.
La seule solution dont tu disposes, c'est de tout mettre dans la zone de RAM de 256k supplémentaire, de façon continue, et de ne pas utiliser le MMU (qui de toute façon est inactif dans l'espace P1).
Citer : Posté le 17/03/2019 22:12 | #
Modifier les paramètres du MMU et quitter l'add-in/crasher sans les restaurer peut bricker définitivement la calto.
Dans ce cas comment faisait Kristaba pour le multiprocessus ? Car son kernel ne rendait pas la main à Casio par la suite (?)
Donc oui, en principe il faudrait que tu sauvegardes puis restaures tous les mappings. Mais en principe tu utilises l'ASID, le simuler c'est pas très fun, pas très intéressant et pas très sécurisé.
[...]
La seule solution dont tu disposes, c'est de tout mettre dans la zone de RAM de 256k supplémentaire, de façon continue, et de ne pas utiliser le MMU (qui de toute façon est inactif dans l'espace P1).
Comment ça "tout mettre dans P1" ? Si je ne peux même pas lire le TLB, qu'est-ce que je peux y mettre ? Le code de chaque processus, puis passer de l'un a l'autre ? Dans ce cas il me faut un loader ELF...
gint est capable d'afficher les contenus du TLB mais pas de les lire
Mais...pour afficher tu es bien obligé de lire non ?
Citer : Posté le 17/03/2019 22:18 | #
Dans ce cas comment faisait Kristaba pour le multiprocessus ? Car son kernel ne rendait pas la main à Casio par la suite (?)
Je sais que le kernel était entièrement en RAM, mais j'ignore comment il faisait sur ce point. Si tu trouves des informations je peux t'aider à déchiffrer le fonctionnement interne.
Tu ne peux rien mettre dans le TLB. Au mieux tu peux utiliser une zone de RAM qui n'est pas gérée par le MMU et de débrouiller vaguement pour que les espaces restent continus... en compilant tout en PIE... c'est pas gagné. >_>
Pardon, gint sait les afficher mais pas les écrire.
Citer : Posté le 17/03/2019 22:36 | #
Tu ne peux rien mettre dans le TLB. Au mieux tu peux utiliser une zone de RAM qui n'est pas gérée par le MMU et de débrouiller vaguement pour que les espaces restent continus... en compilant tout en PIE... c'est pas gagné. >_>
Alors je n'ai aucune idée de ce que signifie PIE, et encore moins de ce que je dois mettre dans cette zone. Car si je peux rien mettre dans le TLB alors sauvegarder ce qu'il y a dedans me sert pas à grand-chose...
J'ai un doute, tu me parles biens de là où vont resider les future "processus" (?) si c'est ça alors je vois quoi mettre dans cette zone: tout le code de chaque "programme". Je me contenterais de les "mapper" tout seul comme un grand et du coup je n'aurais pas besoin du MMU et du TLB
Citer : Posté le 17/03/2019 22:40 | #
PIE = Position Independent Executable (je pense qu'il avait PIC en tête), en gros toutes les adresses sont en relatif et tu peux lancer le code peu importe sa position il me semble
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 18/03/2019 11:57 | #
PIE = Position Independent Executable (je pense qu'il avait PIC en tête), en gros toutes les adresses sont en relatif et tu peux lancer le code peu importe sa position il me semble
Ha mais je ne savais pas que ça existait ça ! ça va m'être tres utile si je ne dois pas passer par le MMU
J'ai regardé ce que a fait Kristaba, il setup le MMU de cette façons:
* MMUCR.SV = 0 (Il met le MMU en Multiple virtual memory mode).
* MMUCR.TF = 1 (Il demande de clear la configuration actuelle des registres UTLB / ITLB, sur sh7724 ce bit est renomé TF (TLB Flush -> TLB Invalidate bits))
* MMUCR.IX = 0 (Il demande un index pour la TLB, ce bit n'est pas present sur sh7724).
* MMICR.AT = 1 (il active le MMU).
Pour ce qui concerne l'ASID il le simule, de ce que j'ai lu.
Et si son kernel arrive en fin de tache, il boucle en attendant un reset de la part de l'utilisateur, et il ne remet rien à sa place.
Comme il ne touche ni à l'ASID, ni à la taille des pages, c'est surement ce qui lui a permis de ne pas bricker sa calto. Je ne vais pas le faire, mais je suis tenté d'essayer de lire les registres du MMU, histoire de voir comment il est configurer (et voir si les address son bonne).
Je ne vois vraiment pas comment faire du multiprocessus sans passer par le MMU.... :/
Citer : Posté le 18/03/2019 12:03 | #
PIE = Position Independent Executable (je pense qu'il avait PIC en tête), en gros toutes les adresses sont en relatif et tu peux lancer le code peu importe sa position il me semble
Oui, c'est précisément ce dont je parlais.
Okay, Kristaba fait des choses que je juge "dangereuses" à un certain point. C'est à toi de voir si tu testes ou pas ; en tous cas si tu le fais, assures-toi toujours, toujours, toujours de restaurer les paramètres du système à la fin de l'add-in. Renseigne-toi à l'avance sur les registres qui ne sont pas réinitialisés par un crash ou un reset pour avoir la certitude que tu ne casseras pas le système. L'idée générale est que si les paramètres du MMU ont changé au moment du boot, le système risque de ne plus démarrer. (Tu peux demander des détails sur ce que AHelper a fait pour casser une Prizm comme ça ; il cherchait à faire des libs partagées.)
Le mode multiple signifie que les ASIDs sont utilisés.
Lire dans le MMU c'est safe, tu peux toujours regarder le code de gint si ça t'amuse.
Je pense que tu as besoin de lire un bout de livre sur les systèmes d'exploitations pour avoir une meilleure idée de comment ça marche, plusieurs points importants m'ont l'air encore assez obscurs dans ton discours.
Citer : Posté le 19/03/2019 16:07 | #
J'ai essayé de reprendre de 0, histoire de bien comprendre comment fonctionne la mémoire, mais je ne suis pas sur d'avoir bien saisi ce que représente la mémoire virtuelle.
La mémoire virtuelle et définie par la taille du processeur, pour la calto c'est un MPU 32bits ce qui lui permet d'adresser de 0x00000000 à 0xffffffff (sois une mémoire virtuelle de 4Go).
Cette mémoire est "découpée" permettant de communiquer avec des modules autour du MPU (RTC, TMU, écran, KEYSC, etc...).
Cependant je ne comprends pas comment elle est organisée, en fait, pour être exact, je n'arrive pas à saisir ce que représentente les zones P0, P1, P2, P3 et P4
L'addresses des modules autour du MPU commence par 0xa donc ils se trouvent dans la zone P2 ?
Les zones cachable (a savoir P0, P1, P3) signifie qu'on peut lire et ecrire dedans ?
La zone P0 commence a 0x00000000 mais pourtant la RAM démarre a 0x08100000, pourquoi ?
La zone P4 contient...des registres ? (TEA, TRA, EXEVT, INTEVT, etc...) ?
La zone de 256ko dont tu me parlais est la zone P3 ? Pourtant elle fait ((0xe00000000 - 0xc0000000) / 1024) 524 288ko ... je ... je ... comprends pas...en fait je me rends compte que je ne sais absolument rien sur la mémoire
Désolé de poser plein de questions, mais j'en ai vraiment besoin, je suis dans le noir complet en ce moment...
Sinon j'ai réussi à supprimer la fuite de mémoire, sécurisé le boot et (enfin) je détruis proprement mon FS avant de rendre la main à Casio.
La séparation entre le noyau et le shell n'est pas super propre / visible à des endroits mais tant que je n'aurais pas trouvé un moyens de loader des programmes (et d'avoir compris le fonctionnement de la mémoire) je refuse d'y toucher.
Dans un premier temps, (une fois que j'aurais bien compris la mémoire,) je vais faire un loader de fichier ELF, histoire de bien séparer mon programme en 3 parties:
* le bootstrap
* le kernel
* le shell
Ce qui me donnera 3 fichiers à la compilation: un G1A (bootstap) et deux fichiers ELF (shell, kernel).
Si j'arrive à charger des programmes dans P3 (si c'est bien de cette zone dont tu me parles), je pourrais commencer le multiprocessus avec quelques problèmes en moins car les "programmes" pourront être chargé et isolé entre eux (?)(même si je ne sais pas trop comment mis prendre encore).
Au vu des questions que je viens de demander, tu as incroyablement raison. xD
Tu n'aurais pas quelques bocquins à me recommander pour un néophyte comme moi ? (Tu m'as montré l'auteur Andrew S. Tanenbaum, mais je préfère reposer la question histoire de me souvenir des noms
Citer : Posté le 19/03/2019 17:19 | #
La mémoire virtuelle est une interface avec tout un paquet de hardware, notamment la RAM physique, la ROM, et les modules périphériques. Il y a des adresses virtuelles qui pointent vers chacune de ces régions.
La séparation est arbitraire. Elle existe car selon les moments on veut utiliser des zones de mémoire avec des propriétés différentes.
* P0 est la seule zone accessible en mode utilisateur (le contraire du mode privilégié du processeur). Dans un vrai OS, les programmes tournent en mode utilisateur et ne peuvent donc utiliser que des adresses dans la première moitié de l'espace. Cette partie peut être gérée par le MMU, ce qui permet au kernel de charger les exécutables en mémoire et tout ça.
* P1 et P2 sont deux zones où le MMU n'est pas actif, ce qui en font des fenêtres directes sur la mémoire physique. Dans le MPU que l'on utilise, les adresses physiques font 29 bits donc l'adresse physique associée à une adresse virtuelle est obtenue en effaçant les 3 bits du haut. Tu remarques donc que P1 et P2 pointent vers la même mémoire (au début de l'espace il y a la ROM, plus loin il y a la RAM). Toutefois P1 et P2 n'ont pas les mêmes paramètres de cache, l'une des zones peut exploiter le cache tandis que l'autre non.
* P3 est quasiment inutilisé pour nous, de mémoire il n'y a que la RAM on-chip qui est mappée ici (en dur, pas par le MMU).
* P4 est un espace un peu fourre-tout dont les adresses sont mappées individuellement vers les modules périphériques.
Oui, mais pas tous les modules sont là, un certain nombre est dans P4.
Non, ça signifie que le cache est actif (le cache étant cet intermédiaire entre le processeur et la mémoire, qui est plus petit et plus près du CPU que la RAM et donc plus rapide, et qui essaie de prévoir ce que le processeur va utiliser pour le charger en avance et limiter les interactions avec la RAM). Cela dit il n'y a pas de cache sur SH3 à ma connaissance (remplacé par la on-chip RAM) et sur SH4 je n'ai jamais trop su s'il y en avait un non plus.
La zone P0 est une zone entièrement gérée par le MMU, on peut donc la remplir comme on veut. On peut met l'add-in à 0x00300200 mais n'importe quelle autre adresse marcherait aussi. Pour la RAM, c'est pareil.
En l'occurrence cette RAM est dans P0 parce que l'OS fait les choses à peu près correctement : en principe l'add-in devrait tourner sur le mode utilisateur du processeur, ce qui lui interdit d'accéder à la partie haute de la mémoire, il n'a accès qu'à P0. Et donc l'OS mappe la partie appropriée de la ROM et la RAM statique quelque part dans P0, pour que l'add-in puisse y accéder. (En réalité l'add-in tourne en mode privilégié, mais ça c'est parce qu'ils font n'importe quoi...)
Quand tu comprendras un peu mieux, interroge-toi sur la question suivante : puisque ton add-in est mappé par le système, peux-tu facilement mapper tes propres processus dans P0 sans risquer des interférences ?
La zone P4 est un petit bordel et il y a des fils dans le processeur qui interceptent les accès à l'adresse 0xff000020 pour les renvoyer vers le registre TRA. C'est des adresses affectées au cas-par-cas. Ce n'est pas de la "mémoire" au sens RAM, c'est juste une adresse virtuelle envoyée vers un registre.
Nope, c'est pas vraiment ça. La ROM et la RAM sont situées aux adresses physiques 0x00000000 et 0x08000000, respectivement. Ça veut dire que tu peux y accéder de plusieurs façons :
* En utilisant une adresse de P0 qui a été redirigée vers une de ces adresses physiques dans le MMU ;
* En utilisant les zones aux adresses 0x80000000 et 0x88000000 (rappelle-toi que le MMU est inactif dans P1, donc tu mets les 3 bits du haut à 0 et ça te donne l'adresse physique) ;
* En utilisant les zones équivamentes de P2 à 0xa0000000 et 0xa8000000.
En général, on passe dans P1, donc on considère que la RAM qui est à l'adresse physique 0x08000000 est exposée dans l'espace virtuel à l'adresse 0x88000000. Il y a bien longtemps, la RAM faisait 256k, ce qui signifie qu'accéder n'importe où entre 0x88000000 et 0x88040000 (exclue) envoyait dans la RAM. Aller plus loin envoyait dans le vide, sans doutes des zéros ou des erreurs...
Mais depuis que la RAM fait 512k (longtemps), on peut aller plus loin parce qu'on a remarqué que les adresses virtuelles 0x88040000 à 0x88080000 (exclue) pointent aussi vers de la mémoire (puisqu'on peut lire, écrire, et les changements persistent). Tu peux aussi y accéder via la zone 0xa8040000 à 0xa8080000 (exclue), qui pointe vers la même mémoire physique, mais on ne le fait jamais.
Oui, le Modern Operating Systems de Tanenbaum est bien, la moitié sur les sytèmes centralisés (classiques) est très accessibles. De mémoire dès le troisième chapitre on est sur la gestion de la mémoire. Tout le reste est très intéressant également.