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 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.
Citer : Posté le 13/01/2014 18:00 | #
Pour le serial USB, tu pense tourner à combien de baud environ ?
En fait, avec CDC, le débit de la ligne est purement indicatif, et c'est le pilote (à la fois côté hôte et device) qui gère la vitesse des transferts. En théorie on est à la vitesse de l'USB, moins les diverses bricoles qui utilisent la bande passante du bus (je configure en USB 2.0 full speed -pas High Speed-, donc 1.5Mo/s théoriques.
En pratique, le débit est beaucou plus faible, mais difficile de donner une valeur précise.
Je pense qu'en faisant quelque chose en espace noyau, sans passer par les interruptions tant que c'est possible, on doit être proche de 200ko/s à la fois montant et descendant, mais à vue de nez.
Dans l'exemple donné, il y a des context switch (c'est un programme utilisateur), plein d'abstractions (passer par l'appel système, la fonction générique de lecture/écriture dans le VFS, la fonction spécifique du device driver, celle de l'USB...).
Sachant que dans l'exemple donné ces opérations sont effectuées 2 fois par caractère (syscall read, puis syscall write), c'est le facteur limitant, et le débit est de 3ko/s (encore une fois, 3ko/s montant ET descendant) d'après un petit test avec dd sous linux.
J'ai fait un autre test, avec un buffer de 64 caractères au lieu d'un seul, et ça monte à presque 40ko/s.
C'est juste un ordre d'idées, et une partie de la réception de données est à optimiser (une histoire de buffer que je dois memcpy() à chaque fois qu'une partie est lue, y'a moyen de faire beaucoup plus rapide avec une implémentation basique de FIFO 'cyclique', je ferais ça pour voir si ça fait de la différence).
Ce qui est sûr c'est que je suis obligé de répondre avec des "Not ACKnowledge" à l'hôte pour ralentir le flux, sans quoi le buffer logiciel de l'endpoint qui reçoit les données est saturé en permanance...
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).
Pour être honnète, j'aurais préféré implémenter la classe USB MSC (Mass Storage), pour que la calto soit reconnue comme une clé USB ou autre (il me semble que dans les OS récents de Casio c'est le cas d'ailleurs, bon point pour eux).
Par contre ça va demander de la bricole violente pour faire passer la SMEM là dessus, sachant que ce n'est pas du tout un système de fichiers traditionnel, qu'on a pas de véritable MBR en dur quelque part, etc...
Cela implquerais de transformer à la volée toutes les infos pour faire croire que la SMEM est un système FAT16 par exemple (faisable, mais compliqué et potentiellement gourmand en mémoire et CPU...).
Dans tous les cas, je ne rendrais probablement pas visible l'intégralité du VFS, le protocol me semble pas adapté, bien que je n'ai pas regardé toutes les specs techniques.
En tous cas merci de proposer, si tu te sens motivé tu peux toujours zieuter la doc de la classe MSC pour voir si tu te sens de l'implémenter en totalité, en partie, ou juste pour filer un coup de main occasionnel
Citer : Posté le 13/01/2014 18:45 | #
Pas faux pour la classe MSC. Je n'y ai pas pensé mais c'est bien plus pratique.
Sur les OS actuels, le système de gestion des fichiers est obscur où ça reste correctement documenté ?
Mais comme tu dis, installer de quelque manière que ce soit un système de fichiers en FAT16 doit demander pas mal de boulot, sans parler d'un quelconque VFS.
Toi aussi t'as lu la doc "L'USB en bref" ?
Elle fait 70 pages environ
Ajouté le 13/01/2014 à 18:58 :
Au passage, que faut-il compiler sur le projet ?
Je me ballade, mais j'ai pas vu vraiment de fonction "main", donc bon...
Ajouté le 13/01/2014 à 18:59 :
Et le README est pas très explicite
Citer : Posté le 14/01/2014 01:35 | #
Au passage, que faut-il compiler sur le projet ?
Je me ballade, mais j'ai pas vu vraiment de fonction "main", donc bon...
Oui, c'est normal, y'a pas vraiment de 'main' dans un projet comme ça.
En plus c'est un peu spécial puisque, actuellement, le bootloader et le noyau sont mélangés dans un même binaire (plus pratique et pas besoin de plus pour le moment, mais quand j'aurais le temps je ferais un bootloader depuis un fichier ELF pour que ce soit plus propre, et qui permette la sélection dans le système de fichier, ou qui soit au minimum configurable via un petit fichier
Donc en résumé :
Point d'entrée du G1A -> "bootstrap" dans "bootloader/bootloader_pre.s"
Une fois que la pile est configurée, "bootstrap" saute à "bootloader_init" situé dans "bootloader/bootloader.c", qui se charge de chercher le fichier "FIXOS.g1a" situé à la racine de la SMEM (oui, c'est hardcodé, c'est crade, et je compte réécrire tout ça rapidement
Une fois que tout est copié (exécutable, variables globales), "bootloader_init" appel la fonction "initialize" qui est le point d'entrée du noyau, situé dans "initialize.s".
Cette fonction prépare le terrain pour le code en C, et une fois fait, elle saute à "init" situé dans "init.c".
En sur-résumé -> la chose la plus proche d'un "main" c'est "init".
Après tout ça ne t'aideras pas à compiler le projet.
Quelques infos pas à jour sont présentes sur la page du projet, mais globalement :
- il faut une toolchain GCC (le compilo Renesas serait pas foutu de compiler la moitié du code, de faire l'édition des liens complexe, etc...)
- il vaut mieux utiliser "make", sans quoi je te laisse voir ce que fait le Makefile, mais c'est pas trivial, et chiant à faire à la main...
Toutes les infos que tu cherche sont dans le Makefile en tous cas, et dans l'obscure "fixos.ld", script pour l'édition des liens, mais faut être motivé là par contre >_<'
Sur les OS actuels, le système de gestion des fichiers est obscur où ça reste correctement documenté ?
Système de fichier maison de chez Casio, aucune documentation officiel, mais du travail de rétro-ingénieurie de plusieurs personnes (j'ai vu du code de simlo qui y accède, mais j'avais fait un truc plus poussé pour un projet précédent, je me suis basé sur mes travaux pour le SMEM). Si ça t'intéresse, j'ai tout réécrit récemment, dans "fs/casio_smemfs/smemfs_primitives_ng.[hc]". C'est pas très documenté, mais le code est compréhensible, et les structures de données parlent d'elles-même.
Le code fonctionne nickel sur toutes les G85 et G85SD que j'ai testé en OS < 2, et je crois pas que l'OS 2.x change le système de fichier, mais dans le pire des cas l'écriture n'est toujours pas implémentée (peur de cramer la calto, et ça peut encore attendre), donc rien ne marchera mais peu de chance que ce soit domageable.
Dernier point, si tu réussi à tout compiler, je te déconseille fortement de décommenter la ligne "//test_eeprom();", c'est le seul code qui va essayer d'écrire sur l'EEPROM, et le bloc effacé et ré-écrit est connu pour être libre sur l'OS 1.x mais utilisé sur l'OS 2.x, donc évitons les ennuis
Citer : Posté le 14/01/2014 20:59 | #
Plus sérieusement je te souhaite bonne chance, il faut en avoir du courage pour bosser sur un projet pareil depuis plus de deux ans (créer un O.S. quand même)
Citer : Posté le 15/01/2014 09:12 | #
Quels paves ! Et rien que pour moi
Du coup je vais voir, merci pour ta réponse.
Si j'ai des questions, je reviendrais de toute façon
Citer : Posté le 15/01/2014 12:53 | #
D'ailleurs au passage, tu dis que c'est pour graph 85 mais uniquement? genre t'as besoin de stocker des données sur la sd? Parce que un unix-like sur 35/75 ca serait top
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 15/01/2014 16:18 | #
C'est a destination des G75/85/95 et des Prizm
Mais du coup, les G35+USB sont concernées.
Citer : Posté le 19/01/2014 09:47 | #
Ah bon
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 19/01/2014 11:46 | #
Je crois que Kristaba a une Graph 85 SD. A ce sujet, ton projet est-il compatible avec toutes les graph 35+ USB/75/85/95 (SD) SH 3A et SH4 ou est spécifique à certains modèles ?
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 19/01/2014 20:45 | #
Pour le moment, la seule compatibilité que j'assure c'est la G85 et G85SD, car ce sont les deux seules machines de test que j'ai sous la main.
Ensuite, il faut voir trois choses dans le projet :
- le code arch-specific, qui dépend du type de CPU, et qui doit sensiblement varier selon la calc (surtout pour les SH4, le code actuel doit être adapté)
- le code plateform-specific, qui dépend de l'ensemble de la plateforme d'exécution (exemple typique : le display driver ou le clavier), dont certaines parties doivent être réécrites selon le modèle de calc (je crois que le T6K11 est utilisé sur toutes les monochromes pour l'affichage, mais l'EEPROM par exemple n'est pas forcément la même, la disposition du clavier non plus, l'USB et la carte SD pareil)
- le code générique, qui s'appuis sur la suposition que le code arch- et plateform-specific met à disposition une interface donnée et n'utilise directement aucune information dépendant de la plateforme
Dans un noyau idéal, tout est bien différencié, et le portage sur une nouvelle plateforme n'implique qu'une réécriture du code arch-specific (si c'est un nouveau processeur) et plateform-specific (pour chaque périphérique défini au niveau de la plateforme).
Pour le moment, dans FiXos, il y a des parties plus ou moins bien séparées (par exemple au niveau de l'USB, la séparation est suffisante pour que les classes de périphériques USB soient implémentées à 100% générique), mais certaines parties qui devraient être génériques utilisent des supposition dont la validité dépend de l'architecture, comme la taille des pages de mémoire.
Ce dernier point fait que l'adaptation à une autre plateforme va impliquer quelques modifs pour rendre le noyau plus souple, et qui seront d'autant plus importantes que les architectures/plateformes seront différentes.
Concrètement, le portage sur les modèles SH4 devraient pas être trop dur car très proches de l'architecture actuellement supportée, mais le portage sur Prizm le sera un peu plus (les périphériques sont assez différents, le système de fichier probablement modifié, etc...), et le portage sur une TI89 encore plus (seul le code générique serait conservé).
Quand le besoin s'en fera sentir, il faudra de toutes façons que je trouve une machine de test pour les SH4.
Sinon, je me demande si je ferais pas un portage sur x86 ou m68k/TI89 à un moment, histoire de rendre le code vraiment propre au niveau de la séparation architecture/générique...
En ce qui concerne l'avancement de la semaine :
Après la dernière explication sur le bootloader/bootstrap du noyau, je me suis rapellé que j'avais fait quelque chose de vraiment temporaire et assez crade pour le bootloader.
J'ai donc recodé un bootloader entièrement indépendant, capable de lire un fichier de configuration pour changer facilement le/les noyaux utilisés, argument donnés, et informations affichées.
Il en résulte un G1A qui contient le bootloader, implémentant une version simplifiée de l'accès au système de fichiers de la SMEM, et qui charge le noyau depuis un fichier ELF dont le chemin est donné dans le fichier de configuration.
Il supporte pour le moment jusqu'à 3 entrées différentes, chacune avec un label, le chemin du noyau à lancer, son type (uniquement ELF supporté), et éventuellement les arguments à passer au noyau (mais la fonctionnalité n'est pas encore gérée dans le noyau, disons que ça se prépare >_<').
On peut également le passer en mode 'silencieux' depuis le fichier de config, pour lancer l'entrée par défaut sans interface utilisateur.
On va dire que c'était indispensable pour avoir quelque chose d'à peu près propre, d'autant plus qu'en utilisant ELF comme format pour le noyau, il ne dépend plus du format G1A et similaire de Casio, et que le bootstraping est enfin totalement externe au noyau (c'est le bootloader qui recopie chacune des sections du binaire dans la mémoire).
Par ailleurs, il n'est absolument pas spécifique à FiXos, et peut être, une fois compilé, utilisé pour un autre projet de noyau (ben oui, soyez curieux vous aussi!).
L'autre avancée de ces derniers jours, c'est le début du support du multi-process (que je pensais commencer avant, mais le bootloader était pas prévu dans le planning, et m'a pris plus de temps que prévu grace à une connerie qui trainait dans la lecture du système de fichier SMEM et qui s'est révélée à ce moment là
Pour l'instant rien de transcendant, surtout des changements mineurs pour supporter plusieurs contextes d'exécution en même temps. Le scheduler est une implémentation temporaire et pas du tout optimisée, mais ça semble marcher correctement.
Le test se fait avec deux processus indépendants, et le changement de contexte est déclenché par l'appuis sur une touche. Je dois maintenant gérer un timer pour le temps d'exécution, mettre un vrai scheduler (surement du round-robin), et faire les appels systèmes fork()/getpid()/getppid().
Bref, dans pas longtemps on devrait pouvoir se faire de jolies fork-bomb, ça va être joyeux je sens
Citer : Posté le 25/01/2014 13:14 | #
Donc dans ce que j'ai compris, t'avances bien et quand aux ports sur des caltos types 35/75 sh4 ca devrait pas prendre plus d'un mois entre fixos 85 et le port
Faut que j'aille me racheter du doliprane maintenant.
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 23/03/2014 19:53 | #
Quelqu'un a des nouvelles du projet ? Ça fait longtemps que Kristaba ne nous a pas fait un de ses pavés
Coïncidence ? Je ne pense pas.
Citer : Posté le 23/03/2014 19:56 | #
En tout cas, il s'est connecté aujourd'hui
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 24/03/2014 17:29 | #
Cool !
Coïncidence ? Je ne pense pas.
Bobage Invité
Citer : Posté le 10/06/2014 12:13 | #
Pourquoi pour le moment ne pas utiliser la calculatrice comme simple terminal. ça serait déjà super.
Kristaba t'es super intelligent, et gnuisto tu comprendras que c'est la pure galère de faire marcher un truc bidouiller soit même sur une machine qui n'a pas prévu ça. Je ne dis pas que c'est peine perdu, mais que finalement autant bidouiller une calculatrice soit même au lieu d'essayer de bidouiller ce truc.
Surtout que tout ce que tu parles existes déjà, et au lieu de reconstruire la roue autour d'un système sur un kernel linux bis que t'aura bidouiller, autant essayer de faire avec ce qui existe déjà.
Soit faire la calculatrice un terminal (par bluetooth ex - donc accès à Gnuilo avec son daemon qui va bien pour envoyer les données à la calculatrice), ou construire la calculatrice de zéro avec des composants libre - comme je l'espérrai et l'espère toujours depuis des années.
J'aimerai par exemple transformer ma calculatrice en gps device (pour les ballades). L'ordinateur sur le dos, ou sur le porte bagage aura un gnuilo qui tournera et transmettra les données en bluetooth. C'est comme ça que je vois mon truc, je n'ai encore rien fais, mais finalement, tu te casses sans doute trop la tête.
Bon courage,
Libere.
Citer : Posté le 10/06/2014 14:39 | #
Salut Dafp (si mes suppositions sont pas trop mauvaises), ça faisait un moment.
Je ne dis pas que c'est peine perdu, mais que finalement autant bidouiller une calculatrice soit même au lieu d'essayer de bidouiller ce truc.
Surtout que tout ce que tu parles existes déjà, et au lieu de reconstruire la roue autour d'un système sur un kernel linux bis que t'aura bidouiller, autant essayer de faire avec ce qui existe déjà.
tu te casses sans doute trop la tête.
Le problème, c'est que des fois c'est vraiment pour le plaisir de me casser la tête que je bosse.
Même le fait de bosser sur une machine dont la specification est très limitée est intéressant : ça apprend des techniques de rétro-ingénieurie, ça permet d'être dans un état "d'exploration", intrigué par tout ce qu'on trouve et toujours prêt à découvrir une nouvelle horreur de Casio, ou un petit truc sympatique que personne n'avait exploité avant
Oui, bien entendu, en terme d'efficacité, et surtout de liberté, je donnerais beaucoup pour travailler avec un matériel connu, libre, et bien documenté. Mais pour le moment, il n'y a pas de tel matériel, donc je m'amuse avec ce que j'ai sous la main et que je connais assez bien désormais.
Surtout que tout ce que tu parles existes déjà, et au lieu de reconstruire la roue autour d'un système sur un kernel linux bis que t'aura bidouiller, autant essayer de faire avec ce qui existe déjà.
En plus du fait que c'est surtout dans un but d'apprentissage que je fais ça, c'est un GNU/Linux (et encore moins un GNU/Hurd) qui serait adapté à une machine embarquée aussi légère.
256Kio de RAM dans le meilleurs des cas, pas de swapage efficace sur de l'EEPROM, matériel particulier....
Autant il y a d'autres noyaux qui seraient possiblement adaptables (noyaux temps réels pour l'embarqué), autant, avec toute l'affection que je lui porte, Linux n'est pas adapté à de l'embarqué aussi léger (ça pourrait se customiser pour tourner vite fait, mais ce serait du bricolage de l'extrème et on perdrait énormément de fonctionnalités).
Même avec un noyau Posix fonctionnel, va jeter un coup d'oeil à la taille des exécutables pour avoir un "simple daemon qui va bien en bluetooth", c'est gros une calto.
ou construire la calculatrice de zéro avec des composants libre - comme je l'espérrai et l'espère toujours depuis des années.
C'est un projet dont je souhaite un aboutissement un jour, mais ça risque d'être difficile.
Dans tous les cas, n'oublie jamais que la première raison de programmer, pour moi, c'est qu'il s'agit d'un jeu d'esprit, et qu'un projet comme FiXos 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.
Arrêter de coder pour le fun, ce serait pousser l'esprit du libre tellement loin qu'il deviendrait paradoxal : la première forme de liberté, c'est de faire ce qui nous fait plaisir, non?
Continue à être libre, et à apporter cet esprit autour de toi!
bobage Invité
Citer : Posté le 10/06/2014 20:28 | #
Salut Dafp (si mes suppositions sont pas trop mauvaises), ça faisait un moment.
Je ne dis pas que c'est peine perdu, mais que finalement autant bidouiller une calculatrice soit même au lieu d'essayer de bidouiller ce truc.
Surtout que tout ce que tu parles existes déjà, et au lieu de reconstruire la roue autour d'un système sur un kernel linux bis que t'aura bidouiller, autant essayer de faire avec ce qui existe déjà.
tu te casses sans doute trop la tête.
Le problème, c'est que des fois c'est vraiment pour le plaisir de me casser la tête que je bosse.
Même le fait de bosser sur une machine dont la specification est très limitée est intéressant : ça apprend des techniques de rétro-ingénieurie, ça permet d'être dans un état "d'exploration", intrigué par tout ce qu'on trouve et toujours prêt à découvrir une nouvelle horreur de Casio, ou un petit truc sympatique que personne n'avait exploité avant
Et c'est bien utile les gens comme toi. C'est quelque chose de très dur, mais qui pourrait être évité s'il y avait un certains accord entre chaque acteurs : les utilisateurs et les constructeurs.
ça me plait, j'en ai fais, dans un moindre niveau, certes, mais c'est énervant.
Quand on souhaite faire autre chose que faire ça pour s'amuser et souhaiter se rendre utile, ça coince. On a l'impression de perdre du temps. C'est pas comme si la calculatrice libre ne pouvait pas être construite. Je m'y connais pas assez, mais foutre dieu, que j'aimerai voir ça. Pourquoi ne pas faire ça sur un appareil comme l'openMoko par exemple, ou sur autre projet que je connais plus le nom (un mini pc à hardware libre).
Certes c'est pas la même chose, et simplement pour l'envie de ne pas jeter ma calculatrice (vive le recyclage), j'aimerai en faire quelque chose d'autre. FixOs? Ou autre...?
Bon courage en tout cas, je ne m'y oppose pas non plus - du tout.
Oui, bien entendu, en terme d'efficacité, et surtout de liberté, je donnerais beaucoup pour travailler avec un matériel connu, libre, et bien documenté. Mais pour le moment, il n'y a pas de tel matériel, donc je m'amuse avec ce que j'ai sous la main et que je connais assez bien désormais.
Surtout ça coûte. Moi j'en ai pas les moyens, pas les connaissances, autant faire avec ce qu'on a déjà, en effet
En plus du fait que c'est surtout dans un but d'apprentissage que je fais ça, c'est un GNU/Linux (et encore moins un GNU/Hurd) qui serait adapté à une machine embarquée aussi légère.
256Kio de RAM dans le meilleurs des cas, pas de swapage efficace sur de l'EEPROM, matériel particulier....
Autant il y a d'autres noyaux qui seraient possiblement adaptables (noyaux temps réels pour l'embarqué), autant, avec toute l'affection que je lui porte, Linux n'est pas adapté à de l'embarqué aussi léger (ça pourrait se customiser pour tourner vite fait, mais ce serait du bricolage de l'extrème et on perdrait énormément de fonctionnalités).
Même avec un noyau Posix fonctionnel, va jeter un coup d'oeil à la taille des exécutables pour avoir un "simple daemon qui va bien en bluetooth", c'est gros une calto.
Non cette histoire de daemon qui gérerait le bluetooth serait sur le serveur. Moi je parlais d'utilisais la calculatrice comme terminal. Pourquoi ne pas le faire directement à partir d'un cable, c'est juste que le sans fil ça semble plus pratique pour ce que je souhaite.
Pour ce qui est de linux, je ne m'y connais pas assez, mais je suppose qu'il existe déjà des noyaux libre s'installant sur des systèmes qui s'apparente à la calculatrice? Pour ce qui est de l'espace des exécutable, je pense que dans un premier temps, je ne pense pas que ça soit une contrainte. C'est sûr que dans un système obscur, le mieux est de recommencer de zéro. Beaucoup de choses ne seront pas possible, mais le luxe et l'objectif (je pense très important et obligatoire) serait d'avoir quelque chose de compatible avec ce qu'il existe déjà avec les systèmes Nix. Tu me diras pas le contraire.
C'est un projet dont je souhaite un aboutissement un jour, mais ça risque d'être difficile.
Non des mini-ordinateurs libre existe déjà. ça reste un pc, mais ça ne coûte rien de le transformer à une calculatrice (un des projets tournait sur openwrt - sur librewrt si on veut - si tu veux je peux retrouver le nom de la machine, mais j'ai pas les favoris à disposition direct).
Dans tous les cas, n'oublie jamais que la première raison de programmer, pour moi, c'est qu'il s'agit d'un jeu d'esprit, et qu'un projet comme FiXos 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.
Arrêter de coder pour le fun, ce serait pousser l'esprit du libre tellement loin qu'il deviendrait paradoxal : la première forme de liberté, c'est de faire ce qui nous fait plaisir, non?
Continue à être libre, et à apporter cet esprit autour de toi!
"la première forme de liberté, c'est de faire ce qui nous fait plaisir" : je suis le premier à te le dire. C'est simplement dommage de passer du temps sur une machine qui ne souhaite pas être coopératrice alors qu'autour de l'informatique, il y a des projets incroyablement intéressant et primordiale pour conserver et protéger notre liberté.
Après tu fais ce que tu veux.
Bref.
Bon courage, et je suis dispo pour t'aider s'il le faut.
Citer : Posté le 12/06/2014 18:48 | #
Re de passage ici, j'ai enfin réussi à compiler un cross-compilateur GCC pour les SH3, ainsi que tout ce qui va avec
Donc je clone le repo git, je me place à la racine du bootloader, je fais un petit make all, et il me sort le bootlaoder en format g1a. Jusque là tout va bien, les problèmes arrivent maintenant :
Je fait un make all à la racine du dossier fixos, il me compile une partie puis j'obtiens ça :
/home/admin/Desktop/FiXos/fixos/arch/sh/modules/usb.c:383: undefined reference to `___udivsi3'
arch/sh/freq.o: In function `freq_time_calibrate':
/home/admin/Desktop/FiXos/fixos/arch/sh/freq.c:74: undefined reference to `___udivsi3'
arch/sh/freq.o: In function `freq_get_peripheral_hz':
/home/admin/Desktop/FiXos/fixos/arch/sh/freq.c:84: undefined reference to `___udivsi3'
arch/sh/freq.o: In function `freq_get_internal_hz':
/home/admin/Desktop/FiXos/fixos/arch/sh/freq.c:89: undefined reference to `___udivsi3'
utils/cyclic_fifo.o: In function `cfifo_push':
/home/admin/Desktop/FiXos/fixos/utils/cyclic_fifo.c:35: undefined reference to `___udivsi3'
utils/cyclic_fifo.o:/home/admin/Desktop/FiXos/fixos/utils/cyclic_fifo.c:67: more undefined references to `___udivsi3' follow
collect2: error: ld returned 1 exit status
make: *** [fixos] Erreur 1
Bref, comment régler ce problème ?
Citer : Posté le 29/07/2014 14:26 | #
Je viens de me rendre compte que depuis que je met à jour le topic sur omnimaga, je ne donne pratiquement plus aucune nouvelle de l'avancement de FiXos sur PC.
Je vais faire un petit résumé, mais vous pouvez suivre un peu mieux via le topic en question si l'anglais ne vous pose pas trop de problème, ou via la traduction de Lionel Debroux sur TI-Planet (j'en profite pour le remercier grandement
Le noyau a énormément évolué depuis mon dernier update sur ce topic (qui date quand même de janvier, honte à moi...). En gros, on est passé de quelque chose d'expérimental et totalement inutilisable à un noyau qui supporte une bonne partie de ce qui est attendu pour faire fonctionner des programmes utilisateurs.
L'environnement est désormais multi-processus (l'ordonanceur est toujours en carton, mais c'est presque du détail à régler plus tard), le système de fichiers virtuel (VFS) fonctionne plutot bien (en lecture seule sur la SMEM, mais je commence à avoir assez confiance envers le noyau pour ajouter l'écriture un de ces jours), les signaux UNIX sont implémentés (seule une partie des signaux est utilisable, histoire d'économiser un peu la RAM). La mémoire dynamique (heap) est fonctionnelle, ce qui permet d'implémenter malloc() et companie, et un proof-of-concept de bibliothèques dynamiques fonctionne aussi, même si des améliorations seraient nécessaires pour une utilisation dans certains cas.
Il est possible d'inspecter des paramètres du noyau avec des syscalls inspirés de sysctl() de BSD, et entre autres choses d'obtenir les informations sur les processus en cours d'exécution (pour implémenter ps, top, et d'autres utilitaires UNIX habituels).
Un travail a également été fait sur l'utilisation de l'écran/clavier le plus directement possible, pour permettre l'écriture de programmes "graphiques". Ils sont accessibles via des devices (/dev/keyboard et /dev/display), et fonctionne suffisamment bien pour supporter un portage de MonochromeLib et des fonctions IsKeyDown()/GetKey(), qui me semblent être les fonctionnalités nécessaires pour écrire des applications de type jeux/GUI. Je rappelle encore une fois que ce type d'application n'est pas la cible primaire du noyau, mais vu que tout fonctionne mieux que je ne l'espérais l'année dernière, elles sont apparues plus faciles à supporter que prévu, donc j'ai quand même posé les bases nécessaires.
Pour les programmes UNIX-like, en console, l'implémentation actuelle gère des terminaux virtuels (un nombre de TTYs fixé à la compilation, 2 à 4 me semble raisonnable), ainsi que la sortie USB ACM/CDC qui permet d'utiliser un émulateur de terminal sur un ordinateur auquel est reliée la calto (surtout pour débuguer du coup).
Pour donner une petite idée, voici la liste des syscalls actuellement supportés, par catégorie :
open()
close()
read()
write()
lseek()
stat()
fstat()
ioctl()
pipe2()
getdents()
Processus
_exit()
fork()
wait()
execve()
getpid()
getppid()
setpgid()
getpgid()
chdir()
fchdir()
times()
Signaux UNIX
sigaction()
kill()
sigprocmask()
sigreturn() (non destiné à l'utilisation explicite)
Inspection des informations du noyau
sysctl_read()
sysctl_write()
sysctl_mibname()
Divers
gettimeofday()
sbrk()
nanosleep()
dynbind() (pour la résolution de symboles dynamiques)
Le noyau fonctionne assez bien pour porter des choses conséquentes pour l'espace utilisateur (les expérimentation pour une libc basée sur Newlib sont assez positive, les fonctionnalités "système" sont maintenant suffisantes pour écrire un shell et des utilitaires tels que ps, top, ls...
Un portage assez expérimental, mais totalement fonctionnel de Gravity Duck a aussi montré la faisabilité d'applications plus "traditionnelles" sur calto.
Maintenant, il va falloir s'assurer que tout fonctionne normalement sur les modèles proches, et sur les caltos avec des versions différentes de l'OS Casio (il y a probablement des choses qui marchent chez moi alors que ce n'est pas le cas partout, et sans autre personne pour tester il est difficile de repérer ce genre d'erreurs).
Citer : Posté le 29/07/2014 15:09 | #
Je t'avais proposé mon aide, mais c'était pendant le bac, et depuis j'ai changé d'ordi donc il faut que je me retape la compil de GCC
Je fais ça dès que j'ai un peu de temps. Bref, je suis curieux de voir ce que ça donne
PS: j'ai du mal à cloner le projet, il me dit que j'ai pas les droits, c'est normal ?
Ajouté le 29/07/2014 à 15:13 :
Edit : pour le git, j'ai résolu le problème, ça venait de ma clé SSH
Ajouté le 29/07/2014 à 17:13 :
Finalement, le fichier bootldr.cfg est bien en UNIX-like, donc le problème vient bien de la lecture de la SMEM...
Pour rappel, j'ai une G35++ SH3 sous OS 02.01.2200