Projet FiXos (OS pour casio fx-9860/Prizm)
Posté le 07/11/2011 20:11
maj 14/11/2013 :
un peu d'actualités
maj 03/03/2013 :
mon (presque) dernier pavé
maj 06/03/2015 :
Dépôts GitLab du projet.
Vu que le sujet d'OS unix-like pour nos chères G85 (fx-9860) et dérivées, ainsi que pour la Prizm (fx-cg20) fait réagir pas mal de gens, j'ouvre un topic pour en parler plus en détail
(début du sujet
sur ce topic)
Déjà, quelques précisions, mes posts précédent étaient simplement des idées pour montrer l'utilité et ma vision d'un possible OS, je n'avais pas vraiment pour projet de le concrétiser dans l'immédiat. L'idéal serait de bosser là dessus conjointement avec des gars d'omnimaga, cemetech, et les autres communautés.
Ceci dit, j'ai déjà quelques idées dans la tête, donc autant les faire partager
(au passage, j'en profite pour répondre un peu aux posts de l'ancien topic)
DJ_Omnimaga : sur Casio on a jamais eu l'occasion de créer un OS tiers jusqu'à la fx-9860 (excepté la Graph100 mais c'était loin d'être le modèle le plus répandu), les processeurs étant non documentés. Depuis que tous les nouveaux modèles de Casio utilisent la même architecture plus ouverte, il est possible de créer un OS custom, mais si il n'y a toujours pas eu de projet d'OS c'est entre autre par ce que les addins permettaient déjà de faire des programmes sympa, et probablement aussi à cause du manque de "programmeurs systèmes" dans le monde Casio.
Vdragon.b: Oui, un OS est généralement codé en C (pas une obligation, mais Linux en est un bon exemple ouaip). Ceci dit, vaut mieux "bien coder", par ce que l'expérience permet de d'optimiser le code, d'utiliser des syntaxes très barbares -mais pratiques-, de comprendre la structure générale de l'OS. Après, si il s'agit de code hors-noyau (un petit utilitaire ou autre) bien entendu les performances sont moins critiques, donc si tu te sens tu pourras aider j'imagine.
Pour les grayscales et le multitâche c'est prévu dans mon idée perso effectivement.
(dans un premier temps, multitâche coopératif avant d'écrire un vrai ordonnanceur)
Pour le moment, les idées que j'ai pour le kernel :
- une fonction init pour initialiser le MMU, le cache, créer la pile kernel, initialiser les interruptions, charger le système de fichiers...
- un FS type FAT par exemple, serait potentiellement créé en tant que fichier du FS de Casio (pour permettre la cohabitation des deux systèmes, en évitant de se tapper le FS de Casio complètement en carton *siflotte*)
- système de virtual FS pour permettre une uniformité des API d'écriture de fichiers
- possibilité de lancer un programme binaire "pur" (binaire sans header G*A), un binaire G1A, ou un fichier ELF (ce dernier permettrait l'utilisation de techniques avancées)
- gestion des bibliothèques dynamiques (du .so si le format est pas trop lourd, custom sinon), dont Newlib (lib stdc) pour alléger les addins, profiter de fonctions spécifiques à chaque calculatrice...
- gestion du MMU en mode activé et pour environnement multiprocessus (basculement en monoprocessus si nécessaire pour assurer la retro-compatibilité G*A?)
- évidemment, les addins seraient lancés en mode 'user' pour assurer la sécurité du kernel
- syscalls utilisant l'instruction TRAPA de l'assembleur SH3 (interruption logicielle), pour basculer en mode protégé et accéder à l'espace noyau
- des drivers d'affichage dépendant du modèle de la calculatrice, permettant de gérer un mode "terminal" et un mode "graphique"
Si vous avez des questions, des choses à proposer, des contacts avec des gens intéressés ou quoi que ce soit n'hésitez pas.
Je ne sais toujours pas si je vais vraiment me lancer là dedans (c'est un gros projet encore une fois, peu de chances d'être fini un jour si y'a que moi dessus
), mais dans le pire des cas, les idées présentées serviront bien à quelqu'un, un de ces quatres
Citer : Posté le 05/04/2013 17:41 | #
Avec ça, y'a plus de SH3 ou pas, c'est carrément un nouvel OS
Plus de problèmes du genre
Mais c'est très long à faire, et ça demande d'être passionné par ça (à ce niveau là, faut pas compter que sur la motiv', je pense).
Citer : Posté le 05/04/2013 17:46 | #
T'as beau refaire l'OS, les processeurs SH3 et SH4 ne sont pas les mêmes donc ça sera compatible que pour un seul (a moins de l'adapter pour les deux).
Mais bon dans tous les cas, le projet n'en est pas du tout à la.
Citer : Posté le 05/04/2013 19:57 | #
Oui mais si tu le fait compatible, et selon moi c'est le principal intérêt, tout les add-ins seront incompatible. Mais après on pourra mieux trafiquer les fonctions d'I/O
Citer : Posté le 05/04/2013 21:16 | #
C'est vrai
Citer : Posté le 08/04/2013 23:00 | #
C'est le principe de l'interopérabilité d'un OS, du moment que vous adaptée les plus basses fonctions, le reste devrait marcher nickel, quelque soit le support. C'est pour ça que l'on peut avoir par exemple Daubian aussi bien sur un ordi qu'une ps3 ou même un Raspberry Pi...
Citer : Posté le 11/04/2013 09:47 | #
Normalement ça demande de recompiler un programme pour qu'il fonctionne sur le même OS mais des architectures différentes.
L'avantage fournis dans ce cas là par un OS c'est la compatibilité des sources (rien à changer pour qu'après re-compilation ça fonctionne), mais si les sources ne sont pas disponibles c'est foutu.
Ceci étant dit, SH3 et SH4 sont tellement proches niveau jeu d'instruction et encodage des instructions qu'il me semble pas qu'il y aurait de problème pour faire des addins compilés pour SH3 qui fonctionnent parfaitement sur SH4 (l'inverse est plus compliqué à cause des instructions additionnelles sur le SH4, mais pas forcément impossible puisque le proco permet de traiter les exceptions d'instruction invalides, ça dépend des cas quoi).
Pour ce qui est du projet, je suis actuellement en Inde pour un stage de quelques mois, et je n'ai plus ni le temps ni la tête à ça ici, évidemment.
On verra si ça me branche toujours à mon retour en France!
Citer : Posté le 11/04/2013 16:50 | #
C'est noté chef!
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 26/06/2013 17:38 | #
En relisant tout ce que vous avez écrit, j'ai pu constater que certain voulait recreer un OS et d'autre juste un addin. Le mieu, je pense serait de créer un logiciel du style de nlite qui permettrait a chacun de choisir les option qu'il voudrait ajouter/supprimer.(meme sans connaissance en programmation)
Si ca ne rend pas le projet trop long et trop dur pour les membres participant, je trouve que ce concept pourrait plaire (moi le 1er
Citer : Posté le 14/11/2013 18:39 | #
Encore une mise à jour du topic même si je ne suis plus vraiment actif sur PC
J'ai encore eu un petit élan de motivation pour ce projet dernièrement, et même si avec moi je ne peux jamais être sûr que ça va durer longtemps, autant partager quand même l'état de ce petit projet.
J'ai profité de ce temps pour corriger beaucoup de soucis qui traînaient avec la gestion des exceptions et surtout de la mémoire virtuelle.
Le but étant de faire fonctionner un premier programme "userland", cela demande qu'une des parties assez délicates (changement de contexte et changement de mode, ainsi que la gestion du MMU) soient parfaitement fonctionnelles. Ce qui est particulièrement problématique en raison du fait que ces parties ne peuvent pas être debuguées facilement (une exception provoque un reset pur et simple, et le code manipule beaucoup de choses qui peuvent en lever
En plus de cela, il a fallu créer un bootloader plus élaboré, avec ses propres primitives permettant de lire le système de fichier de la Storage MEMory, car le bootstrap utilisé précedemment utilisait la gestion de la mémoire virtuelle de l'OS Casio tout en écrasant la RAM dans laquelle se trouvait des informations utilisées par ce dernier pour effectuer les translations d'adresse (pas très malin de ma part, surtout que le soucis était invisible avec un binaire de moins de 16kio...).
Pour l'instant le bootloader est directement intégré au G1A qui contient le noyau, et le nom du fichier à charger est configuré en dur à la compilation ("FIXOS.g1a", qui doit se trouver à la racine de la SMEM). Ceci étant dit, il est maintenant facile de séparer les deux, à condition d'ajouter quelques informations de relocation (adresses auxquelles les différentes parties du binaire du noyau doivent être copiées).
Dans ce cas, le noyau serait un binaire sans header G1A, et le bootloader pourrait être configuré assez facilement à partir d'un fichier de config simple placé dans la SMEM, j'essaierait de faire ça d'ici peu. L'intéret est assez limité actuellement mais ce serait beaucoup plus propre.
De même, le programme utilisateur de test est actuellement statiquement lié au binaire du noyau, bien qu'il soit mappé à des adresses différentes de la mémoire virtuelle).
Il s'agit donc plus d'un "proof of concept", la prochaine étape sera l'exécution d'un binaire depuis un fichier de la SMEM.
Tout à l'air de marcher pour le mieux, le processus est cloisoné dans sa mémoire virtuelle et en mode utilisateur, dispose de sa propre stack utilisateur et kernel (2 stack différentes par processus, j'essaie de voir si il n'y a pas une solution moins gourmande en RAM, genre stack kernel partagée, mais c'est pas forcément pratique à mettre en place, donc je verrais plus tard).
Le changement de contexte marche aussi pas trop mal (changement de mode pour être précis, passage du mode protégé/noyau au mode utilisateur, et vice versa).
L'exception inconditionnelle (TRAPA en assembleur) permet de revenir dans le code du noyau, donc plus qu'à implémenter les syscalls qui vont bien et le processus utilisateur pourra faire des choses utiles.
Au passage, petite déception qui m'a coûté pas mal de temps, il semblerait que cette version modifiée du SH3 7705 ne possède pas de gestion hardware de l'ASID (Adress Space IDentifier, utilisé pour indiquer à la partie gestion mémoire du CPU quel processus est en exécution, permettant de filtrer les correspondances mémoire physique <-> mémoire virtuelle déjà présentes selon le processus).
Il y a tout de même moyen de s'en passer sans perdre en fiabilité/sécurité/fonctionnalité, mais on perd un énorme atout des MMU modernes, puisque le noyau va devoir invalider toutes les translations à chaque changement de processus, impliquant en plus des TLB Miss à chaque fois qu'un processus reprendra le controle.
Pour faire simple, les performances en multi-processus seront un poil moins bonne, mais c'est surtout rageant quand on voit que tous les SH3 avec MMU ont cet ASID en interne, et que toutes les fonctionnalités qui pourraient l'utiliser existent sur modèle en particulier >_<"
Autre chose, j'essaie de voir un peu comment fonctionne certains périphériques (EEPROM de la SMEM en mode écriture, accès à la carte SD, etc...), dans le but de coder de quoi y accéder proprement.
J'en profite pour essayer de créer un debugueur/traceur pour avoir directement la trace de chaque branchement effectué par une fonction (en l'occurence les fonctions interne des Bfile_xxx), en utilisant les User Break, un module du CPU permettant de poser des points d'arrêts conditionnels dans l'exécution d'un programme.
Outre le fait que ça pourrait être assez pratique couplé à une connexion au PC pour avoir un debugueur distant (y compris pour déguguer des addins qui n'ont rien à voir avec mon noyau), j'ai aussi dû me plonger dans la gestion des exceptions/interruptions par l'OS de Casio.
En gros, le but était d'avoir configuré le VBR pour qu'il branche dans mon code en cas d'exception, mais que toutes celles qui ne m'intéressaient pas soient traitées par les handler d'exception de l'OS de Casio pour ne pas entraver son fonctionnement pendant le lecture/écriture.
Après quelques heures de galère, de rétro-ingénieurie sur le code de l'OS de Casio, et d'essais, j'ai fini par comprendre une bonne partie de la façon dont cela est traité. Et c'est vraiment pas beau à voir.
Le code de Casio qui gère les exception semble avoir été écrit par un stagiaire (et encore), brise des tonnes de conventions, est particulièrement contre-intuitif, et j'en passe...
Exemple : si le VBR est modifié, l'appel des handlers par un simple saut provoque une boucle infinie. Ou encore une routine est appelée dans les handlers en utilisant l'instruction RTE sans aucune raison valide.
Mieux encore, la valeur du registre de status, SR, est modifiée (chose typique qu'un handler ne doit jamais faire...).
Bref, en conclusion, c'est trèèèèès crade, et ça explique par exemple pourquoi on n'avait jamais réussi à gérer les niveaux de gris tout en autorisant les interruptions pour l'OS.
Pas sûr à 100% que ça règle le reset après les niveaux de gris (encore que j'ai pas tout suivi, c'est peut-être déjà fixé?) mais ça permettrait, par exemple, d'appeler les IsKeyDown de l'OS, et surtout d'avoir les messages TLB Error ou W/R error lors d'un accès à une adresse invalide par un addin utilisant les niveaux de gris (quand on sait décoder ces informations, le debug est plus facile).
Je testerais ces nouveaux handlers sur les niveaux de gris, et j'éditerais/re-posterais si il y a des résultats intéressants.
Pour finir, comme la rétro ingénieurie dans cette jungle est longue et pas toujours super fun, je serais reconaissant si des gens avaient quelques infos sous la main pour me faciliter le boulot.
Je sais que certains sur casiocalc/omnimaga (simlo et compagnie) ont déjà fait de l'écriture sur l'EEPROM, j'essaierais de les contacter ou de poster sur omnimaga à l'occasion.
Pour l'accès à la carte SD, j'avais déjà passé un peu de temps à zieuter, mais pour l'instant aucune piste n'a donné de résultat.
Le code est toujours disponible sur mon dépot gitorious pour les curieux et les motivés (https://www.gitorious.org/fixos/fixos/), mais sa compilation nécessite un G1A Wrapper (trouvable sur mon github), un GCC pour SH qui marche, et une petite modification du Makefile pour donner le nom des outils utilisés.
Au cas où tout de même : testé uniquement sur une G85 SD SH3 en OS 1.00.0000 (sisi, ça existe encore
Possible que sur des G85 (SD) ancien modèle mais avec une autre version de l'OS il y ait des soucis lors du bootloader (l'accès aux fichiers n'a pas été testé, faudra le mettre au point).
Sur les autres modèles, il me faudra des cobayes motivés un de ces jours pour fixer les éventuels soucis.
N'oubliez pas que c'est surtout un projet mené par curiosité, pour faire une preuve de faisabilité de projets semblables, et que pour le moment, le code source est bien plus intéressant que le binaire lui-même
(erf, décidemment je peux pas m'empếcher de faire des pavés, s'doit être génétique en fin de compte Oo)
Citer : Posté le 14/11/2013 19:02 | #
Pour l'accès aux fichiers, je crois que c'est Limachi qui avait cherché à faire sa propre fonction de modification de fichiers, pour palier à ces immondices que sont les BFile_
Au passage, le code sur ton dépôt est au point ? (Genre je peux tester sans trop de problèmes ?)
Citer : Posté le 14/11/2013 19:46 | #
ouaip, et je n'ai pas encore totalement compris le fonctionnement de la mémoire des différentes caltos, donc il y a danger pour l'instant si je venais a tenter autre chose que juste "regarder"
sinon, je suis vraiment content de savoir que tu continue ce projet kristaba, ça fait plus d'un an que je suis le projet et je trouve qu'il arrive quand même a avancer (après, je peux parler car j'ai l'habitude des projets "longs", mon minecraft va bientôt fêter ces 2 ans sans avoir eut une alpha viable)
-en C:
-Un pong.
-Un projet en pause. Je compte le reprendre de temps en temps: Summer Cursed
-mon tuto sur les Str
Mes calto: G25+, G75
Mon minecraft en dévelopement
-Portal2D de JavierXD
-CalCraft de Wime
-GeekBros du groupe GeekBrothers (Eiyeron,Siapran,KevKevVTT,Adbook,LIMachi)
Citer : Posté le 14/11/2013 19:50 | #
Ouai, le problème n'est même pas le fait que ce soit via des fonctions non standard (Bfile and co), mais plus que ces fonctions sont d'une lenteur tellement affolante, je ne comprendrais jamais comment ils ont fait ça...
J'avais re-fait la partie lecture pour faire une lib contenant les fonctionalités de stdio.h (la lecture est très simple, le système de fichier en EEPROM est accessible via des accès mémoire classiques, mais l'écriture demande quelques accès aux adresses qui vont bien pour controller l'écrasement des pages de l'EEPROM toussa).
Le code est loin d'être au point, vu que je n'ai qu'une seule calto pour tester rien ne garantie que certaines choses semblent fonctionner chez moi uniquement à cause / grace à des spécificités de ma calto (modèle, OS, et d'autres trucs qui pourraient jouer).
Après, vu que nul part dans mon code il n'y a de modification de l'EEPROM, la seule possibilité de gros soucis ce serait qu'un saut amène sur un morceau de données qui, coincidence extrème, écraserait des morceaux de l'EEPROM en cas d'exécution (exactemment le même risque qu'avec n'importe quel addin qui bug, que l'on peut considérer négligeable, genre inférieur à une chance sur 2^128 à vu de pif).
Le noyau est chargé en RAM, donc un reset derrière la calto et c'est comme si il n'avait jamais existé
Pour le coup, le jour où il y a des fonctionnalités en écriture dans la SMEM, il faudra être nettement plus prudent (dans l'idéal, faire en sorte que cela soit désactivé lors de la compilation sans ajout d'une ligne dans le Makefile), et faire des tests exhaustifs pour être sûr
Bref, pour le moment pas de risque, à part de galérer pour compiler.
Citer : Posté le 14/11/2013 21:09 | #
oh je ne savais pas qu'il y avait une erreur qui portait l'opposé de mon nom
sinon, bonne continuation et bon courage (il t'en faut beaucoup je le sens) pour cet énorme projet qui avance doucement, mais surement
Jouez à 6 sur une seule calto : Curve Fever
Un die and retry qui vous fera bieeeen rager Test Andropov
un très bon sokoban
le seul vrai jeu de foot en basic : FIFA 12
Ca c'est ce que j'appelle un jeu de reflexion jewel master
Qui vaincra l'intelligence artificielle de cet othello
Le célèbre pacman
Et tant d'autres BTL's games
Le jeu du mois de Novembre et award du jeu le plus dur de l'année 2013
Citer : Posté le 14/11/2013 21:20 | #
Ouai, le problème n'est même pas le fait que ce soit via des fonctions non standard (Bfile and co), mais plus que ces fonctions sont d'une lenteur tellement affolante, je ne comprendrais jamais comment ils ont fait ça...
Lors d'un test, j'ai entre autre trouvé que quand on ouvre ou enregistre un fichier, il y a une fenêtre avec une barre de progression qui s'affiche (visible avec des fichiers très gros, et la fenêtre n’appairait que quelques centièmes de secondes)
Ce qui pour moi explique en partie la lenteur de ces fonctions.
-en C:
-Un pong.
-Un projet en pause. Je compte le reprendre de temps en temps: Summer Cursed
-mon tuto sur les Str
Mes calto: G25+, G75
Mon minecraft en dévelopement
-Portal2D de JavierXD
-CalCraft de Wime
-GeekBros du groupe GeekBrothers (Eiyeron,Siapran,KevKevVTT,Adbook,LIMachi)
Citer : Posté le 15/11/2013 12:52 | #
Ca avance, super
I own a graph 3575+.
Citer : Posté le 16/11/2013 16:00 | #
Ok j'ai rien compris mais je sais que tu avnaces. Bon courage!
Quelqu'un a du doliprane?
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 02/01/2014 15:23 | #
Malgré l'IRL, les périodes de partiels, les fêtes et les divers projets qui trainent à côté, j'ai bossé un peu sur le noyau ces derniers temps.
Petit état de l'avancement des choses, histoire de ne pas perdre mes compétences, qui eurent été fort utiles en mai 68 (ben oui, à l'époque on ne crachait pas sur un beau pavé
Pas mal de changement dans l'architecture générale du projet, pour essayer de garder le code dépendant de l'architecture le plus séparé possible du reste (même si pour le moment, pas mal de choses sont mal pensées de ce côté là, pour éviter de rendre le projet trop complexe avant même qu'il ne soit un poil mature).
Niveau fonctionnalitées, la dernière fois je vous parlait d'écriture sur l'EEPROM et lecture/écriture directe de la carte SD. Pour le moment une première implémentation pour l'EEPROM est codée (permettant l'écriture, l'écrasement de page, l'obtention d'informations sur la puce, comme sa taille, son constructeur, etc...).
Pour la carte SD, grâce à cette foutue "SD Association" qui tient à maintenir certains secrets industriels, Renesas a interdiction formelle de publier les spécification de son implémentation du module SDHI...
J'ai donc passé de longues journées à me taper du code désassemblé de l'OS de Casio pour comprendre comment ça marchait, et autant dire qu'il faut être patient et minutieux...
Pour le moment, et malgré le fait que beaucoup de choses restent assez obscure (pas la moindre documentation en même temps...), j'ai des résultats fort sympathiques, mais pas encore de lecture/écriture de données.
Globalement, j'ai maintenant le code nécessaire à la communication avec la carte, le protocole d'initialisation, et on peu envoyer/recevoir des commandes du protocole SD/SDHC (permettant de récupérer pleins d'informations : constructeur, type de mémoire, temps d'accès, protocoles supportés, taille de la carte, protections en écriture, tensions supportées...). Malheureusement, la lecture de bloc de données ne marche pas encore, et je n'ai pas eu la patience de continuer mes tests pour le moment.
En théorie j'ai le code qui devrait marcher, issue de l'OS de Casio, mais en pratique soit j'ai loupé quelque chose en le décompilant, soit il me manque une partie de l'initialisation.
Bref, ça avance, mais c'est pas encore fonctionnel
Sinon, dans les gros morceaux ajoutés, il y a enfin un système de périphérique (device) à la UNIX, permettant de faire un lien à l'exécution entre un "pilote" de périphérique et des noeuds du système de fichier.
Le seul device implémenté pour le moment est destiné à être le terminal "primaire", utilisant l'écran de la calto pour afficher (et quand ce sera implémenté, le clavier pour l'entrée). Le but sera de suivre les caractères d'échapement style VT100, et les ioctls UNIX de controle des TTY.
Le périphérique est rendu accessible à l'initialisation via le fichier /dev/console, et est utilisé par le noyau pour les logs de debug dès que les modules nécessaires (surtout le Virtual File System) sont fonctionnels. De plus, une implémentation beaucoup plus "statique" et non extensible est utilisée en tant que "early terminal", pour permettre le debug avant que le VFS et le terminal soient disponibles.
Le système de fichier "smemfs", permettant d'accèder aux fichiers de la SMEM, a été en partie réécrit pour être plus lisible et maintenable. En gros, il avait été écrit en étant "orienté vecteur de caractères" (manipulant des char* à foison pour accèder aux méta-informations du système de fichier), et est maintenant "orienté structures", donc définissant et utilisant des structures de données dès que possible.
Autant dire que ça a bien gagné en lisibilité...
Toujours pas d'écriture de fichiers malgré les fonctionnalités disponibles pour l'écriture de l'EEPROM, ça me fait toujours un peu froid dans le dos de toucher à ça, je verrais quand le reste sera plus stable.
Dernière grosse chose, et pas des moindres : l'espace utilisateur commence à être vivaaaaaaaant! \o/
J'ai implémenté une version minimaliste de la lecture des fichiers ELF (wikipedia pour les curieux), ce qui permet désormais d'utiliser une chaine de compilation GCC sans aucun programme maison pour créer un programme pour FiXos.
Les entêtes et méta-informations du format ELF sont potentiellement volumineuses, mais il est possible de réduire énormément ce volume en précisant à ld ou objcopy de ne pas mettre ce qui n'est pas indispensable à l'exécution (surtout les symboles de débugages, souvent plus lourde que le binaire lui-même...).
Actuellement, seul les segments sont utilisés, ce qui permet de gérer correctement un simple exécutable (mais pas un exécutable avec édition des liens dynamique, ni de bibliothèque partagée, ce sera pour plus tard).
Dans le même temps, les premiers appels systèmes à la base même d'UNIX sont disponibles : open(), read() et write()
Petit aperçu du code d'un programme utilisateur "hello world" :
[purple]int[/purple] main() {
[green]// try to open [gray]"/dev/console"[/gray], open mode is not implemented [b][blue]for[/blue][/b] now[/green]
[purple]int[/purple] fd;
fd = open([gray]"/dev/console"[/gray], [maroon]0[/maroon]);
[b][blue]if[/blue][/b](fd != -1) {
write(fd, [gray]"Hello FiXos!\n", sizeof("Hello FiXos!\n"[/gray])-1);
}
[green]// never [b][blue]return[/blue][/b] (no exit() syscall)[/green]
[b][blue]while[/blue][/b](1);
[b][blue]return[/blue][/b] 0;
}
Bref, il manque encore plein de choses, mais ça commence à avoir la gueule d'un noyau
Comme toujours, les curieux peuvent faire un tour sur le gitorious du projet pour voir à quoi ça ressemble (aspirine non fournie).
Et bonne année à tous, tant que j'y suis!
Citer : Posté le 04/01/2014 20:03 | #
Tu m'impressionneras toujours !
Vitesse des fonctions en Basic Casio | 7 days CPC | Casio Universal Wiki | Tutoriel Basic Casio
>>> Give me a click Brother
>>> Random Youtube Video
Citer : Posté le 13/01/2014 11:45 | #
J'ai un petit peu l'impression de transformer ce topic en blog à force, mais j'espère que tout cela intéresse(ra?) quelques personnes
Donc j'ai passé les 10 derniers jours à essayer de jouer avec l'USB (encore un délire qui est loin d'être primordial à un noyau, mais ça semblait amusant).
Le but que j'avais en tête était d'avoir une implémentation d'un périhérique USB type "émulateur de port série" (utilisé par pas mal de petits périphériques pour communiquer avec un PC à faible cout, l'implémentation est assez générique et tous les OS modernes ont les drivers qu'il faut pour que ça apparaisse comme un port série classique côté utilisateur sur le PC -> les arduinos, certains téléphones, etc...). Avec un tel dispositif, le gros avantage est l'affichage des logs de debug et de la console virtuelle sur un dispositif avec un cran bien plus grand et bien plus de mémoire que la calto, me permettant d'avoir un historique complet et verbeux de tout ce qu'il se passe dans le noyau.
N'ayant jamais touché à l'USB aussi bas niveau, il a fallu qe je me tappe pas mal de théorie, mais heureusement, contrairement à la carte SD, le périphérique de controle de l'USB sur le CPU est bien documenté par Renesas.
Il a tout de même fallu tapper un peu dans le code de l'OS de Casio pour comprendre comment passer le D+ de l'USB en pull-up (indispensable pour savoir si le port est relié à un hôte, et sans quoi l'hôte ne se rendra jamais compte du périphérique nouvellement branché).
Et comme je craignais, Casio a fait une petite blague en utilisant un bit d'un port non documenté pour cela (le même port qui controle l'alimentation de la carte SD, par ailleurs).
Bref, mis à part cela, pas mal de galère pour bien comprendre les mécanismes un peu magique de l'USB, et répondre correctement à l'hôte, mais là c'est uniquement de ma faute.
Tout cela résulte au final en :
- une implémentation de l'USB device qui se veut totalement abstraite de la plateforme, et assez facilement portable (les classes USB implémentées et utilisant uniquement ces interfaces sont portables dès que l'interface USB device est écrite correctement pour une nouvelle plateforme)
- une implémentation assez basique mais fonctionnelle de la classe CDC/ACM, résulant dans notre cas à une émulation de port série/modem
- une implémentation d'un périphérique correspondant au canal de communication résultant de CDC
Le périphérique est lié à l'initialisation du noyau au fichier /dev/serial, et permet donc à l'espace utilisateur et au noyau de profiter de open/read/write (pas encore d'ioctls mais ça viendra).
Petit code de démonstration pour un process utilisateur qui va renvoyer l'echo de chaque caractère envoyé sur le port série virtuel :
fd_serial = open([gray]"/dev/serial"[/gray], 0);
[purple]int[/purple] nbread;
[purple]char[/purple] c;
[green]// never [b][blue]return[/blue][/b][/green]
[b][blue]while[/blue][/b](1) {
[green]// do a simple 'echo' of each byte received from /dev/serial[/green]
[b][blue]if[/blue][/b]((nbread = read(fd_serial, buf, [maroon]1[/maroon])) > 0) {
write(fd_serial, buf, nbread);
}
}
Combiné à l'utilisation d'un programme dans le genre Hyperterminal/gtkterm, on a la possibilité d'utiliser un véritable terminal VT100 pour l'affichage, et le clavier d'un ordi en temps qu'entrée standard.
Cette petite expérience m'a aussi permis de combler quelques gros bug liés au changement de contexte utilisateur -> trapa -> interruption, à côté desquelles j'étais passé sans les voir...
Prochaine étape si j'ai toujours la motivation : le début du multi-process (ordonnancement, fork, exec, et tout le bordel).
Citer : Posté le 13/01/2014 15:54 | #
Je rejoins Totoyo, au passage.
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 13/01/2014 16:56 | #
Pour le serial USB, tu pense tourner à combien de baud environ ? On en est pas encore là, mais pour du transfert de fichier, si tu veux que je fasse une partie, je peux toujours me demander, surtout si le proto se fait en liaison série (mais en ligne de commande pour commencer).
Bonne chance pour le multi-process, c'est pas du tout le plus simple. En tout cas, tant mieux si du coup t'arrive à avoir un aperçu pour debugger sur l'ordi.