Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Vie communautaire


Index du Forum » Vie communautaire » GladOS - un OS pour nos chères calculatrices.
Yatis Hors ligne Membre Points: 580 Défis: 0 Message

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.



Disperseur Hors ligne Membre Points: 1830 Défis: 1 Message

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
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 15/10/2019 18:51 | #


Oui. Enfin ce n'est pas l'installation du SDK qui va t'arrêter
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Disperseur Hors ligne Membre Points: 1830 Défis: 1 Message

Citer : Posté le 15/10/2019 20:11 | #


Non c vrai
Yatis Hors ligne Membre Points: 580 Défis: 0 Message

Citer : Posté le 01/11/2019 16:13 | #


Salut ! Voilà quelque nouvelle du projet !

La dernière fois, je vous parlais des devices à la UNIX. Je les ai implémentés et ça m'a permis de faire les premiers appelle système : open, read, write, close, lseek. Par la suite j'ai refait la gestion de la mémoire physique et maintenant le gestionnaire de page a son propre cache et la gestion de la "heap" demande des pages si besoin. En parallèle, j'ai fait un début de driver pour la communication Serial (3pins). Le but était d'avoir une calculatrice qui ferait office de loggeur pour checker que tout son passe bien pendant le boot mais je n'ai pas eu le courage de le finaliser. Je me suis dit que, quitte à avoir un logeur externe autant faire un driver USB et avoir les logs depuis un laptop.

J'ai aussi ajouté (c'est très expérimental pour le moment) un sheduler et il fonctionne ! Le multi-processus est actuellement possible sur ma calculatrice (j'ai pu faire tourner 3 processus utilisateur en parallèle).

Cependant, j'ai quelques problèmes avec l'état actuel de l'OS. Mon but était d'aller le plus loin possible dans le prototypage d'un potentiel OS avant de faire une refonte du projet (ou d'abandonnée le projet, si les possibilités était trop faible). Actuellement, l'OS est archi instable (j'ai une corruption de stack assez vénère, entre autres), certaines parties sont mal pensées / hardcodées, ce qui m'empêche d'avancer et ça devient de plus en plus dangereux de tester des choses dessus. Je pense donc que le moment est venue d'arrêter le prototypage. Ce premier jet m'aura permis d'apprendre beaucoup de choses et je pense que ça vaut le coup de continuer, même si les performances seront assez basses (je pense).

Donc je vais refaire le projet de 0 en essayant de prendre en compte le plus possible la norme POSIX. Le but sera d'avoir ce que j'ai déjà sous la main (à savoir un bootstrap, la gestion des pages physiques, un VFS et un sheduler) avec une gestion du clavier et un moyen de communiquer en USB. Ensuite viendra la gestion des processus avec la communication inter-processus (pipe, mutex, etc....).

Mais j'avoue ne pas avoir réellement la foi de reprendre à 0, ces derniers jours de débogage mon rendu fou à cause de la corruption de stack et certain problème IRL. Actuellement, je n'ai aucune envie de faire la refonte. Je mets donc le projet en stand-by, histoire de prendre dû recule.
Cakeisalie5 En ligne Ancien administrateur Points: 1896 Défis: 11 Message

Citer : Posté le 01/11/2019 16:33 | #


Yatis a écrit :
J'ai aussi ajouté (c'est très expérimental pour le moment) un sheduler et il fonctionne ! Le multi-processus est actuellement possible sur ma calculatrice (j'ai pu faire tourner 3 processus utilisateur en parallèle).

Très impressionant !

Yatis a écrit :
Cependant, j'ai quelques problèmes avec l'état actuel de l'OS. Mon but était d'aller le plus loin possible dans le prototypage d'un potentiel OS avant de faire une refonte du projet (ou d'abandonnée le projet, si les possibilités était trop faible). Actuellement, l'OS est archi instable (j'ai une corruption de stack assez vénère, entre autres), certaines parties sont mal pensées / hardcodées, ce qui m'empêche d'avancer et ça devient de plus en plus dangereux de tester des choses dessus. Je pense donc que le moment est venue d'arrêter le prototypage. Ce premier jet m'aura permis d'apprendre beaucoup de choses et je pense que ça vaut le coup de continuer, même si les performances seront assez basses (je pense).

Donc je vais refaire le projet de 0 en essayant de prendre en compte le plus possible la norme POSIX. Le but sera d'avoir ce que j'ai déjà sous la main (à savoir un bootstrap, la gestion des pages physiques, un VFS et un sheduler) avec une gestion du clavier et un moyen de communiquer en USB. Ensuite viendra la gestion des processus avec la communication inter-processus (pipe, mutex, etc....).

Mais j'avoue ne pas avoir réellement la foi de reprendre à 0, ces derniers jours de débogage mon rendu fou à cause de la corruption de stack et certain problème IRL. Actuellement, je n'ai aucune envie de faire la refonte. Je mets donc le projet en stand-by, histoire de prendre dû recule.

Comme tu le pressens, le refactoring complet a un coût, et si c'est réellement la direction dans laquelle tu t'engages, c'est un long tunnel qui t'attend sur ce qui apparaît pourtant comme un coup de tête. Réfléchis bien : tu l'as dit toi-même, tu as un prototype qui démontre les capacités d'un tel projet et tu as de quoi donner envie, c'est peut-être le moment d'introduire d'autres personnes dans ce projet.

Même si tu as beaucoup de choses concernant le projet en tête, interrompre son développement pendant un temps paraît judicieux. Bien que tu aies documenté certaines parties techniques sur la bible, au-delà de ce topic qui décrit les évolutions et certains questionnements que tu as pu avoir, ainsi que certaines réponses qui t'ont été apportées, il est intéressant de poser :

— Les objectifs que tu t'es ou t'étais fixé, ainsi que leur temporalité (« à la fin de l'année », « d'ici deux ans », etc).
— Un retour d'expérience : quels idées ou concepts as-tu souhaité introduire dans la structure de ton kernel, est-ce que cela repose sur une ou plusieurs contraintes techniques, est-ce pour ouvrir une ou plusieurs possibilités, ces possibilités sont-elles vraiment nécessaires (sinon tu finis avec un MULTICS que personne ne pourra avoir).
— Un état des lieux (sur la base des deux éléments précédents) : le design de ton kernel, comment est-il organisé, qu'est-ce qui est bien fait, qu'est-ce qui doit être amélioré.

Sur cette base, tu pourras alors estimer si tes objectifs sont atteignables et les négocier si besoin, ou déterminer avec une démarche raisonnée (et non un cumul de frustration, i know the feeling) si tu as vraiment besoin de reprendre de zéro ou si tu peux ne reprendre que certaines parties. Tu pourras aussi, je pense, voir tout le chemin que tu as parcouru, autant personnellement qu'en termes de compétences relationnelles et techniques, qui est très loin d'être négligeable.

Une fois tout ceci réalisé, tu peux alors accueillir d'autres personnes pour donner une autre dimension à ton projet, une dimension d'échange, dans l'esprit « seul on va plus vite, ensembles on va plus loin ». D'autres personnes qui peuvent chacune apporter leur pierre, avec plus ou moins de compétences techniques que toi (ou tout simplement d'autres compétences, comme parcourir tout ce qui existe en logiciel pour les calculatrices modernes et pouvoir surligner ce dont le système a vraiment besoin pour être un jour utilisé !).

Tout ça est une suggestion, peut-être que tu ne souhaites pas revenir sur ce projet du tout pour le moment et peut-être que tu ne souhaites pas produire un kernel utilisé un jour par la communauté ; it's your choice to make, et tu choisis où mettre tes priorités dans la vie (pour couper court à ceux qui me diraient de faire la même chose pour le projet P7 ).

Quoi qu'il en soit, un grand bravo déjà pour en être arrivé là, et je te souhaite de continuer de réaliser des projets qui te font envie et progresser.

Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !

Mon blogBesoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 03/11/2019 10:58 | #


Cake a déjà tout dit ou presque ! J'en profite uniquement pour rempiler avec mon expérience personnelle.

J'ai réécrit gint un grand nombre de fois. À chaque fois, c'est parce que le projet commençait à inclure du code pour lequel je ne l'avais pas prévu quand je l'avais réécrit la fois précédente. La dernière en date, c'est pour supporter la Graph 90, et bien que beaucoup de code ait été réutilisé tel quel, il y avait plein de choses à changer dans les coins.

À une seule occasion, je l'ai fait parce que le code était si buggé que plus rien ne marchait. Je l'ai très vite regretté quand j'ai compris le bug quelques semaines plus tard : une simple erreur dans la description hâtive des registres du contrôleur d'interruptions. Oui, il en faut peu.

Ouvre un fichier aléatoire de ton projet et demande-toi : ai-je vraiment besoin de le réécrire ? La réponse est probablement non. Restructurer est long, mais moins long et moins frustrant que réécrire entièrement.

Les gros projets sont comme ça : ce sont les plus funs, mais aussi ceux qui nécessitent le plus de délicatesse dans la façon dont on écrit le code. N'oublie pas que le génie logiciel est une science : il y a un état de l'art, il y a des techniques, et il y a de la recherche active. C'est normal si c'est dur. Il faut simplement apprendre.

En tous cas, ça m'étonnerait que tu en restes là alors que tu as déjà atteint le même ordre de niveau que FiXOS. Tu peux aller bien plus loin encore
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Disperseur Hors ligne Membre Points: 1830 Défis: 1 Message

Citer : Posté le 03/11/2019 11:20 | #


Perso du haut de ma petite expérience, je peux dire que parfois il est difficile, voir impossible de choisir la bonne forme ou la bonne structure pour un même bout de code de manière à l'optimiser au maximum et à faciliter la suite de l'écriture du code. Je me suis souvent vu confronté à ce genre de problèmes ou plusieurs solutions fonctionnent mais pas une ne permet de simplifier le code, et ce notamment en Python . Sur l'aspect réécriture, il m'est arrivé une seule fois de tout réécrire, il s'agissait d'un petit programme, pas d'un gros projet comme celui dont il est question ici, mais ce fut quand même une perte de temps car une fois réécris et fonctionnel, on se rends compte que seulement une ligne ou une commande dysfonctionnait. Autant de temps perdu à réfléchir à la suite du code. Je ne peux donc que te déconseiller de tout réécrire. Au pire, garde quand même des bouts..
En tout cas je suis de tout cœur avec toi et te souhaite d'y parvenir !
Gladosse Hors ligne Membre Points: 229 Défis: 2 Message

Citer : Posté le 29/01/2022 14:26 | #


je savais pas que j'etais la popstar du forum avant mon arrivee

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 95 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

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