Vhex est le nom donné à un regroupement de projet permettant de facilité à la création de jeux vidéo et d'utilitaire bas-niveau pouvant aller jusqu'à la conception de noyau sur des plateformes embarquées.
L'objectif derrière ces fonctionnalités est d'aider à la compréhension et à l’apprentissage de la programmation dite bas-niveau au néophyte, car ce domaine permet d’avoir une bonne vision du monde qui nous entoure et de démystifier le fonctionnement des machines ainsi que certains concepts assez abstraits dans la programmation.
Présentation rapide du projet
Le projet est assez gros et est en réalité composé de plusieurs petits projets. Contrairement à Gint qui est spécifique aux calculatrices Casio et qui est orienté "efficacité" pour créer des jeux extrêmement performants. Vhex n'a pas exactement la même vision.
En effet, je ne vise pas uniquement les calculatrices Casio, mais bien la création de ma propre console portable. Seulement, je ne dispose pas encore des connaissances nécessaires pour arriver à concevoir des machines. C'est pourquoi, (et pour plein d'autres raisons qui seront évoqués dans le premier chapitre du topic), le "proof of concept" du projet est fait sur la calculatrice Casio et plus précisément les calculatrices couleurs.
La vidéo au-dessus montre une démo du projet. Ce qu'il faut retenir de cette vidéo, c'est que le noyau fonctionne et que les API (les fonctions que les utilisateurs pourront utiliser pour construire des choses) de base (dessin, clavier, timer) sont fonctionnels. Cependant, et comme vous allez le voir en lisant le chapitre concernant le noyau, le résultat est globalement extrêmement lent (d'où l'image de fin qui dit "envie d'overclocking") et c'est parfaitement normal. Le projet est jeune* et la gestion des performances ne sont pas à l'ordre du jour.
À l'heure actuelle où j'écris ces lignes, je suis en train de poser toutes les APIs sur papier afin de "geler" toutes les fonctionnalités le plus rapidement possible. Une fois que ce sera fait, je pourrais commencer à faire des optimisations. Je m'attarderai beaucoup plus en détaille sur la planification du projet sur le chapitre d'introduction.
Le projet Vhex regroupe actuellement tous ces projets :
plateforme agnostique (indépendante d'une machine)
vxKernel : l'unikernel, une des pièces maitresse du projet
vxSDK : le SDK pour aider au développement, une des pièces maitresse du projet aussi
vxOS : le système d'exploitation qui fournit une interface utilisateur
vxGDuck : un projet de démo qui est une adaptation du code de PierrotLL
vxControl : un "OS" de contrôle du kernel (comme gintctl pour les connaisseurs)
vxOpenLibM : un fork d'openlibm supportant la compilation PIC (pour faire simple : c'est très technique)
sh-elf-vhex : un GCC modifié permettant la création de librairie dynamique (c'est très technique aussi)
vxBoot : le bootloader permettant de charger des noyaux en mémoire (et pas que Vhex !)
Pour l'instant, peu de ces projets sont publics, car je manipule pas mal de chose qui flirtent avec la légalité et la stabilité des calculatrices. Je publierai les projets petits à petit après être certains que tout soit en ordre avant d'être rendue public.
Néanmoins, vous pouvez vous balader sur l'instance Gitea de Vhex, afin de voir tous les projets qui y ont été ajouté.
Pour des questions de lisibilité et pour ne pas surcharger cette page d'information et de mot technique inutile. Je vais fragmenter mes informations et mes notes dans les commentaires de ce topic et y ajouter des liens pour aller les lires, ça sera beaucoup plus simple pour tout le monde. Cette page fait donc office de "hub" pour le projet.
Ça me permettra de poster les informations au fur et à mesure sans me décourager en voyant la montagne de truc à écrire et ça animera beaucoup plus ce projet plutôt que de le faire dans mon coin.
Je vais aussi essayer de mettre en place une newsletter tous les dimanches pour expliquer mes avancées et mes prévisions pour la semaine suivante. Ça évitera de faire le mort pendant des années alors que beaucoup de choses avancent dans l'ombre.
Aussi, la tête du topic évoluera avec le temps. C'est alors normal que pour l'instant, il n'y ait rien de fou visuellement. Vhex est un projet extrêmement technique qui demande du temps avant d'avoir quelque chose de visuel à montrer.
Sommaire
Le sommaire sera mis à jour avec le temps.
Ce chapitre ne contiendra pas encore de notes techniques à propos du projet, mais sera en partie une synthèse de mes expériences, mes réflexions et mes échecs que j'ai traversés au cours de la réalisation du projet.
I.1 Historique du projet
Le projet Vhex date de 2018-2019. Au cours de ces trois dernières années, le projet a pris plein de forme différente.
À la base, c'était un outil de rétro-ingénierie dont j'avais besoin pour m'aider dans la documentation du clavier afin de pouvoir continuer GladOS qui est, à mes yeux, l'ancêtre de Vhex. Le projet était vraiment simpliste à l'époque et fonctionnait plutôt bien.
J'ai par la suite découvert le module UBC qui m'a offert un moyen d'écrire un programme me permettant de suivre l'exécution de l'OS de Casio instruction par instruction. Voyant le potentiel du truc que j'avais entre les mains, je me suis empressé de foncer tête baissé pour faire la deuxième version de mon outil... et c'est là que le bât blesse. Et ce n'est que bien plus tard, en lisant "The mythical man mounth" que j'ai compris mon erreur :
Frederick P. Brooks - The Second-System Effect a écrit :
[...]La tendance générale est de sur-concevoir le deuxième système, en utilisant toutes les idées et fioritures qui ont été prudemment détournées sur le premier. Le résultat, comme le dit Ovide, est un "gros tas". [...]
Il faut savoir qu'avant de reprendre Vhex pour faire la 2.0 du projet, j'avais beaucoup avancé sur GladOS en parallèle, mais j'avais mis fin au projet à la suite de beaucoup de problèmes avec le code de ce dernier et à cause de la frustration. Cependant, GladOS m'avait donné énormément de connaissance pour faire des choses extrêmement techniques. J'ai tenté de mettre toutes ces connaissances dans la deuxième version de l'outil.
Après plusieurs semaines de travail, je me suis rendu compte que cette nouvelle version de Vhex...était exactement ce que j'avais déjà fait avec GladOS sauf que cette fois-ci, j'avais réussi à aller un peu plus loin techniquement. Toutefois, le projet (qui était sur ce topic), est tombé à l'eau pour les mêmes raisons que GladOS : j'ai visé trop gros d'un coup et sans vraiment me focaliser sur le but précis du projet. J'avais fini par me retrouver avec des threads, des processus, un ordonnanceur, un début de tests avec des librairies dynamiques, ... ce qui n'était réellement pas nécessaire pour le projet qui est, de base, un désassembleur et non un OS. En conclusion, je me suis retrouvé à nouveau perdu dans mon code et sur des problèmes extrêmement fourbes très proches de ceux que j'avais rencontrés avec GladOS. Sauf que cette fois-ci, le profond sentiment d'avoir perdu mon temps a été très dur à encaisser : j'avais passé plusieurs années (2018 - début 2020) à réécrire le même code, les mêmes lignes pour contrôler la machine, les mêmes logiques, pratiquement la même architecture, ... tout ça sans jamais avoir de résultat visuel et sans jamais réutiliser le code que j'avais precedement fait. J'ai donc simplement abandonné le projet une nouvelle fois, me jurant de passer à autre chose.
Pratiquement 6 mois passèrent sans que je ne touche au projet. On arrive en septembre 2020 et j'avais completement mis de côté le développement sur calculatrices. Je suis resté un peu sur la scène "reverse/documentation", car ce domaine m'intéresse beaucoup, sans rien de vraiment probant.
Cependant, fin 2020, mon école où j'étais à ce moment-là, Epitech, me demande de choisir un sujet de fin d'études sur 2 ans. Dans un premier temps, je rejoins un projet complètement nul (coucou à @Django et @Moule s'ils passent par là) qu'on a appelé Payou : c'était une copie d'Yuka...mais c'était par Yuka. J'ai curieusement quitté le projet rapidement et ai formé, avec tous les étudiants qui n'avaient pas encore trouvé de groupe (dont une quasi-totalité qui on soit disparu, soit redoublé, soit quittés l'école) et j'ai décidé de reprendre Vhex, car j'avais une partie du travail de fait dans un coin et plein de bout de code qui trainait. L'objectif était donc de me la couler douce et de finir le projet en 2 mois au lieu de 2 ans.
Bien sur, ce fus encore une fois un echec, car je devais montré une preuve de concept du projet a toute la promotion, et ce quelque semaine apres la formation officiel du groupe. Et comme je l'ai evoqué plus tot, concevoir un kernel...c'est extremement frustrant au debut, car nous avons aucun resultat visible, ou alors ils sont extremement ridicule. Et surtout, ce n'était pas l'objectif de faire quelque chose de technique, le but était plutôt de nous inciter à faire "une pseudo-startup" et la grille de notation porte en grande majorité sur la stratégie commerciale, le marketing, la communication, les mises en place de CI, ...
Donc, je me suis mis en tête de développer tout le projet avant la présentation du projet..... Ce qui est une erreur absolue, car ce n'etais pas ce qui était demandé, mais j'ai une fois de plus foncé tête baissée sans prendre le temps de réfléchir. J'ai donc redéveloppé en partant zéro, et pour la millième fois de suite, un kernel qui faisait exactement la même chose que Vhex et GladOS, mais cette fois-ci, j'ai échoué bien plus tôt que prévu, car c'était la première fois que je développais sur la Graph90+E, ce qui m'a encore plus affecté psychologiquement, mais c'était trop tard, j'avais signé pour 2 ans.
J'ai complètement délaissé le projet après ça pendant facilement 6 mois, aucune des personnes présentes dans le groupe n'avait envie de faire quoi que ce soit. En même temps, ils n'avaient aucune idée de ce qu'était le projet. J'avais commencé à faire des trucs, mais sans vraiment d'envie, dans mon coin et uniquement parce qu'on devait rendre des choses a Epitech.
Et ça a duré jusqu'à l'arrivée de plusieurs nouvelles personnes dans le projet, beaucoup plus structuré et beaucoup plus sérieux que les précédant, car une année était passée et les enjeux étaient tout de suite plus importants à leurs yeux : la validation du diplôme. Pour ma part, j'avais compris que les diplômes ne servent absolument à rien (surtout celui d'Epitech) et que seules les compétences primes dans le monde professionnel (et l'avenir me donnera raison à de nombreuses reprises). Ceci-dit, on a commencé à reposer les documents correctement, à redéfinir une ligne directrice pour le projet et restructurer le groupe en interne. Toutefois, je n'avais toujours pas spécialement envie de faire le projet. Je le faisais davantage pour ne pas planter les autres.
Cette situation a durée jusqu'en septembre 2021. A ce moment la, je deviens assistant pedagogique dans une ecole de cyber-securité a Paris, l'ecole 2600, ou j'ai aidé a la construction des moulinettes et de l'infra. Comme a Epitech, les etudiants on une "piscine" en debut d'année : deux semaines ultra intenssif sur de l'assembleur et du C tres techniques (vraiment). A savoir que la piscine c'est passé dans une base de loisir autour d'un lac et que ces deux semaine ce terminais par un event "special".
Cet évent a commencé avec de la musique et a mangé. À 22h30 la musique se coupe et on demande à tout le monde de regrouper (assistant et prof compris) : 4 personnes armées sont arrivés sur les lieux et nous ont dit qu'on avait 15 minutes pour faire nos sacs afin de tenir toute la nuit. On apprit plus tard que ces personnes étaient en fais des membres du GIGN. Le but de l'évent était simple : on est divisé en 4 groupes et on devait soulever un brancard avec une personne du groupe dedans et suivre la silouhette d'un des membres du GIGN : s'il passait par-dessus un mur, on devait faire passer le brancard par-dessus le mur. Si on nous disait d'aller dans le lac, on allait dans l'eau (habillé) et le brancard ne doit pas être mouillé, sinon on se faisait tout simplement détruire avec plein d'exercice physique. Pour faire simple : ou que le guide passe, le brancard passe. Et ce, de 22h45 à 7h du matin.
Cette nuit-là, j'ai abandonné vers 6h de matin. Mes échecs depuis ces dernières années me sont revenues en boucle cette nuit et je me suis juste rendu compte que j'étais détruit psychologiquement, perdu et sans objectif. Le lendemain, j'ai décidé de me prendre deux semaines de vacances pour méditer et prendre une décision.
Après cette courte pause, Je me suis totalement repris en main en me fixant des objectifs (que je garde perso pour le coup), je me suis mis à faire des plannings, des listes, des indicateurs, à poser sur papier mes idées de projets, mes envies, ... je voulais absolument avoir une vision sur l'entièreté de ma vie. Et pour gagner en auto-discipline, je me suis interdit de manger le matin jusqu'à la fin de l'année scolaire en cours (~10 mois). Chose que j'ai complètement tenue sans broncher une seule seconde.
Quelques mois plus tard, début 2022, je reprends Vhex de zéro une dernière fois. J'ai reposé les objectifs du projet, fragmenté toutes les étapes en toute petite tache et j'avance petit pas par petit pas avec une vision complète sur le projet sans jamais m'éloigné de mon objectif initial. Si j'ai une idée, je la note quelque part et je l'intègrerai le moment venu. Je rattrape et dépasse toutes mes espérances en quelques semaines. J'ai aussi quitté officiellement (depuis quelques mois maintenant) Epitech, mais je continue le projet comme si ne rien etait, car il est hors de question que je laisse tomber les personnes qui dépendent de ce projet dont je suis le seul à pouvoir faire avancer. Puis je compte bien rattacher Vhex à mon sujet de fin d'études à l'école 2600 (oui, je suis devenue étudiant entre temps).
Je commence vraiment à être extrêmement serein sur l'avancement du projet et c'est pourquoi j'ai décidé de reprendre le topic.
I.2 Le pitch originel du projet
Le pitch de base de mon sujet de fin d'études était "Création d'une console portable pour apprendre à programmer". Et ce qui va suivre et tiré d'un d'un des documents que j'avais écrit pour justifier le projet.
Vhex - document de spec 2019 a écrit :
Il y a peu de solutions qui permettent de visualiser clairement les effets d’un code à bas-niveau et sont souvent trop complexes à aborder et peu fun pour un néophyte. L'une des solutions les plus connues (il me semble) reste Arduino qui est grandement utilisé dans les filiales "techniques" comme la STI2D.
Si je prends l’exemple d’Arduino, comme montre le schéma au-dessus, la ligne directrice "éducative" consiste généralement à comprendre deux notions pratiquement en simultané : l’électronique et l’informatique bas-niveau. Tout ça avant même de pouvoir s’amuser avec leur produit, car généralement la première fois qu'on touche à cette machine, on arrive, après plusieurs heures de cours, à enfin faire clignoter la LED orange de la carte. Ce qui n'est vraiment pas engageant pour les néophytes.
Vous vous doutez bien que seule une faible minorité de personnes arrive à la dernière étape, car on a trop peu de résultats concrets rapidement. Et en plus, de ça, Arduino tente de cacher la partie "technique" avec des abstractions, un IDE et un langage proche du C++. Tout cela permet donc à Arduino de contourner la complexité d’apprentissage de certaines thématiques dont l'une qui est, à mes yeux, primordial : comprendre le fonctionnement de la machine.
Ce n’est pas ma vision, et comme l’illustre le schéma au-dessus, j'aimerais d’abord que les utilisateurs, aussi néophyte soit-il, puissent, dès la sortie de la boîte, s’amuser sur la machine. Puis, par la suite, laisser leurs curiosités prendre le dessus pour comprendre le fonctionnement des jeux, puis potentiellement de la machine. Ils pourront avancer à leur rythme tout en faisant des choses concrètes visuellement et rapidement.
I.3 Compromis
Comme je l'ai évoqué approximativement un peu plus haut, le but de Vhex est de fournir une console portable sur laquelle les utilisateurs peuvent jouer et développer. Je vise dans un premier temps les utilisateurs complètement néophytes, mais aussi les utilisateurs très expérimentés.
Pour faire simple, j'aimerais pouvoir développer un jeu sans avoir m'occuper de comment contrôler la machine et aussi pouvoir prototyper mes propres noyaux sans risque de casser la machine.
Toujours tiré du même document, voilà comment j'imaginais Vhex au début du projet:
Vhex - document de spec 2019 a écrit :
Maintenant, je vais vous expliquer la réalité du projet. Créer une console portable implique de concevoir toute la partie "hardware", sauf que je n'ai pas encore les connaissances nécessaires pour y parvenir. Je devais partir en Corée en 2021 pour ça, mais le Covid modulo mon envie de tout plaquer ont fait que je n'y suis pas allé. J'ai donc dû trouver une alternative à la console et j'ai choisi la Graph90+E, car l'écran est en couleur et je visais plus ou moins mes performances matérielles dans l'idée et je saivais deja programmer dessus. Cependant, je garde en tête que ce médium est temporaire et je compte bien acquérir les connaissances qui me manquent pour concevoir ma propre console, mais chaque chose en son temps.
De plus, il y avait de plus d'en plus de "mini-projet" dont Vhex était dépendant, c'est pourquoi Vhex est bien devenue un regroupement de projet comme cité sur la page principale de ce topic. Je rentrerai en détail sur chaque projet dans les prochains chapitre.
I.3.1 : Pourquoi la G90 ?
L'objectif sur la graph90+E est relativement simple. J'aimerais avoir un noyau qui permet de lancer des applications en parallèle via une interface graphique comme le menu de Casio et de pouvoir "switcher" entre les jeux comme un alt tab sous Windows.
À noter que, secrètement, je voulais créer Vhex (avec la console) comme une sorte "sandbox" pour la conception de noyaux et le prototypage de drivers. C'est pourquoi les "applications" sont considérés comme étant des kernels et non comme des "applications utilisateur". Ce qui signifie que le mécanisme de "switch" entre les applications est fait via réaliser par hyperviseur directement intégré à Vhex.
Aussi, l'entièreté des applications est directement chargée en RAM, je n'ai pas de gestion de mémoire virtuel (du moins pour la graph90+E et aussi pour beaucoup de raison technique).
I.3.2 : Quid de la partie Web ?
Je ne m'occupe pas de la partie Web pour l'instant. Même si j'ai quitté Epitech, quelque personne se charge de créer le site communautaire de Vhex, mais je n'ai aucune vision sur ce qu'ils ont fait jusqu'à présent.
Pour la petite histoire, à Epitech, vers fin 2020, on doit pitcher nos projets à toute la promo, et il me semble qu'on avait même fini premier dans une des catégories d'ailleurs. Lors de notre premier rendu quelques semaines plus tard (on doit rendre des choses tous les mois pratiquement, pour vérifier qu'on avance bien), la personne qui évaluait le rendu nous a clairement dit "ah, mais moi j'y connais rien en électronique, donc toute cette partie ne pourra pas être notée. Et la partie kernel non plus d'ailleurs. Et là, je ne peux pas vous mettre des points parce que vous n'avais pas fait de CI sur Github, ni de tests unitaires...". Bref, ce sont des incapables et cette école reste un des plus gros scams connus à ce jour. Et c'est à ce moment-là que j'ai tordu le projet pour y glisser un site web et j'y mis quasiment toute l'équipe sur sa création.
Donc ce n'est vraiment pas d'actualité pour l'instant.
I.4 : Resumé
Vhex est un regroupement de projets, comme listé sur la page principale du projet, mais a pour but, sur le long terme, d'être une console portable permettant d'apprendre à programmer.
Pour l'instant, je ne peux me concentrer uniquement sur la conception du noyau, et ce, sur la graph90+E, car je n'ai pas encore les compétences requises pour me lancer dans la conception d'une carte mère.
Merci pour l'update ! Tu te tiens à ton Dimanche, et je triple-valide le post, je sens venir exactement ce dont on a besoin pour bien comprendre comment s'articule le projet.
Il y a plein de choses à dire ici, mais je tiens à réagir sur un point spécifiquement. En lisant l'historique on voit clairement ton évolution personnelle cachée derrière le projet sur ces quelques années. Je le comprends parce qu'on a tous les deux le même trait d'accuser notre manque de compétence/discipline quand on échoue quelque part. Mais là c'est impossible de ne pas voir le lien entre le fait que tu n'aies pas d'objectif et le fiasco absolu qu'est Epitech. Alors des fois respire un coup, observe que tu fais objectivement des trucs pétés, et tires-en un peu de satisfaction. L'imposteur, c'est celui qui arrive à te faire croire que tu es nul alors que les faits prouvent le contraire.
Ah et aussi j'aurais jamais tenu à jeun tous les matins lol, vas pas dire que tu manques de discipline maintenant.
Pour le jeun, je fais pareil et c'est absolument pas parce que je manque de discipline et que je skip le p'tit dej' pour gratter une petite demi-heure de sommeil
Sinon hâte de voir ce que ça va donner, depuis le temps qu'on entend parler de Vhex sans vraiment voir de résultat, en dehors de la libc (merci à vous deux, au passage). Et bravo pour avoir réussi à embarquer des gens dans ton projet sans y croire
[NewsLetter] - Préparation du vxSDK en version 0.13.0
Pas de grosse news cette semaine, je suis pas mal occupé sur plein d'autre projet et je n'ai pas pris le temps d'écrire le prochain chapitre qui concernera le SDK de Vhex.
Cependant, j'ai bientôt fini le refacto complet de l'outil, ce qui introduira la version 0.13.0 du vxSDK. Version qui vient corriger beaucoup de problème de conception et venant aussi simplifier grandement les sources du projet entre autre. De plus, un des ajouts majeurs de cette refonte concerne l'installation de paquet "en parallèle" que je vous expliquerais plus en détail dans le prochain chapitre.
Petit message pour dire que le projet n’est toujours pas mort, il avance petit a petit, mais me demande de lourdes modifications concernant l’architecture complète du projet assez fréquemment, faute d’avoir des objectifs qui évoluent constamment.
La dernière grosse modification en date, assez récente d’ailleurs, concerne la refonte du "système de build" afin de supporter du matériel bien plus vaste que simplement les calculatrices (je vise notamment les RaspberryPi) ce qui implique d’être capable d’être suffisamment agile en terme d’architecture et de méthodologie de compilation afin de pouvoir s’adapter au différence d’architecture (superh, aarch64, ...) et de composants physique (une calculatrice est différent d'une raspi figurez-vous).
Cette grosse modification a d’ailleurs été initiée afin de résoudre un énorme problème de conception : le bootloader.
Avant cette refonte, le bootloader était un projet à part (vxBoot) qui était écrit avec Gint et qui s'occupait simplement de charger le noyau, qui n'était, a ce moment la, rien d’autre qu’un simple fichier ELF (exécutable basique), et s’occupait de faire toutes les opérations de relocalisation avant de booter ledit noyau.
Maintenant, depuis quelque jours, le bootloader est entièrement intégré au projet et supporte l’ASLR, ce qui me permet de “m’auto corriger” lors de la phase de bootstrap (prise de contrôle du matériel). Pour faire très simple : je cherche la RAM utilisateur, je “m’auto déplace” là bas, je “m’auto corrige” pour m'intégrer correctement a mon nouvel environnement et j’exécute le code du bootloader qui s’occupera : soit de fournir une interface utilisateur afin d'inspecter/configurer l'image noyau avant de le démarrer. soit de booter le kernel directement de manière transparente soit d’attendre qu’on lui envoie l'image noyau par USB (histoire que je ne perde pas de temps à faire des transfert dans la ROM toute les 30 secondes).
L’avantage d’une telle technique aussi compliqué (ASLR), c’est que le code qui s’occupe de gérer l’hardware est drastiquement réduit ce qui me permet de supporter plus facilement d'autres machines et d'effectuer des tests unitaires et de couverture de code plus facilement. De plus, le code du bootloader, pour les calculatrices Casio, repose maintenant exclusivement sur les syscall du constructeur et non plus sur Gint, ce qui m’assure un gain en code et de stabilité considérable (non pas que Gint ne soit pas stable, mais "l'auto correction" est une opération assez sensible et je n'ai pas besoins de grand choses techniquement pour le bootloader).
Seulement, je ne boot toujours pas le noyau (qui, lui a beaucoup évolué, mais rien de bien notable visuellement), j’ai pas mal de changement et de tests à faire avant de pouvoir retomber sur mes pattes, notamment concernant la RaspberryPi qui n'est...pas documenté et qui repose sur des firmware propriétaire. Lets go.
Bon, on ne dirait pas comme ça, parce que le projet est très technique et que ma communication reste miteuse, mais le projet a énormément évolué depuis mon dernier message. Il s'est passé beaucoup de choses dans ma vie privée qui m'ont amené à réduire mon implication sur ce projet, mais il avance assez vite depuis que je me suis sortie de certaines galères terrifiante.
Je suis fier du projet et très heureux du résultat actuellement. C'est plus ou moins mon fil rouge technique, donc je continuerais d'avancer... et qui sais peut-être qu'un jour il sera utilisable pour le commun des mortels.
Un autre petit message d’avancement sur le projet avant que ça ne finisse encore une fois sous le tapis.
Depuis la semaine dernière, j’ai pas mal nettoyé le code de bootstrap (prise de controle du materiel) de la raspi3b et je me suis atteler la la partie affichage vidéo, ce qui m’a permis de faire pas mal de découverte concernant la machine.
La carte mère embarque un GPU (VideoCore) qui contient son propre firmware (très peu documenté car les sources du firmware sont closes), mais quelque bonnes âmes ont eu, contrairement à moi concernant Fugue, la bonté d'écrire une documentation sur comment “communiquer” avec le ledit GPU (il manque des informations et c’est pas toujours super claire, mais on a l'essentiel).
Et j’ai découvert que le GPU offre une interface assez exotique (mailboxes) qui permettent de demander au firmware de faire certaine opération à notre place. Pour faire simple, c’est du même niveau que les “syscall” de Casio sur la calculatrice : opaque et étrangement fonctionnel.
J’ai donc simplement créé une interface entre le GPU et mes besoins ce qui m’a permis de “speedrun” l’affichage graphique et de porter 90% du bootloader ce matin qui est maintenant fonctionnel sur la machine (il manque la gestion du clavier, que je n’ai pas le temps de mettre en place maintenant).
A noter aussi que pas mal de modifications ont dû être faites concernant la gestion de l’ASLR. (Qui reste assez exotique aussi sur cette machine, car on a un espace d'adressage de 32 bits (les pointeurs font 32bits en gros), mais comme les registres font 64bits, la majorité des déplacements de mémoire demande du 64 bits. Bref, faut juste faire gaffe à certain moment).
Cependant, certes le bootloader semble bien booté sur QEMU, j’ai bien les info de debug en UART, des choses qui s’affiche à l'écran, … mais impossible de faire fonctionner sur la machine physique. l’HDMI refuse de donner signe de vie.
Et comme les concepteurs de la machine on eu l’idée de génie de se dire “tiens, on va mapper l’UART sur le module bluetooth”, je ne peux même pas avoir de logs avec mon analyseur logique donc je ne sais même pas où le binaire plante. Une piste de debug serait de jouer avec la LED présente sur la machine (je sais théoriquement comment faire), mais ça demande beaucoup de temps et d’y aller en tâtonnant…je n’ai pas le temps actuellement pour ça.
Enfin bon, tout avance bien mine de crayon.
Ajoute des screenshots, on comprendra mieux
Alors, pour l’instant les screens ne servent strictement à rien pour la simple et bonne raison que j’affiche uniquement 3 lignes à l'écran pour vérifier que l’ASLR est fonctionnel et ensuite ça attend juste que l’utilisateur tape sur le clavier et attends un reset manuel.
Vraiment rien de passionnant pour l’instant, car c'est un projet extrêmement technique. C’est plus les sources qui sont important ici, mais il faut avoir envie de se plonger dans mon code
Petit message sur le topic pour vous dire que je suis retourné sur le projet ces 3 dernières semaines dans l'optique de rendre publique les sources (enfin) et d'y apporter le support de la fxcp400. Je viens tout juste de finir la remise à plat du projet et de rendre public le depot sur github ici https://github.com/YannMagnin/vxGOS (un mirroir a aussi été mis sur la forge de PC)
A noter aussi que le projet reste pour moi un sujet de fond et un gros bac a sable pour de l'expérimentation. J'y retourne quand j'ai le temps donc c'est pas très croustillant pour vous.
Le fait de reprendre le projet pratiquement un an après, m'a permis de reposer les objectifs, mon organisation, ma gestion du projet, l'architecture, le code, ... bref c'est principalement une grosse remise à plat pour les futurs évolutions.
L'une des grosse nouveauté concernant le noyau (au delà du rebranding) reste l'ajout du support de la Classpad II (fxcp400) et l'abandon de la RaspberryPi due au manque de documentation sur le matériel mais qui sera remplacé par la BananaPi qui semble beaucoup plus ouvert. Ceci étant dit, pour ceux qui voudrait tester le noyau sur la fxcp400 (ce qui ne servirait pas à grand chose honnêtement, il y a vraiment pas beaucoup à voir) il vous faudra un [custom firmware](https://en.wikipedia.org/wiki/Custom_firmware) sur la dernière version (02.01.7002) qui permet de charger le kernel (mon propre firmware modifié ne sera pas rendu public pour des raisons légales évidentes). Ceci étant dit, je prévois d'ajouter le support de [hollyhock-2](https://github.com/SnailMath/hollyhock-2/releases/) mais ca me demande de revoir le boot du noyau sur la machine donc ça n'arrivera pas tout de suite (peut être dans la prochaine release).
Du coup, que fait le noyau ? Pour l'instant pas grand chose. J'ai une phase de bootstrap ou je cherche a me charger entièrement RAM puis je démarre le bootloader (reposant essentiellement sur l'OS de Casio) qui me permet d'avoir une console pour effectuer des tests de diagnostic et booter le kernel (a l'avenir ça sera transparent). L'idée serait de me permettre d'ajouter de la compression sur l'image du noyau et de faire la décompression avant son boot. Par la suite, le kernel se bootstrap a sont tour (ASLR) et utilise une nouvelle console un peu spéciale (kterm) qui permet d'avoir des messages très tôt dans la phase du boot. Et....c'est tout pour l'instant, ensuite ça attend un reset manuel (une bonne partie des codes du noyau ont été désactivés pour l'instant le temps de revoir l'hyperviseur et l'allocateur kernel (la prochaine release)).
La feuille de route est disponible dans les issues pour les curieux (https://github.com/YannMagnin/vxGOS/issues/30). D'ailleurs, je travail en parallèle sur un langage de programmation perso qui m'aidera à la surveillance ainsi qu'au maintien la base de code, mais je vous en reparlerai surement plus tard quand ça aura avancé et que je pourrais vous montrer des choses.
Donc voila, un petit message pour vous dire que le projet avance, mais que ça reste une tache de fond pour moi !
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
Citer : Posté le 17/07/2022 22:08 | # |
Fichier joint
[NewsLetter] - I. Introduction au projet
Ce chapitre ne contiendra pas encore de notes techniques à propos du projet, mais sera en partie une synthèse de mes expériences, mes réflexions et mes échecs que j'ai traversés au cours de la réalisation du projet.
I.1 Historique du projet
Le projet Vhex date de 2018-2019. Au cours de ces trois dernières années, le projet a pris plein de forme différente.
À la base, c'était un outil de rétro-ingénierie dont j'avais besoin pour m'aider dans la documentation du clavier afin de pouvoir continuer GladOS qui est, à mes yeux, l'ancêtre de Vhex. Le projet était vraiment simpliste à l'époque et fonctionnait plutôt bien.
J'ai par la suite découvert le module UBC qui m'a offert un moyen d'écrire un programme me permettant de suivre l'exécution de l'OS de Casio instruction par instruction. Voyant le potentiel du truc que j'avais entre les mains, je me suis empressé de foncer tête baissé pour faire la deuxième version de mon outil... et c'est là que le bât blesse. Et ce n'est que bien plus tard, en lisant "The mythical man mounth" que j'ai compris mon erreur :
[...]La tendance générale est de sur-concevoir le deuxième système, en utilisant toutes les idées et fioritures qui ont été prudemment détournées sur le premier. Le résultat, comme le dit Ovide, est un "gros tas". [...]
Il faut savoir qu'avant de reprendre Vhex pour faire la 2.0 du projet, j'avais beaucoup avancé sur GladOS en parallèle, mais j'avais mis fin au projet à la suite de beaucoup de problèmes avec le code de ce dernier et à cause de la frustration. Cependant, GladOS m'avait donné énormément de connaissance pour faire des choses extrêmement techniques. J'ai tenté de mettre toutes ces connaissances dans la deuxième version de l'outil.
Après plusieurs semaines de travail, je me suis rendu compte que cette nouvelle version de Vhex...était exactement ce que j'avais déjà fait avec GladOS sauf que cette fois-ci, j'avais réussi à aller un peu plus loin techniquement. Toutefois, le projet (qui était sur ce topic), est tombé à l'eau pour les mêmes raisons que GladOS : j'ai visé trop gros d'un coup et sans vraiment me focaliser sur le but précis du projet. J'avais fini par me retrouver avec des threads, des processus, un ordonnanceur, un début de tests avec des librairies dynamiques, ... ce qui n'était réellement pas nécessaire pour le projet qui est, de base, un désassembleur et non un OS. En conclusion, je me suis retrouvé à nouveau perdu dans mon code et sur des problèmes extrêmement fourbes très proches de ceux que j'avais rencontrés avec GladOS. Sauf que cette fois-ci, le profond sentiment d'avoir perdu mon temps a été très dur à encaisser : j'avais passé plusieurs années (2018 - début 2020) à réécrire le même code, les mêmes lignes pour contrôler la machine, les mêmes logiques, pratiquement la même architecture, ... tout ça sans jamais avoir de résultat visuel et sans jamais réutiliser le code que j'avais precedement fait. J'ai donc simplement abandonné le projet une nouvelle fois, me jurant de passer à autre chose.
Pratiquement 6 mois passèrent sans que je ne touche au projet. On arrive en septembre 2020 et j'avais completement mis de côté le développement sur calculatrices. Je suis resté un peu sur la scène "reverse/documentation", car ce domaine m'intéresse beaucoup, sans rien de vraiment probant.
Cependant, fin 2020, mon école où j'étais à ce moment-là, Epitech, me demande de choisir un sujet de fin d'études sur 2 ans. Dans un premier temps, je rejoins un projet complètement nul (coucou à @Django et @Moule s'ils passent par là) qu'on a appelé Payou : c'était une copie d'Yuka...mais c'était par Yuka. J'ai curieusement quitté le projet rapidement et ai formé, avec tous les étudiants qui n'avaient pas encore trouvé de groupe (dont une quasi-totalité qui on soit disparu, soit redoublé, soit quittés l'école) et j'ai décidé de reprendre Vhex, car j'avais une partie du travail de fait dans un coin et plein de bout de code qui trainait. L'objectif était donc de me la couler douce et de finir le projet en 2 mois au lieu de 2 ans.
Bien sur, ce fus encore une fois un echec, car je devais montré une preuve de concept du projet a toute la promotion, et ce quelque semaine apres la formation officiel du groupe. Et comme je l'ai evoqué plus tot, concevoir un kernel...c'est extremement frustrant au debut, car nous avons aucun resultat visible, ou alors ils sont extremement ridicule. Et surtout, ce n'était pas l'objectif de faire quelque chose de technique, le but était plutôt de nous inciter à faire "une pseudo-startup" et la grille de notation porte en grande majorité sur la stratégie commerciale, le marketing, la communication, les mises en place de CI, ...
Donc, je me suis mis en tête de développer tout le projet avant la présentation du projet..... Ce qui est une erreur absolue, car ce n'etais pas ce qui était demandé, mais j'ai une fois de plus foncé tête baissée sans prendre le temps de réfléchir. J'ai donc redéveloppé en partant zéro, et pour la millième fois de suite, un kernel qui faisait exactement la même chose que Vhex et GladOS, mais cette fois-ci, j'ai échoué bien plus tôt que prévu, car c'était la première fois que je développais sur la Graph90+E, ce qui m'a encore plus affecté psychologiquement, mais c'était trop tard, j'avais signé pour 2 ans.
J'ai complètement délaissé le projet après ça pendant facilement 6 mois, aucune des personnes présentes dans le groupe n'avait envie de faire quoi que ce soit. En même temps, ils n'avaient aucune idée de ce qu'était le projet. J'avais commencé à faire des trucs, mais sans vraiment d'envie, dans mon coin et uniquement parce qu'on devait rendre des choses a Epitech.
Et ça a duré jusqu'à l'arrivée de plusieurs nouvelles personnes dans le projet, beaucoup plus structuré et beaucoup plus sérieux que les précédant, car une année était passée et les enjeux étaient tout de suite plus importants à leurs yeux : la validation du diplôme. Pour ma part, j'avais compris que les diplômes ne servent absolument à rien (surtout celui d'Epitech) et que seules les compétences primes dans le monde professionnel (et l'avenir me donnera raison à de nombreuses reprises). Ceci-dit, on a commencé à reposer les documents correctement, à redéfinir une ligne directrice pour le projet et restructurer le groupe en interne. Toutefois, je n'avais toujours pas spécialement envie de faire le projet. Je le faisais davantage pour ne pas planter les autres.
Cette situation a durée jusqu'en septembre 2021. A ce moment la, je deviens assistant pedagogique dans une ecole de cyber-securité a Paris, l'ecole 2600, ou j'ai aidé a la construction des moulinettes et de l'infra. Comme a Epitech, les etudiants on une "piscine" en debut d'année : deux semaines ultra intenssif sur de l'assembleur et du C tres techniques (vraiment). A savoir que la piscine c'est passé dans une base de loisir autour d'un lac et que ces deux semaine ce terminais par un event "special".
Cet évent a commencé avec de la musique et a mangé. À 22h30 la musique se coupe et on demande à tout le monde de regrouper (assistant et prof compris) : 4 personnes armées sont arrivés sur les lieux et nous ont dit qu'on avait 15 minutes pour faire nos sacs afin de tenir toute la nuit. On apprit plus tard que ces personnes étaient en fais des membres du GIGN. Le but de l'évent était simple : on est divisé en 4 groupes et on devait soulever un brancard avec une personne du groupe dedans et suivre la silouhette d'un des membres du GIGN : s'il passait par-dessus un mur, on devait faire passer le brancard par-dessus le mur. Si on nous disait d'aller dans le lac, on allait dans l'eau (habillé) et le brancard ne doit pas être mouillé, sinon on se faisait tout simplement détruire avec plein d'exercice physique. Pour faire simple : ou que le guide passe, le brancard passe. Et ce, de 22h45 à 7h du matin.
Cette nuit-là, j'ai abandonné vers 6h de matin. Mes échecs depuis ces dernières années me sont revenues en boucle cette nuit et je me suis juste rendu compte que j'étais détruit psychologiquement, perdu et sans objectif. Le lendemain, j'ai décidé de me prendre deux semaines de vacances pour méditer et prendre une décision.
Après cette courte pause, Je me suis totalement repris en main en me fixant des objectifs (que je garde perso pour le coup), je me suis mis à faire des plannings, des listes, des indicateurs, à poser sur papier mes idées de projets, mes envies, ... je voulais absolument avoir une vision sur l'entièreté de ma vie. Et pour gagner en auto-discipline, je me suis interdit de manger le matin jusqu'à la fin de l'année scolaire en cours (~10 mois). Chose que j'ai complètement tenue sans broncher une seule seconde.
Quelques mois plus tard, début 2022, je reprends Vhex de zéro une dernière fois. J'ai reposé les objectifs du projet, fragmenté toutes les étapes en toute petite tache et j'avance petit pas par petit pas avec une vision complète sur le projet sans jamais m'éloigné de mon objectif initial. Si j'ai une idée, je la note quelque part et je l'intègrerai le moment venu. Je rattrape et dépasse toutes mes espérances en quelques semaines. J'ai aussi quitté officiellement (depuis quelques mois maintenant) Epitech, mais je continue le projet comme si ne rien etait, car il est hors de question que je laisse tomber les personnes qui dépendent de ce projet dont je suis le seul à pouvoir faire avancer. Puis je compte bien rattacher Vhex à mon sujet de fin d'études à l'école 2600 (oui, je suis devenue étudiant entre temps).
Je commence vraiment à être extrêmement serein sur l'avancement du projet et c'est pourquoi j'ai décidé de reprendre le topic.
I.2 Le pitch originel du projet
Le pitch de base de mon sujet de fin d'études était "Création d'une console portable pour apprendre à programmer". Et ce qui va suivre et tiré d'un d'un des documents que j'avais écrit pour justifier le projet.
Il y a peu de solutions qui permettent de visualiser clairement les effets d’un code à bas-niveau et sont souvent trop complexes à aborder et peu fun pour un néophyte. L'une des solutions les plus connues (il me semble) reste Arduino qui est grandement utilisé dans les filiales "techniques" comme la STI2D.
Si je prends l’exemple d’Arduino, comme montre le schéma au-dessus, la ligne directrice "éducative" consiste généralement à comprendre deux notions pratiquement en simultané : l’électronique et l’informatique bas-niveau. Tout ça avant même de pouvoir s’amuser avec leur produit, car généralement la première fois qu'on touche à cette machine, on arrive, après plusieurs heures de cours, à enfin faire clignoter la LED orange de la carte. Ce qui n'est vraiment pas engageant pour les néophytes.
Vous vous doutez bien que seule une faible minorité de personnes arrive à la dernière étape, car on a trop peu de résultats concrets rapidement. Et en plus, de ça, Arduino tente de cacher la partie "technique" avec des abstractions, un IDE et un langage proche du C++. Tout cela permet donc à Arduino de contourner la complexité d’apprentissage de certaines thématiques dont l'une qui est, à mes yeux, primordial : comprendre le fonctionnement de la machine.
Ce n’est pas ma vision, et comme l’illustre le schéma au-dessus, j'aimerais d’abord que les utilisateurs, aussi néophyte soit-il, puissent, dès la sortie de la boîte, s’amuser sur la machine. Puis, par la suite, laisser leurs curiosités prendre le dessus pour comprendre le fonctionnement des jeux, puis potentiellement de la machine. Ils pourront avancer à leur rythme tout en faisant des choses concrètes visuellement et rapidement.
I.3 Compromis
Comme je l'ai évoqué approximativement un peu plus haut, le but de Vhex est de fournir une console portable sur laquelle les utilisateurs peuvent jouer et développer. Je vise dans un premier temps les utilisateurs complètement néophytes, mais aussi les utilisateurs très expérimentés.
Pour faire simple, j'aimerais pouvoir développer un jeu sans avoir m'occuper de comment contrôler la machine et aussi pouvoir prototyper mes propres noyaux sans risque de casser la machine.
Toujours tiré du même document, voilà comment j'imaginais Vhex au début du projet:
Maintenant, je vais vous expliquer la réalité du projet. Créer une console portable implique de concevoir toute la partie "hardware", sauf que je n'ai pas encore les connaissances nécessaires pour y parvenir. Je devais partir en Corée en 2021 pour ça, mais le Covid modulo mon envie de tout plaquer ont fait que je n'y suis pas allé. J'ai donc dû trouver une alternative à la console et j'ai choisi la Graph90+E, car l'écran est en couleur et je visais plus ou moins mes performances matérielles dans l'idée et je saivais deja programmer dessus. Cependant, je garde en tête que ce médium est temporaire et je compte bien acquérir les connaissances qui me manquent pour concevoir ma propre console, mais chaque chose en son temps.
De plus, il y avait de plus d'en plus de "mini-projet" dont Vhex était dépendant, c'est pourquoi Vhex est bien devenue un regroupement de projet comme cité sur la page principale de ce topic. Je rentrerai en détail sur chaque projet dans les prochains chapitre.
I.3.1 : Pourquoi la G90 ?
L'objectif sur la graph90+E est relativement simple. J'aimerais avoir un noyau qui permet de lancer des applications en parallèle via une interface graphique comme le menu de Casio et de pouvoir "switcher" entre les jeux comme un alt tab sous Windows.
À noter que, secrètement, je voulais créer Vhex (avec la console) comme une sorte "sandbox" pour la conception de noyaux et le prototypage de drivers. C'est pourquoi les "applications" sont considérés comme étant des kernels et non comme des "applications utilisateur". Ce qui signifie que le mécanisme de "switch" entre les applications est fait via réaliser par hyperviseur directement intégré à Vhex.
Aussi, l'entièreté des applications est directement chargée en RAM, je n'ai pas de gestion de mémoire virtuel (du moins pour la graph90+E et aussi pour beaucoup de raison technique).
I.3.2 : Quid de la partie Web ?
Je ne m'occupe pas de la partie Web pour l'instant. Même si j'ai quitté Epitech, quelque personne se charge de créer le site communautaire de Vhex, mais je n'ai aucune vision sur ce qu'ils ont fait jusqu'à présent.
Pour la petite histoire, à Epitech, vers fin 2020, on doit pitcher nos projets à toute la promo, et il me semble qu'on avait même fini premier dans une des catégories d'ailleurs. Lors de notre premier rendu quelques semaines plus tard (on doit rendre des choses tous les mois pratiquement, pour vérifier qu'on avance bien), la personne qui évaluait le rendu nous a clairement dit "ah, mais moi j'y connais rien en électronique, donc toute cette partie ne pourra pas être notée. Et la partie kernel non plus d'ailleurs. Et là, je ne peux pas vous mettre des points parce que vous n'avais pas fait de CI sur Github, ni de tests unitaires...". Bref, ce sont des incapables et cette école reste un des plus gros scams connus à ce jour. Et c'est à ce moment-là que j'ai tordu le projet pour y glisser un site web et j'y mis quasiment toute l'équipe sur sa création.
Donc ce n'est vraiment pas d'actualité pour l'instant.
I.4 : Resumé
Vhex est un regroupement de projets, comme listé sur la page principale du projet, mais a pour but, sur le long terme, d'être une console portable permettant d'apprendre à programmer.
Pour l'instant, je ne peux me concentrer uniquement sur la conception du noyau, et ce, sur la graph90+E, car je n'ai pas encore les compétences requises pour me lancer dans la conception d'une carte mère.
Citer : Posté le 18/07/2022 20:00 | #
Merci pour l'update ! Tu te tiens à ton Dimanche, et je triple-valide le post, je sens venir exactement ce dont on a besoin pour bien comprendre comment s'articule le projet.
Il y a plein de choses à dire ici, mais je tiens à réagir sur un point spécifiquement. En lisant l'historique on voit clairement ton évolution personnelle cachée derrière le projet sur ces quelques années. Je le comprends parce qu'on a tous les deux le même trait d'accuser notre manque de compétence/discipline quand on échoue quelque part. Mais là c'est impossible de ne pas voir le lien entre le fait que tu n'aies pas d'objectif et le fiasco absolu qu'est Epitech. Alors des fois respire un coup, observe que tu fais objectivement des trucs pétés, et tires-en un peu de satisfaction. L'imposteur, c'est celui qui arrive à te faire croire que tu es nul alors que les faits prouvent le contraire.
Ah et aussi j'aurais jamais tenu à jeun tous les matins lol, vas pas dire que tu manques de discipline maintenant.
Citer : Posté le 18/07/2022 20:35 | #
Pour le jeun, je fais pareil et c'est absolument pas parce que je manque de discipline et que je skip le p'tit dej' pour gratter une petite demi-heure de sommeil
Sinon hâte de voir ce que ça va donner, depuis le temps qu'on entend parler de Vhex sans vraiment voir de résultat, en dehors de la libc (merci à vous deux, au passage). Et bravo pour avoir réussi à embarquer des gens dans ton projet sans y croire
Citer : Posté le 23/07/2022 20:06 | #
[NewsLetter] - Préparation du vxSDK en version 0.13.0
Pas de grosse news cette semaine, je suis pas mal occupé sur plein d'autre projet et je n'ai pas pris le temps d'écrire le prochain chapitre qui concernera le SDK de Vhex.
Cependant, j'ai bientôt fini le refacto complet de l'outil, ce qui introduira la version 0.13.0 du vxSDK. Version qui vient corriger beaucoup de problème de conception et venant aussi simplifier grandement les sources du projet entre autre. De plus, un des ajouts majeurs de cette refonte concerne l'installation de paquet "en parallèle" que je vous expliquerais plus en détail dans le prochain chapitre.
Citer : Posté le 23/07/2022 22:56 | #
J'avais pas vu l'update, mais ce que je pense a déjà été dit par Lephé.
Citer : Posté le 10/06/2023 20:33 | #
Yo,
Petit message pour dire que le projet n’est toujours pas mort, il avance petit a petit, mais me demande de lourdes modifications concernant l’architecture complète du projet assez fréquemment, faute d’avoir des objectifs qui évoluent constamment.
La dernière grosse modification en date, assez récente d’ailleurs, concerne la refonte du "système de build" afin de supporter du matériel bien plus vaste que simplement les calculatrices (je vise notamment les RaspberryPi) ce qui implique d’être capable d’être suffisamment agile en terme d’architecture et de méthodologie de compilation afin de pouvoir s’adapter au différence d’architecture (superh, aarch64, ...) et de composants physique (une calculatrice est différent d'une raspi figurez-vous).
Cette grosse modification a d’ailleurs été initiée afin de résoudre un énorme problème de conception : le bootloader.
Avant cette refonte, le bootloader était un projet à part (vxBoot) qui était écrit avec Gint et qui s'occupait simplement de charger le noyau, qui n'était, a ce moment la, rien d’autre qu’un simple fichier ELF (exécutable basique), et s’occupait de faire toutes les opérations de relocalisation avant de booter ledit noyau.
Maintenant, depuis quelque jours, le bootloader est entièrement intégré au projet et supporte l’ASLR, ce qui me permet de “m’auto corriger” lors de la phase de bootstrap (prise de contrôle du matériel). Pour faire très simple : je cherche la RAM utilisateur, je “m’auto déplace” là bas, je “m’auto corrige” pour m'intégrer correctement a mon nouvel environnement et j’exécute le code du bootloader qui s’occupera :
L’avantage d’une telle technique aussi compliqué (ASLR), c’est que le code qui s’occupe de gérer l’hardware est drastiquement réduit ce qui me permet de supporter plus facilement d'autres machines et d'effectuer des tests unitaires et de couverture de code plus facilement. De plus, le code du bootloader, pour les calculatrices Casio, repose maintenant exclusivement sur les syscall du constructeur et non plus sur Gint, ce qui m’assure un gain en code et de stabilité considérable (non pas que Gint ne soit pas stable, mais "l'auto correction" est une opération assez sensible et je n'ai pas besoins de grand choses techniquement pour le bootloader).
Seulement, je ne boot toujours pas le noyau (qui, lui a beaucoup évolué, mais rien de bien notable visuellement), j’ai pas mal de changement et de tests à faire avant de pouvoir retomber sur mes pattes, notamment concernant la RaspberryPi qui n'est...pas documenté et qui repose sur des firmware propriétaire. Lets go.
Bon, on ne dirait pas comme ça, parce que le projet est très technique et que ma communication reste miteuse, mais le projet a énormément évolué depuis mon dernier message. Il s'est passé beaucoup de choses dans ma vie privée qui m'ont amené à réduire mon implication sur ce projet, mais il avance assez vite depuis que je me suis sortie de certaines galères terrifiante.
Je suis fier du projet et très heureux du résultat actuellement. C'est plus ou moins mon fil rouge technique, donc je continuerais d'avancer... et qui sais peut-être qu'un jour il sera utilisable pour le commun des mortels.
Citer : Posté le 10/06/2023 21:35 | #
ma communication reste miteuse
Ajoute des screenshots, on comprendra mieux, et serons plus intéressés par le projet
Citer : Posté le 17/06/2023 15:34 | #
Yo,
Un autre petit message d’avancement sur le projet avant que ça ne finisse encore une fois sous le tapis.
Depuis la semaine dernière, j’ai pas mal nettoyé le code de bootstrap (prise de controle du materiel) de la raspi3b et je me suis atteler la la partie affichage vidéo, ce qui m’a permis de faire pas mal de découverte concernant la machine.
La carte mère embarque un GPU (VideoCore) qui contient son propre firmware (très peu documenté car les sources du firmware sont closes), mais quelque bonnes âmes ont eu, contrairement à moi concernant Fugue, la bonté d'écrire une documentation sur comment “communiquer” avec le ledit GPU (il manque des informations et c’est pas toujours super claire, mais on a l'essentiel).
Et j’ai découvert que le GPU offre une interface assez exotique (mailboxes) qui permettent de demander au firmware de faire certaine opération à notre place. Pour faire simple, c’est du même niveau que les “syscall” de Casio sur la calculatrice : opaque et étrangement fonctionnel.
J’ai donc simplement créé une interface entre le GPU et mes besoins ce qui m’a permis de “speedrun” l’affichage graphique et de porter 90% du bootloader ce matin qui est maintenant fonctionnel sur la machine (il manque la gestion du clavier, que je n’ai pas le temps de mettre en place maintenant).
A noter aussi que pas mal de modifications ont dû être faites concernant la gestion de l’ASLR. (Qui reste assez exotique aussi sur cette machine, car on a un espace d'adressage de 32 bits (les pointeurs font 32bits en gros), mais comme les registres font 64bits, la majorité des déplacements de mémoire demande du 64 bits. Bref, faut juste faire gaffe à certain moment).
Cependant, certes le bootloader semble bien booté sur QEMU, j’ai bien les info de debug en UART, des choses qui s’affiche à l'écran, … mais impossible de faire fonctionner sur la machine physique. l’HDMI refuse de donner signe de vie.
Et comme les concepteurs de la machine on eu l’idée de génie de se dire “tiens, on va mapper l’UART sur le module bluetooth”, je ne peux même pas avoir de logs avec mon analyseur logique donc je ne sais même pas où le binaire plante. Une piste de debug serait de jouer avec la LED présente sur la machine (je sais théoriquement comment faire), mais ça demande beaucoup de temps et d’y aller en tâtonnant…je n’ai pas le temps actuellement pour ça.
Enfin bon, tout avance bien mine de crayon.
Ajoute des screenshots, on comprendra mieux
Alors, pour l’instant les screens ne servent strictement à rien pour la simple et bonne raison que j’affiche uniquement 3 lignes à l'écran pour vérifier que l’ASLR est fonctionnel et ensuite ça attend juste que l’utilisateur tape sur le clavier et attends un reset manuel.
Vraiment rien de passionnant pour l’instant, car c'est un projet extrêmement technique. C’est plus les sources qui sont important ici, mais il faut avoir envie de se plonger dans mon code
Citer : Posté le 29/05/2024 19:17 | #
Yo,
Petit message sur le topic pour vous dire que je suis retourné sur le projet ces 3 dernières semaines dans l'optique de rendre publique les sources (enfin) et d'y apporter le support de la fxcp400. Je viens tout juste de finir la remise à plat du projet et de rendre public le depot sur github ici https://github.com/YannMagnin/vxGOS (un mirroir a aussi été mis sur la forge de PC)
A noter aussi que le projet reste pour moi un sujet de fond et un gros bac a sable pour de l'expérimentation. J'y retourne quand j'ai le temps donc c'est pas très croustillant pour vous.
Le fait de reprendre le projet pratiquement un an après, m'a permis de reposer les objectifs, mon organisation, ma gestion du projet, l'architecture, le code, ... bref c'est principalement une grosse remise à plat pour les futurs évolutions.
L'une des grosse nouveauté concernant le noyau (au delà du rebranding) reste l'ajout du support de la Classpad II (fxcp400) et l'abandon de la RaspberryPi due au manque de documentation sur le matériel mais qui sera remplacé par la BananaPi qui semble beaucoup plus ouvert. Ceci étant dit, pour ceux qui voudrait tester le noyau sur la fxcp400 (ce qui ne servirait pas à grand chose honnêtement, il y a vraiment pas beaucoup à voir) il vous faudra un [custom firmware](https://en.wikipedia.org/wiki/Custom_firmware) sur la dernière version (02.01.7002) qui permet de charger le kernel (mon propre firmware modifié ne sera pas rendu public pour des raisons légales évidentes). Ceci étant dit, je prévois d'ajouter le support de [hollyhock-2](https://github.com/SnailMath/hollyhock-2/releases/) mais ca me demande de revoir le boot du noyau sur la machine donc ça n'arrivera pas tout de suite (peut être dans la prochaine release).
Du coup, que fait le noyau ? Pour l'instant pas grand chose. J'ai une phase de bootstrap ou je cherche a me charger entièrement RAM puis je démarre le bootloader (reposant essentiellement sur l'OS de Casio) qui me permet d'avoir une console pour effectuer des tests de diagnostic et booter le kernel (a l'avenir ça sera transparent). L'idée serait de me permettre d'ajouter de la compression sur l'image du noyau et de faire la décompression avant son boot. Par la suite, le kernel se bootstrap a sont tour (ASLR) et utilise une nouvelle console un peu spéciale (kterm) qui permet d'avoir des messages très tôt dans la phase du boot. Et....c'est tout pour l'instant, ensuite ça attend un reset manuel (une bonne partie des codes du noyau ont été désactivés pour l'instant le temps de revoir l'hyperviseur et l'allocateur kernel (la prochaine release)).
La feuille de route est disponible dans les issues pour les curieux (https://github.com/YannMagnin/vxGOS/issues/30). D'ailleurs, je travail en parallèle sur un langage de programmation perso qui m'aidera à la surveillance ainsi qu'au maintien la base de code, mais je vous en reparlerai surement plus tard quand ça aura avancé et que je pourrais vous montrer des choses.
Donc voila, un petit message pour vous dire que le projet avance, mais que ça reste une tache de fond pour moi !
A plus !