GladOS - un OS pour nos chères calculatrices.
Posté le 08/10/2019 22:24
Salut tout le monde !
Comme je l'ai dit-il y a quelques jours,
lors de la réunion audio de PC, j'ai commencé un projet il y a maintenant quelque mois, concerne la création d'un OS pour nos chères calculatrices monochromes (pour l'instant). D'ailleurs l'historique du projet est accessible via
ce topic, que je vous recommande et j'en profite pour remercier encore une fois
Lephenixnoir pour sa patience et sa connaissance <3
Lors de la dernière réunion, Lephenixnoir m'a conseillé d'écrire ce topic qui, selon moi, ne devrait pas sortir maintenant car je juge que le noyau n'est pas suffisamment mature / intéressant pour en parler...mais j'espère que tout cela intéresse(ra?) quelques personnes quand même.
Voilà actuellement ce que j'ai sous la main :
* Un bootloader qui a ses propres primitives de lecture en SMEM et qui se charge de loader le kernel en RAM. (le kernel est un fichier ELF).
* Un bootstrap permettant d'initialiser les périphériques les plus importants (MMU, exceptions et interruptions matérielles, mode d'exécution du CPU).
* Gestion de la Mémoire Virtuelle à la fois au niveau physique (TLB et MMU) et logique (noyau lui-même), en répondant aux échecs du TLB.
* Gestion de plusieurs zones de mémoire virtuelles pour isoler les processus entre eux.
* Manipuler les interruptions en fonction du hardware et la version de l'OS de Casio (ex: clavier, écran, RTC, ...).
* Manipuler la mémoire physique par page (découvrir automatiquement la taille de la RAM, l'allocation "dynamique" de pages de 1ko ainsi que la gestion d'une "heap" pour le noyau).
* Un File System type FAT en RAM.
* Accéder en lecture seule au système de fichiers de la Storage MEMory (SMEM).
* Un Virtual File System me permettant à la fois de rendre plus rapide la création de système de fichier et de les mounter n'importe où.
* Lancer des processus depuis la SMEM via un loader ELF.
* La gestion des appelles système.
* Un driver clavier (utilisant les interruptions matérielles du KEYSC).
* Un driver pour l'écran (T6K11).
Petite précision quand même, tout ce qui est listé ici n'est pas forcément dans le noyau actuel mais ont déjà été codés et tester. À l'heure où je vous parle mon kernel s'initialise et lance le premier processus utilisateur puis bascule dans le code noyau grâce à l'exception inconditionnelle
TRAPA et je viens tout juste de mettre en place le changement de contexte
processus -> kernel -> processus. Il me reste plus qu'a à mettre en place les appelle système qui vont bien
Mais il y a quelques points que j'aimerais améliorer avant d'avoir quelque chose d'un minimum intéressant :
* La gestion de la mémoire physique (qui est obsolète actuellement).
* La gestion du TLB (qui n'est pas encore assez correcte à mon goût).
* La gestion des appelles système qui n'a pas suffisamment été testé (à cause des changements de contexte effectués par le basculement
processus -> kernel et vis et versa).
* Utiliser une stack kernel partagée car, actuellement chaque processus possède deux stacks (processus et kernel) ce qui est lourd (2Ko en plus par processus) mais ce n'est pas facile à mettre en place rapidement (donc je ne sais pas encore).
* Une gestion des fichiers ELF un peu plus pousser en chargeant des programmes PIE (ce n'est pas le cas actuellement car j'aimerai juste avoir quelque chose de stable rapidement).
* Respecter POSIX parce que, faut pas déconner non plus, c'est quand même extrêmement crade actuellement (et surtout, pas assez sécurisé).
* Refaire la gestion des devices a la UNIX (qui existe mais n'est pas adaptés pour l'architecture actuelle du noyau).
* Documenter le noyau et avoir un code facilement maintenable / compréhensif. (dans le code et sur la Bible).
Une fois tout ça en place, je compte publier une démo du kernel pour le curieux (avec quelque programme de base comme un
shell et un
ls par exemple).
Puis, à ce moment-là je reprendrais le désassemblage du code de Casio a la recherche de certaine informations qui sont pas très bien (voir pas du tout) documentée (notamment l'EEPROM).
En parallèle, je comptais mettre un jour
Vhex, un outil permettant de désassembler l'OS de Casio, pour lui intégrer un éditeur, un compilateur ainsi qu'un débogueur. Ce qui me sera bien pratique pour retracer les
Bfile_ (qui sont, au passage, d'une lenteur affolante et atroce à désassembler x_x ). Mais, dans ce cas, ça m'impliquera de refaire un kernel, qui devra cohabiter (en RAM) avec l'OS de Casio cette fois (comme gint) (oui, ce n'est pas le cas de GladOS qui ne rend jamais la main a Casio et qui écrase tout en RAM). Après, ce n'est pas super complexe...faut juste être prudent
Pour finir, voila une liste de ce que j'ai en tête pour GladOS:
* Gestion de l'USB pour avoir des logs plus verbeux.
* La gestion des librairies partagées.
* Écriture en EEPROM.
* Remplacer complètement l'OS de Casio dans l'EEPROM car je juge trop dangereux de faire cohabiter les deux noyaux au même endroit.
Bien sur le dernier points va mettre du temps à arriver (mais ça arrivera un jour) et il me manque encore beaucoup de boulot xD (j'ai quelque idée ceci-dit...). Je n'ai pas envie de mettre de date, sachez juste que ce projet me tiens a cœur et je ne compte pas arrêter avant d'avoir cassé ma calculatrice
Encore une chose, les sources ne sont pas (encore) accessible car le kernel n'est pas assez sécurisé et mature pour le mettre en publique : je n'ai pas envie qu'une personne se retrouve avec une calculatrice foiré parce qu'il / elle ne savait pas ce qu'il / elle faisait. Partez aussi du principe que le jour ou je commence à toucher a l'EEPROM les sources ne seront plus disponible car le code sera extrêmement dangereux à utiliser. (on en est pas la et je compte donner des infos au fur et à mesure de l'avancement du projet, exactement comme Kristaba faisais).
PS: Pour le curieux, j'écris de la documentation et je poste mes désassemblages / découverte sur
ma section de la Bible de Planet Casio.
Citer : Posté le 08/10/2019 22:25 | #
Wait, on était déjà au courant en fait non ?
Citer : Posté le 08/10/2019 22:59 | #
Wait, on était déjà au courant en fait non ?
Ben non : moi
Passé ici il y a peu. ಥ‿ಥ
Jouez à Mario sans arrêt sur votre Casio !
City Heroes
Piano Casio
Micro GIMP
Citer : Posté le 08/10/2019 23:36 | #
J'avais vaguement entendu parler du projet d'OS, j'ai hate de voir si les interfaces graphiques vont changer!
Lien: https://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=15779
Citer : Posté le 09/10/2019 09:15 | #
J'ai quelques questions : 1 : Lorsque ce projet sera terminé ( c'est à dire un OS utilisable et fonctionnel ) , pourra t'on développer des logiciels externes pour cet OS ?
2 : Si oui , en quel langage ?
Merci d'avance et bon courage
Passé ici il y a peu. ಥ‿ಥ
Jouez à Mario sans arrêt sur votre Casio !
City Heroes
Piano Casio
Micro GIMP
Citer : Posté le 09/10/2019 22:00 | #
Bon moi aussi j'ai plein de questions, mais plus techniques !
Quelle est la puissance du driver pour le système de fichiers ? Qu'est-ce que tu peux ou ne peux pas faire ? Est-ce que cette fonctionnalité est récente (ie. la fois où on a désassemblé Bfile_OpenFile() en parallèle) ou plus ancienne ?
Je suppose que tu mets le MMU en mode multiprocessus avec les ASID pour faire ça ?
Quelle taille de blocs, quelle quantité allouée au total ? Y a-t-il des fichiers dedans au démarrage (eg. initramfs) ou c'est vide ?
Tu peux détailler le principe et rapidement le fonctionnement de ce composant ?
On en a discuté déjà, mais je suis pas sûr de voir ce que tu veux faire avec une pile partagée.
Bon courage, quand tu auras fait ça tu auras dépassé le stade de FiXOS je pense !
As-tu pensé à construire un device tree ?
Est-ce que tu as des pistes sur la compatibilité/l'universalité des ROMs sur les différents modèles ?
+1
+2
Voilà, passage rapide mais je pense que ça peut lancer des discussions.
Citer : Posté le 10/10/2019 22:34 | #
Wait, on était déjà au courant en fait non ?
Oui est non, l'ancien topic n'était plus trop approprié pour le projet. Puis il fallait dans tous les cas que je fasse un topic à part pour le pas "polluer" l'ancien car il parlait d'un débogueur et non d'un OS.
J'avais vaguement entendu parler du projet d'OS, j'ai hate de voir si les interfaces graphiques vont changer!
Haha, pour l'instant ce n'est, ni ma priorité, ni le moment pour penser à ça x)
Ceci dit, la partie "graphique" sera la plus séparée du kernel possible et il ne sera vraiment pas compliqué de créer ton propre "gestionnaire de fenêtres" pour avoir de beaux menus dynamiques et sympathiques.
Mais encore une fois, ce n'est pas pour ça que le projet a été créer.
Pour moi, ce projet me permet d'apprendre énormément de chose et fait de bosser sur une machine dont la spécification est très limitée est intéressant : ça m'oblige à apprendre, comprendre, mettre en pratique des dizaines de thèmes différents, tout en me donnant de plus en plus la capacité de visualiser clairement les problèmes rencontrés dans la programmation de noyaux.
Le projet n'avait pas pour but de devenir publique du fait que je code pour satisfaire ma curiosité et sans but précis mais maintenant que je commence à être à l'aise avec le proco et que le projet commence à s'affiner ; je pense que mes travaux pourront, à court terme, intéresser certaines personnes et, a plus long terme, être utile pour certain d'entre vous (comme Gint) car les développeurs qui ne programment pas encore sur Casio pourraient faire cette transition plus simplement étant donné que le système serait UNIX-like.(sans parler de la sécurité, la fiabilité, l'API (syscall) mise à disposition et l'abstraction du matériel.).
J'ai quelques questions : 1 : Lorsque ce projet sera terminé ( c'est à dire un OS utilisable et fonctionnel ) , pourra t'on développer des logiciels externes pour cet OS ?
2 : Si oui , en quel langage ?
1) Actuellement je programme déjà des programmes externes pour le noyau car il est tout à fait capable de lancer un processus et de charger un programme depuis la SMEM. (il n'y a toujours pas de multi-proces mais ça viendra)
2) Les programmes peuvent être codés en ce que tu veux du moment que le binaire se trouve au format ELF (et aussi à condition qu'il respecte 2 / 3 bricoles qui traine comme le linker). Et comme je n'ai toujours pas commencé à travailler sur les librairies dynamiques (les .so) dont il faudra donc utiliser les librairies statiques (les .a) (ce qui alourdit considérablement les programmes mais je m'occuperai de cette partie plus tard, quand le noyau sera stable).
Pour te donnait une idée du temps que me prend l'adaptation d'un programme, il me suffit d'avoir les sources d'un projet, ajouter un linker et de faire un make...c'est tout
Quelle est la puissance du driver pour le système de fichiers ? Qu'est-ce que tu peux ou ne peux pas faire ? Est-ce que cette fonctionnalité est récente (ie. la fois où on a désassemblé Bfile_OpenFile() en parallèle) ou plus ancienne ?
Récemment, (~1 mois), j'ai commencé à comprendre une bonne partie du FS de Casio et je suis actuellement totalement autonome pour trouver et lire un fichier (même ceux qui sont "supprimés"
Le système de fichiers de Casio se traduit par :
0xa0270000: une table de blocs indiquant des données sur certain secteur de l'EEPROM (c'est du moins ce que j'en ai déduit)
0xa0270320: une table répertoriant les fichiers. Et chaque fichier contient :
* Un header (donnant certaine info comme le nom du fichier, son type, s'il se trouve dans un dossier ou à la racine, ...).
* Des fragments (indiquant la taille de la donnée que le fragment contient (il manque un octet à chaque fragment x_x), son numéro, l'offset de l'adresse qui contient la donnée, ...).
J'ai plus ou moins laissé tomber le désassemblage quand j'ai découvert la table des fichiers, après j'ai piffé à l'infini et l'au-delà pour comprendre comment accéder aux données, les fragments, ... Mais il me faut absolument un traceur pour finir de désassembler cette bouse de Bfile_Open_OS(), tant que je n'aurai pas cette outil, ça va être complexe d'avancer (d'ailleurs impossible de trouver l'UBC....). Au passage, j'ai reçu une Graph90 et leur système de fichiers a l'air totalement différent mais c'est surement basé sur la même architecture, à tester donc.
Je suppose que tu mets le MMU en mode multiprocessus avec les ASID pour faire ça ?
Absolument ! Mais je n'ai pas encore vérifier si l'ASID existait véritablement (Kristaba a eut des problèmes avec, je verrai ça le jour ou je commence le multi-process). Le processus est totalement cloisonné dans sa mémoire virtuelle et j'arrive à savoir quand un processus provoque une segmentation fault
J'en profite pour te prévenir, le bit MMUCR.SQMD semble ne pas être présent ce qui m'a fait douter de la fiabilité de la documentation mais après plusieurs tests...de...disons configuration a coup de 0xffffffff sur le MMUCR ainsi que le désassemblage de l'handler de TLB miss de Casio ; je peux dire, sans trop de risques, que la documentation du SH7724 sur le MMU est fiable
Je compte faire certains tests pour vérifier si le bit MMUCR.SQMD existe ou non, je te tiendrais au courant
Au passage, le jour ou je commence à faire la refonte de Vhex je pense essayer de répondre au TLB miss a la place de Casio car ça me semble pas trop complexe vu la façon basique dont il le gère (mais il faudra prendre beaucoup plus de précaution).
Quelle taille de blocs, quelle quantité allouée au total ? Y a-t-il des fichiers dedans au démarrage (eg. initramfs) ou c'est vide ?
...
Tu peux détailler le principe et rapidement le fonctionnement de ce composant ?
...
As-tu pensé à construire un device tree ?
Pour l'instant le FS utilise des blocs de 64 octets car c'est largement suffisant (pour l'instant)
Au démarrage tu as quelque chose qui ressemble à ça (pour l'instant /dev est vide):
/:
|--dev:
| |-- screen
| |-- keyboard
| |-- tty0 (tty1, tty2, ...)
| |-- rtc0 (rtc1, rtc2, ...)
| |-- usb0 (usb1, usb2, ...)
| \-- tmu0 (tm0, tmu1, ...)
\--mtn:
\- smem:
|-- GLADOS:
| |-- glados.elf
| |-- shell.elf
| \-- ls
|-- loader.g1a
...
Mon Virtual File System me permet, comme tu peux le voir, d'utiliser plusieurs File System "en même temps" et ainsi pouvoir accéder aux différents mémoires de stockage présent sur la machine (SMEM (EEPROM) et gladfs (RAM...oui...je n'ai pas mieux comme nom xD)).
Pour le device-tree...j'ai un /dev qui me permet de faire un lien à l'exécution entre un "pilote" de périphérique et le système de fichiers.
On en a discuté déjà, mais je suis pas sûr de voir ce que tu veux faire avec une pile partagée.
ça m'éviterait d'allouer 2ko de stack kernel par processus, on n'a pas beaucoup de RAM !
Est-ce que tu as des pistes sur la compatibilité/l'universalité des ROMs sur les différents modèles ?
Franchement je n'ai aucune piste et ça va être treeeeees long à désassembler car Casio désactive les interruptions pendant l'écriture donc impossible d'y aller avec un débogueur / traceur ('fin si mais c'est complexe à mettre en place). Cependant il me semble que Kristaba a désassemblé une partie où Casio récupérait des infos sur l'EEPROM donc il y a un faible espoir pour réussir à faire un truc générique a tout type d'EEPROM. Mais ça reste a voir :/
J'en profite aussi pour donner quelques news sur le kernel.
J'ai totalement repensé la gestion des pages physique et c'est maintenant bien plus rapide / viable / fiable.
Pour faire simple, avant, j'avais une dépendance circulaire au niveau de la gestion de la mémoire physique car j'utilise 2 "modes":
* page: pour gérer des pages de 1024 octets.
* heap: pour gérer des bloques de 64 octets dans les pages.
Ce qui me permettait (je pensais) d'utiliser de la mémoire physique uniquement quand j'en avais vraiment besoin. De plus, je pouvais demander qu'une seule page à la fois et la gestion d'une page (par l'heap) utilisais une partie comme cache, ce qui me laissait pratiquement rien de libre pour allouer de la mémoire (une page de 1024 octets me donnait une allocation max de ~960 octets). La dépendance résidait dans la gestion des pages car j'avais besoin de la heap pour stocker des informations...mais la heap avait besoin de la gestion des pages pour fonctionner...vous voyez le problème
Maintenant la heap fait ~10ko et "le cache" de la gestion des pages est directement demander au début, ce qui a enlevé la dépendance circulaire. Autant dire que ça à gagner en sécurité et en efficacité ! Qui plus est, maintenant, je peux demander un nombre de pages "qui se suivent" ce qui est super pratique et m'a permis de sécuriser une autre chose (et pas des moindres) la stack kernel. Avant j'utilisais une partie de la mémoire virtuelle du processus pour y mettre une stack kernel et il fallait absolument forcer les pages à exister aux yeux du MMU (je vous rassure, les pages avaient certains flags qui empêchaient au processus d'accéder à cette stack mais si jamais les page n'existait pas...ça crashais lors du basculement noyau -> kernel (syscall)).
Bref, je vais enfin pouvoir commencer la gestion de l'user land et du multi-process !
J'ai aussi mis à jour mon bootloader ainsi que la gestion de l'accès de fichier de la SMEM suite à une découverte forte sympathique au niveau de l'organisation des fragments de données d'un fichier. Ça m'a permis de savoir combien de fragments contient un fichier et ainsi accéder au prochain fichier avec seulement avec un calcul au lieu de parcourir chaque fragment jusqu'au nouveau fichier. Honnêtement, j'aimerais bien voir la différence de rapidité entre mon casio_smem_open() et Bfile_OpenFile() je pense être au moins 10 fois plus rapide xD
Citer : Posté le 12/10/2019 19:22 | #
Je vais être honnête, je savais que ton projet avait une vraie envergure, mais je commence seulement à réaliser à quel point c'est du lourd. x)
Je doute que tu puisses faire tourner grand-chose avec valgrind sur la calculatrice ceci dit - gros coût d'entrée en mémoire et gros ralentissements à prévoir (du genre entre 3× et 20× plus lent).
0xa0270000: une table de blocs indiquant des données sur certain secteur de l'EEPROM (c'est du moins ce que j'en ai déduit)
0xa0270320: une table répertoriant les fichiers.
Merci pour ces infos. Je ne doute pas que ces valeurs vont dépendre de chaque version de l'OS - y a-t-il un protocole permettant de les obtenir à la main voire de les calculer à l'exécution ?
Il ne "manque pas" un octet à chaque fragment, c'est évidemment fait exprès. Imagine que c'est stocké sur 16 bits. Il n'y a clairement pas de fragment de taille 0, ça ne servirait à rien. Par contre il y a probablement des fragments de taille exactement 2^16 parce que ça s'aligne tout pile. Personne ne voudrait un fragment de taille 2^16-1.
Conclusion, les valeurs à représenter sont 1..2^16. Donc on écrit n-1 dans le champ 16 bits quand le fragment est de taille n.
Ce genre de technique est aussi utilisé à certains endroits dans les registres périphériques du MPU.
fxos est fait pour ça. Si tu penses à des fonctions qui ne sont pas implémentées dedans, je peux essayer de les ajouter. (Je peux pas exécuter pas-à-pas cela dit.)
Dans un add-in classique ? Je vois pas trop l'intérêt, à part que c'est un peu dangereux. x)
Sympa ton système de fichiers ! Petite suggestion, au lieu d'exposer /dev/tmu{0,1,2}, tu peux peut-être exposer juste /dev/tmu, et chaque fois que tu fais open() dessus ça donne un nouveau timer, avec une erreur si les trois sont utilisés ?
Propre. Comment ils sont formalisés tes pilotes d'ailleurs ? Dans gint il y a une structure dédiée et une macro GINT_DECLARE_DRIVER(). Tu as peut-être un truc du même genre ? Je doute que tu aies des modules noyau encore.
Mais dans ce cas tu ne peux pas interrompre un processus pendant un syscall → pas très honnête pour le scheduler.
En principe le tas utilise le syscall brk() pour obtenir des pages et ensuite utilise ces pages. L'allocateur physique stocke ces données dans une zone statique et s'alloue lui-même des pages en cas de besoin, sans dépendre de personne. C'est ce qu'il se passe "d'habitude".
Tu m'intrigues encore là. Quand tu auras le driver timer bien exposé dans /dev je pense que tu n'auras aucun mal à mesurer les perfs en détail à la façon de la libprof mais en plus propre
Citer : Posté le 12/10/2019 22:36 | #
Je doute que tu puisses faire tourner grand-chose avec valgrind sur la calculatrice ceci dit - gros coût d'entrée en mémoire et gros ralentissements à prévoir (du genre entre 3× et 20× plus lent).
Oups, je me suis mal exprimé. Je voulais dire qu'on pourra déboguer les programme depuis un laptop (avec Valgrind par exemple) pour s'assurer de la fiabilité du code.
Merci pour ces infos. Je ne doute pas que ces valeurs vont dépendre de chaque version de l'OS - y a-t-il un protocole permettant de les obtenir à la main voire de les calculer à l'exécution ?
Oui il y a moyen, le syscall 0x01ad il me semble, mais je n'ai pas encore réussi à le désassembler
Il ne "manque pas" un octet à chaque fragment, c'est évidemment fait exprès. Imagine que c'est stocké sur 16 bits. Il n'y a clairement pas de fragment de taille 0, ça ne servirait à rien. Par contre il y a probablement des fragments de taille exactement 2^16 parce que ça s'aligne tout pile. Personne ne voudrait un fragment de taille 2^16-1.
Ho ! :o ça explique tout, je me disais biens que Casio n'avait pas pu faire une erreur aussi grosse sans le voir x)
Propre. Comment ils sont formalisés tes pilotes d'ailleurs ? Dans gint il y a une structure dédiée et une macro GINT_DECLARE_DRIVER(). Tu as peut-être un truc du même genre ? Je doute que tu aies des modules noyau encore.
Je n'ai pas encore mis en place les ioctl mais certain périphérique (comme l'écran ou le clavier) peuvent être utilisé avec les appels systèmes open() / read() / write() / close().
Oui j'utilise une structure qui prend pas mal de chose :
* nom
* architecture
* version de l'OS min.
* version de l'OS max.
* les opérations du device : open, read, write, close.
Et les devices sont chargés dynamiquement au démarrage dans /dev
Sympa ton système de fichiers ! Petite suggestion, au lieu d'exposer /dev/tmu{0,1,2}, tu peux peut-être exposer juste /dev/tmu, et chaque fois que tu fais open() dessus ça donne un nouveau timer, avec une erreur si les trois sont utilisés ?
Je pourrais, effectivement. Mais j'aimerai savoir pourquoi il y a /dev/tty et /dev/tty{0, 1, 2,...} de base...chaque numéro indique le nombre de fois que le tty a été ouvert ?
Je vais réfléchir à ça dans les prochains jours car j'ai fini la partie bootstrap du noyau (je donne plus de détail à la fin du poste).
Mais dans ce cas tu ne peux pas interrompre un processus pendant un syscall → pas très honnête pour le scheduler.
C'est pas faux, puis ça compliquerai / ralentirai plus qu'autre chose le noyau. Je mets cette idée de côté quand même (sait-on jamais).
En principe le tas utilise le syscall brk() pour obtenir des pages et ensuite utilise ces pages. L'allocateur physique stocke ces données dans une zone statique et s'alloue lui-même des pages en cas de besoin, sans dépendre de personne. C'est ce qu'il se passe "d'habitude".
Même pour le kernel ? :o
Ceci-dit pour l'instant j'essaie d'avoir le multi-process le plus rapidement possible histoire de me confronter rapidement aux principaux problèmes ; ensuite je ferais une refonte de l'OS pour avoir quelque chose respectant le plus possible POSIX.
(édit : ça me semble terriblement logique maintenant que je relis ce que tu viens d'écrire, c'est un système de copy-on-write non (?)
Tu m'intrigues encore là. Quand tu auras le driver timer bien exposé dans /dev je pense que tu n'auras aucun mal à mesurer les perfs en détail à la façon de la libprof mais en plus propre
Je compte tester ça dès que je le peux et je te tiens au courant, je suis très curieux aussi de voir la différence de temps.
Voici les avancements sur le projet.
Comme je l'ai dit plus haut, j'ai fini la partie bootstrap du noyau cela signifie que le kernel est complètement initialisé et le premier processus lancé. Le premier processus utilisateur (c'est important (et classe) de le souligner) ne fait rien de grandiose, il affiche juste "Odd says: Coucou c'est nous !" ce qui signifie que les premiers appelles système ont été mis en place (à savoir effacer l'écran et afficher du texte) mais c'est déjà un début ! Pour l'instant les interruptions sont coupé pendant l'appelle système car je voulais juste m'assurer que le basculement processus -> kernel -> processus fonctionne, ce qui est le cas maintenant. Par la suite, il va falloir que je mette a jours la gestion des devices à la UNIX pour pouvoir accéder au TTY et commencer le shell !
Citer : Posté le 13/10/2019 10:38 | #
* nom
* architecture
* version de l'OS min.
* version de l'OS max.
* les opérations du device : open, read, write, close.
Et les devices sont chargés dynamiquement au démarrage dans /dev
Impeccable ! o/
Ils sont numérotés parce qu'ils ont une "identité" : /dev/tty1 est celui que tu obtiens quand tu tapes Ctrl-Alt-F1, et ainsi de suite. Mais pour les timers on se fout de savoir si on manipule TMU0 ou un autre.
Le kernel n'utilise pas de syscall évidemment, mais oui le tas du kernel fait appel à l'allocateur de pages pour obtenir de la mémoire.
Copy-on-write c'est différent, c'est une histoire de cache. Précise ta pensée...
Bravo ! Je te suggère fortement de laisser le dessin au processus. Peut-être que seul l'appel système qui affiche une image à l'écran est intéressant pour l'instant. Avoir ça en userspace sera utile pour la partie graphique plus tard
Citer : Posté le 13/10/2019 19:36 | #
Y'a une question que me trotte dans la tête, tu fais comment pour tester GladOS? Tu le flashes dans la calto, où tu utilises un addin?
Lien: https://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=15779
Citer : Posté le 14/10/2019 11:05 | #
J'ai un addin qui fait office de bootloader et s'occupe de charger GladOS (qui est un fichier ELF) dans la RAM. S'ensuit une partie qui s'appelle bootstrap dont le but est de s'occuper d'initialiser le kernel, les interruptions, le CPU, les différents périphériques, etc. Ainsi que de charger le premier processus dans sa mémoire virtuelle (actuellement un shell qui, lui aussi, est un fichier ELF). Une fois cette partie finie, le basculement du processus vers le noyau peut se faire de 3 façons : sois avec l'instruction trapa (interruption logicielle), sois avec les interruptions hardwares où sois avec les exceptions.
À mince ! C'est exactement ce que j'avais fait avant de changer pour une heap "statique" ; mais du coup où est stocké le cache pour l'allocateur de page (qui est proche de 5ko de mon côté) ? Car le problème que j'avais rencontré étais une dépendance circulaire entre la heap et le gestionnaire de pages.
Bien sûr ! Mais pour l'instant j'avais ces fonctions a porté de main, c'était plus simple pour moi.
Pour moi le Copy-on-write a pour but de simuler une ressource tant qu'elle n'est pas utilisée explicitement (écriture / lecture). Ce qui est, il me semble, le cas avec malloc : tu peux avoir (pratiquement) autant de place que tu veux lors que tu n'utilises pas la zone allouée car "elle n'existe pas" sur le moment. Ça évite de d'allouer de la mémoire pour rien. Mais du coup ça signifie que l'allocation maximum ne peut être plus gros que la taille d'un page ? Sinon ça signifie que le cache de la heap est statique ? Et ou est-il stocké ?
Citer : Posté le 14/10/2019 11:36 | #
Soit il est alloué statiquement, soit il est alloué à la main dans des pages (modulo une petite initialisation l'allocateur de pages peut se donner lui-même de la mémoire
Ah je vois. Cette chose s'appelle de l'allocation paresseuse. Copy-on-write est un cas particulier. Si tu me demandes une copie, alors je te donne l'original sans copier pour gagner du temps. Mais dès que tu écris, je copie pour de vrai. L'espoir est qu'en fait tu n'écriras jamais donc je peux économiser la copie.
Tu peux faire ça avec des pages. Quand tu appelles mmap() par exemple, Linux ne t'alloue pas la mémoire immédiatement, il attend que tu lises ou écrives les pages concernées. L'espoir est que tu n'utiliseras pas tout les pages. (Par exemple quand tu mappes un fichier en mémoire tu ne vas pas forcément lire ou écrire l'intégralité du fichier, il suffit donc de charger paresseusement les zones que tu utilises.)
L'allocation paresseuse pour le tas ça fait bizarre comme idée. Je ne sais pas si ça existe. Ce qui est sûr c'est que tu peux profiter d'allocation paresseuse dans le tas sans rien faire. En effet, le tas utilise l'allocateur de pages pour obtenir sa mémoire. Donc tant que tu n'utilises pas la mémoire renvoyée par malloc(), l'allocateur de pages n'allouera pas de pages.
Il faut bien voir la hiérarchie "allocateur de pages → tas → programme". Si l'allocation paresseuse a lieu tout en bas, elle se propage partout. (Bien sûr, la granularité que tu obtiens sera celle d'une page. Mais je pense que c'est largement suffisant.)
Citer : Posté le 14/10/2019 12:26 | #
Du coup j'ai lu et je me demande ce dont on doit s'attendre prochainement.. parceque je comprends a peut pres mais je ne suis pas tres renseigné sur ce sujet. Donc doit on s'attendre a un systeme d'exploitation tout neuf et modulable bientot pour notre chere calto ?
-Planétarium 2
Citer : Posté le 14/10/2019 12:38 | #
Il faut peut-être préciser le but du projet... et dissiper (si besoin) l'idée que ce serait un remplacement pour l'OS actuel, ses applications mathématiques, etc.
Citer : Posté le 14/10/2019 15:30 | #
Et la présence ou non d'un mode examen
Passé ici il y a peu. ಥ‿ಥ
Jouez à Mario sans arrêt sur votre Casio !
City Heroes
Piano Casio
Micro GIMP
Citer : Posté le 14/10/2019 17:24 | #
[...] dissiper (si besoin) l'idée que ce serait un remplacement pour l'OS actuel, ses applications mathématiques, etc.
Il n’empêche que l'idée d'un os comportant uniquement une invite de commandes type DOS pour la calto me plait beaucoup
-Planétarium 2
Citer : Posté le 15/10/2019 14:35 | #
doit on s'attendre a un systeme d'exploitation tout neuf et modulable bientot pour notre chere calto ?
...
Et la présence ou non d'un mode examen du coup ?
...
Il n’empêche que l'idée d'un os comportant uniquement une invite de commandes type DOS pour la calto me plait beaucoup.
Le but ultime du projet sera de prendre complètement la place de Casio dans l'EEPROM. (ce qui est loin d'être le cas) Mais je tiens à souligner que l'OS n'a pas pour but de "remplacer" celui de Casio. Pour ce qui est de l'OS en lui-même j'aimerai arriver a quelque chose d'UNIX-like respectant le plus possible POSIX. J'aimerai vraiment faire de la calculatrice, un outil à part entière pour faire découvrir le développement "embarqué" de manière plus "douce" et "simple". Le développement actuel sur Casio (et l'embarquée en général) est un peu barbare au début (même si Gint aide vraiment beaucoup) et pas mal de personne abandonne car il faut installer un compilo, un linker, des librairies, changer l'OS, trouver comment transférer les fichiers, etc... ce qui n'est pas une partie de plaisir. En théorie, sur GladOS, on aura juste besoins de balancer un fichier par USB / 3pins donc (en théorie) on a juste un compilo et un utilitaire à installer, ce qui me semble plus acceptable. De plus, comme l'OS sera UNIX-like, la transition pour les développeurs sera bien plus simple. (C'est d'ailleurs sur ça que je vais travailler une fois les devices mis en place, la gestion de l'USB).
Aussi, je continue de m'amuser avec le noyau ainsi que les différents périphériques (rtc, timer, adc, usb, ...) et en parallèle j'essaie de faire une documentation complète sur la calculatrice, j'ai déjà commencé (KEYSC) mais comme je n'ai pas énormément de temps en ce moment pour me relire / corriger certaine partie, je me contente de la mentionner.
Je compte ré-écrire le topic car il n’est pas vraiment compréhensible / attirant, mais je n'ai pas le temps de m'occuper de ça actuellement et j'attends d'avoir finis la première version du kernel ainsi que mon stage pour y remédier.
Citer : Posté le 15/10/2019 15:57 | #
Le développement actuel sur Casio (et l'embarquée en général) est un peu barbare au début (même si Gint aide vraiment beaucoup) et pas mal de personne abandonne car il faut installer un compilo, un linker, des librairies, changer l'OS, trouver comment transférer les fichiers, etc... ce qui n'est pas une partie de plaisir. En théorie, sur GladOS, on aura juste besoins de balancer un fichier par USB / 3pins donc (en théorie) on a juste un compilo et un utilitaire à installer, ce qui me semble plus acceptable. De plus, comme l'OS sera UNIX-like, la transition pour les développeurs sera bien plus simple. (C'est d'ailleurs sur ça que je vais travailler une fois les devices mis en place, la gestion de l'USB).
Je suis totalement d'accord , quand j'ai vu le nombre de choses à télécharger et installer , j'ai stoppé net le C
Passé ici il y a peu. ಥ‿ಥ
Jouez à Mario sans arrêt sur votre Casio !
City Heroes
Piano Casio
Micro GIMP
Citer : Posté le 15/10/2019 16:00 | #
Cela dit quand c'est trop facile il faut aussi assurer le service après-vente auprès de tous les gens qui téléchargent les outils mais ne savent pas du tout coder en C. Le problème c'est qu'autant on peut apprendre à des gens à coder en Basic sur Planète Casio, autant on ne peut pas leur apprendre à programmer en C. Le sujet est trop vaste, et dès qu'on dit "il faut apprendre sur PC" tout le monde s'en fout.
Citer : Posté le 15/10/2019 18:45 | #
Pas tords. N'empêche que tt le monde ne s'en fout pas. Moi par exemple, je continue mon apprentissage du C sur PC et de temps en temps je me lance sur ma g75. Mais c vrai que la methode pour prgrammer en c sur graph est barbare
Faut dire aussi que je suis un programmeur acharné. Et certains sr le site pourront en temoigner
-Planétarium 2