Added my progress

Tp1.md

@@ -0,0 +1,194 @@
+# Travail pratique 1
+
+## [Q1] Quelle est l'architecture processeur de la carte SAMA5D3 Xplained
+
+C'est un processeur d'architecture ARM CORTEX A5
+
+Quelques specs :
+- Supporte le jeu d'instruction Thumb2
+- Dispose d'un MMU (Presque essentiel pour linux embed)
+- Dispose d'une unité de calcul a virgule flottante
+
+Il m'est demandé ensuite dans le TP d'aller chercher une Toolchain compatible avec certains critères tels que GCC13+ ou l'API Musl
+
+Je suis allé sur https://toolchains.bootlin.com
+
+Ensuite j'ai choisi de voir uniquement les toolchains destinées aux processeurs ARM A5 basées sur l'API Musl. 
+
+Il existe aussi des versions avec GlibC mais cette librairie est trop lourde et fait des executables trop lourds eux aussi pour ce que l'on veut faire
+
+J'ai ensuite choisis la seule toolchain qui supportait GCC 13+
+
+## [Q2] Quel est le nom complet de la toolchain téléchargée ?
+
+Le nom complet est armv5-eabi--musl-stable-2024.05-1
+
+- Armv5 veut dire que la toolchain contient un GCC qui va compiler pour un processeur ARM5 V5.
+- Les termes EABI indiquent si la target est sensée être en Big endian, si elle supporte les floats etc...
+- musl indique la librairie C utilisée. Ici Musl pour sa taille réduite et la taille minimale des exectuables ainsi créés
+- stable veut dire que c'est une version normalement plus stable que les versions bleeding edge
+- La date nous indique simplement quand la toolchain a été build
+
+Dans le nom on ne voit pas la version de GCC, peut-être que on peut la déduire avec la date mais en tous cas sur bootlin la version GCC était indiquée comme étant 13.3.0
+
+## [Q3] Quelle est la version complète de GCC de votre chaine de compilation
+
+On peut voir dans le dossier BIN de la toolchain différents executables qui ont des noms du genre :
+
+`arm-buildroot-linux-muslabi-gcc-13.3.0`
+
+Donc j'en déduis que la version de FCC est 13.3.0 mais pour en être sur il faudra l'executer ce que je vais faire un peu plus bas dans ce tp
+
+## [Q4] Quel est le nom de la librairie C de votre chaine de votre toolchain ainsi que son numéro de version
+
+La toolchain a été choisie justement par ce que sa librairie C était Musl et on peut voir dans les noms des executables que vraissemblalement c'est bien le cas.
+
+Je ne sais pas comment connaitre sa version car il n'y a pas d'executable juste Musl. Et en executant ces derniers je n'ai la version que des outils eux mêmes et pas de Musl
+
+## [Q5] Dans quel répertoire se trouvent les binaires principaux de votre toolchain ?
+
+Tous les outils comme GCC les linkers etc... sont stockés sous 
+
+`toolchain/bin`
+
+Il est ensuite demandé d'ajouter au PATH ce repertoire pour que l'on puisse utiliser ces différents outils depuis nimporte ou dans notre machine
+
+Pour ce faire il faut aller éditer le fichier .Bashrc qui se trouve à la racine utilisateur 
+
+`cd ~`
+`vim .bashrc`
+
+Dans le fichier bashrc si on n'a jamais rien ajouté au path on vient à la fin du fichier ajouter :
+
+```bash
+# Custom PATH
+export PATH="$PATH:~/tp/toolchain/bin"
+```
+
+Attention il est important de ne pas oublier le `$PATH:` avant le lien vers notre toolchain.
+
+Si on l'oublie on override le PATH existant et on aurait plus accès aux bin de notre linux ce qui serait vraiment dommage.
+
+`/tp/toolchain`c'est simplement le chemin vers ma toolchain
+
+## [Q6] Testez votre toolchain avec un petit programme c de votre choix et donnez sa taille
+
+Pour ce test voici le code C que je vais essayer de compiler :
+
+```C
+#include <stdio.h>
+
+int main(){
+    printf("Hello, world !");
+}
+```
+
+Ce qui est juste le code minimum en C.
+
+Voici la commande que j'utilise pour compiler ce code avec la toolchain 
+
+`arm-buildroot-linux-muslabi-gcc test.c -o test-arm`
+
+Cette commande utilise le GCC de ma toolchain pour compiler mon fichier test.c
+
+Ensuite pour voir la taille de mon fichier j'utilise 
+
+`du -sh test-arm`
+
+du est la commande disk usage et avec l'argument -s je summarize et avec le -h je le rend Human Readable ce qui veut dire que les unités sont plus faciles à comprendre
+
+Cette commande nous retourne 
+
+`8.0K   test-arm`
+
+Notre executable fait donc 8000 bits ce qui est très peu !
+
+## [Q7] Que se passe-t-il si vous essayez d'executer l'executable obtenu sur votre machine de developpement ? Quelle est la raison de l'erreur obtenue ?
+
+Si on essaie d'executer test-arm on obtient :
+
+`./test-arm`
+
+`bash: ./test-arm: cannot execute binary file: Exec format error`
+
+Cette erreur indique en général un problème d'architecture. Elle indique que le fichier binaire que l'on a essayé d'executé n'est pas compatible avec l'architecture processeur de notre machine.
+
+Comme personnellement je code sur un MAC M3 j'ai souvent eu cette erreur car la toolchain a été build pour que GCC tourne sur une architecture X86 qui n'est pas la mienne.
+
+Pour contourner ce problème j'ai bien galèrer mais j'ai fini par trouver une solution qui conciste à utiliser une machine virtuelle qui émule du X86 avec un ubuntu server car un ubuntu Desktop est trop lent à virtualiser.
+
+J'aurais aussi pu simplement build ma propre toolchain avec l'idée de faire tourner GCC sur arm mais je n'avais pas envie de me lancer la dedans
+
+## [Q8] Quelle est l'architecture cible exacte de l'exectuable compilé précédemment.
+
+Normalement cela devrait être un executable destiné à des processeurs de type ARM V5.
+
+## [Q9] Comment pouvez-vous assurer avec certitude que le code binaire généré correspond bien à cette architecture ?
+
+Je peux m'en assurer en utilisant la commande 
+
+`file test-arm`
+
+qui me retourne
+
+`test-arm: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-arm.so.1, not stripped`
+
+Cela me permet de voir que ma target est correcte avec un processeur ARM V5 EABI 32 bits
+
+On peut comparer avec un fichier que j'ai compilé avec le GCC de ma machine
+
+Déja il fait 16000 bits ce qui est le double de taille
+
+Et ensuite si je fais 
+
+`file test-x86`
+
+la réponse :
+
+`test-x86: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]blablabla, for GNU/Linux 3.2.0, not stripped)`
+
+## [Q10] A titre de comparaison, compilez à nouveau votre petit programme C, mais en executant une edition de lien statique. Quelle est la taille de ce nouvel executable
+
+Pour ce faire j'utilise la commande 
+
+`arm-buildroot-linux-muslabi-gcc -static test.c -o test-arm-static`
+
+Ce qui nous donne un nouvel executable et si on utilise la commande 
+
+`du -sh test-arm-static`
+
+expliquée plus haut on obtient 
+
+`44K    test-arm-static`
+
+Ce qui veut dire que on est passé de 8kb à 44kb car on a du inclure la librairie stdio.h dans l'executable si je ne dis pas de betise
+
+## [Q11] Expliquez la différence de taille obtenue
+
+Comme tout juste expliqué, de ce que j'ai compris dans une execution statique on a un exectuable qui doit contenir tout ce dont il a besoin pour tourner et donc on ajoute par exemple dans notre cas la lib stdio.h
+
+Pour comparer j'ai fait la même chose avec mon gcc de ma machine et après avoir compilé en statique un simple hello world on se retrouve avec un fichier qui fait 768KB ce qui est IMMENSE par rapport aux pauvres 44kb de Musl
+
+De ce qu'on a entendu en cours, la raison pour laquelle on utilise Musl est justement par ce que les executables surtout ceux statiques sont beaucoup moins lourds
+
+## [Q12] Quelle est la taille de chaque executable après la suppression des symboles avec strip
+
+Evidemment on ne peut pas utiliser le strip de notre machine. Il faut utiliser le strip de notre toolchain et dans mon cas cela donne une commande comme ca 
+
+`arm-buildroot-linux-muslabi-strip test-arm-static`
+
+Et maintenant quand je fais un 
+
+`du -sh test-arm-static`
+
+je recupère
+
+`28K    test-arm-static`
+
+J'ai donc divisé par 2 la taille de mon executable
+
+De ce que j'ai pu lire sur internet, la fonction strip retire tous les symboles et toutes les informations de debug ce qui peut réduire drastiquement la taille de l'executable.
+
+Ca ne devrait en rien impacter les performances de l'executable mais il devient plus dur de le débug.
+
+Voila c'est la fin de ce TP. J'ai passé 5-6h dessus je pense mais c'est ma faute car j'ai décidé de daily drive une machine ARM alors que tout le monde à l'HEPIA semble être sur des architectures X86

Tp2.md

@@ -0,0 +1,249 @@
+# Travail Pratique 2
+
+## Bootloaders shinanegans
+
+## Connection à la carte
+
+On a un cable usb serie avec 4 couleurs 
+
+- Noir = Ground
+- Rouge = +5v
+- Blanc = RX
+- Vert = TX
+
+On trouve les ports à côté du port RJ45 de la carte quand on la tient avec le dit port sur la droite.
+
+Après avoir branché le cable usb et en allant dans le dossier /dev de ma machine. Un 'ls' me permet de voir que le ttyUSB0 est bien apparu.
+
+`tail /var/log/kern.log`
+
+Je me suis rajouté dans le groupe dialout avec la commande
+
+`usermod -a -G dialout $USER`
+
+et 
+
+`su $USER`
+
+Pour relancer un shell avec les privileges
+
+pour me connecter en série à la carte on utilise picocom avec la commande :
+
+`picocom --b 115200 /dev/ttyUSB0`
+
+Et grâce à ca on se retrouve avec un invite de commandes
+
+Pour sortir c'est `ctrl+a` et `ctrl + x`
+
+Ensuite dans le répertoire des bootstraps je clone le répo de at91
+
+`http://github.com/linux4sam/at91bootstrap`
+
+Grâce à la commande `git tag`
+
+On peut voir toutes les versions disponibles et ensuite avec 
+
+`git checkout v4.0.9`
+
+On peut naviguer sur la version qui est demandée dans l'énoncé
+
+Dans le répertoire configs on peut voir pleins de fichiers avec des noms à coucher dehors
+
+## [Q1] Quel fichier de configuration avez vous choisi ?
+
+Déja on sait que notre Board s'appelle Sama5d3... donc si on cherche parmis toutes les configs celles qui commencent par ce préfixe il n'en reste plus que 9
+
+Parmis ces 9 on peut chercher les mots u-boot et on peut se rappeller que le mot clé Xplained nous intéresse et il ne reste plus que deux options.
+
+Une version NF et une version SD. Je dirais que SD veut dire SD card et NF Nand flash
+
+Comme c'est la nandflash qui nous intéresse je pense que le bon nom de config est le 
+
+`sama5d3_xplainednf_uboot_defconfig`
+
+Depuis le repertoire at91bootsrap on peut executer
+
+`make mrproper`
+
+et ensuite on peut tenter un 
+
+`make sama5d3_xplainednf_uboot_defconfig`
+
+Attention ne pas mettre /config/sama5d3... par ce que c'est pas le fichier que il veut c'est simplement son nom
+
+On peut maintenant essayer 
+
+`make menuconfig`
+
+Mais il manque des libs donc pour trouver la bonne j'ai utilisé
+
+`apt-cache search ncurses | grep lib | grep dev`
+
+Et une des lib s'appellait `libncurses-dev` et donc après un 
+
+`sudo apt install libncurses-dev`
+
+la commande make menuconfig fonctionne !
+
+Une fenêtre graphique s'ouvre et on peut naviguer dans les menus un peu comme dans un bios.
+
+On doit verifier différentes informations.
+
+1. La carte cible correspond à votre carte — LeCPU est à 528MHz
+
+Pour trouver ces informations il faut aller sous `MPU PRODUCT` et la on a une liste de cpus et on peut voir notre modèle la SAMA5D3 qui est bien selectionnée.
+
+Ensuite on va sous `CLOCK SIGNAL` -> `CPU clock` et on voit bien que l'option 528mhz est bien selectionnée.
+
+2. Il y a bien 256MB de RAM
+
+Pour ca j'ai pas trouvé honnêtement mais dans le menu `DRAM` -> `DRAM PARTS` je vois que la ram DDR2 est selectionnée et que c'est le seul champ qui porte le nom de notre carte SAMA5D3 et avec un identifiant MT47H64M16 x2 et honnêtement je sais pas complêtement ce que ca veut dire mais l'info doit être la...
+
+3. “Next Software Type” est bien “U-Boot”
+
+Pour ca on peut le voir directement depuis le menu principal avec un champ qui s'appelle `Next software type` et la on voit direct que c'est marqué U-BOOT mais on pourrait aussi choisir LINUX KERNEL ou Android par exemple.
+
+4. A quelle adresse en NAND AT91Bootstrap trouvera U-Boot
+
+Dans `U-BOOT STORAGE SETUP` on peut voir trois valeurs hexa qui donnent des infos.
+
+L'addresse dans la ram ou on pourra trouver l'image de U-BOOT se trouve en `0x26F00000` C'est donc la que le bootloader de niveau 1 doit aller chercher les infos pour lancer U-BOOT complet de ce que j'ai compris.
+
+5. Quelle est la taille maximale d’U-Boot configurée dans AT91Bootstrap
+
+On peut chopper cette info juste au dessus de l'addresse de U-BOOT. Ici c'est 0x000C0000. C'est pas la taille MAX mais la taille directement de l'image qui est exprimée en byte j'imagine et ca fait 786432 bytes ou 786kb ce qui parait cohérent.
+
+## [Q2] A quelle adresse se trouve U-Boot en flash NAND et quelle est la taille maximale de celui-ci (donnez les tailles en hexadécimal et en base 10) ? (rappel : l’outil qalc permet de réaliser des conversions de bases)
+
+J'ai pas tout compris de cette question par rapport à la précédente. Je vais donc partir du principe que c'est une question redondante des deux précédentes par ce que je ne vois aucune autre infos à propos de U-BOOT que celles que j'ai déja notée plus haut.
+
+## Compiler le bootloader
+
+Avant de tenter une quelconque compilation il faut se rappeller que pour Cross Compile il faut changer certaines variables d'environnements pour que notre machine utilise le bon gcc linker etc...
+
+On peut le faire en l'écrivant dans chaque commande mais c'est un coup à l'oublier. On va donc faire comme dans le cour.
+
+On va ajouter dans notre -bashrc la variable d'environnement CROSS_COMPILE à arm-linux-
+
+On édite notre fichier .bashrc et à la fin on ajoute 
+
+`export CROSS_COMPILE=arm-linux-`
+
+On peut ensuite verifier que ca a marché en ouvrant un nouveau terminal et en faisant 
+
+`echo $CROSS_COMPILE` et en voyant que ca nous renvoie bien `linux-arm-`
+
+Maintenant on devrait pouvoir compiler avec la commande `make`
+
+Je me retrouve avec une erreur comme quoi il n'arrive pas à trouver mon gcc alors que je peux complêtement accèder à mon gcc depuis le repertoire du bootloader at91...
+
+Après quelques recherches j'ai lu que il se pouvait que make n'utilise pas le bon shell et que donc le fichier .bashrc ne soit pas lu.
+
+J'ai donc ajouté `SHELL := /bin/bash` tout en haut du MakeFile et j'ai ensuite pu compiler
+
+A la fin de la compilation on a même quelques infos intéressantes :
+
+```
+[Succeeded] It's OK to fit into SRAM area
+[Attention] The space left for stack is 110756 bytes
+```
+
+Le fichier binaire peut apparemment tenir dans notre SRAM et il reste encore un peu de place.
+
+## [Q3] Dans quel répertoire se trouve le bootloader que vous venez de compiler, comment se nomme-t-il et quelle est sa taille ?
+
+je suis remonté dans l'invite de commande pour voir si je pouvais trouver des indices et j'ai vu cette ligne
+
+`Size of sama5d3-nandflashboot-uboot-4.0.9.bin is 20316 bytes`
+
+J'ai ensuite été voir dans le répertoire `build/binairies` et avec ca j'ai pu retrouver notre fichier .bin pour avoir sa taille un petit `du -sh` et ca nous donne :
+
+```
+du -sh sama5d3-nandflashboot-uboot-4.0.9.bin
+16K	sama5d3-nandflashboot-uboot-4.0.9.bin
+```
+
+Le fichier .bin fait donc 16kb
+
+
+## Configuration et compilation d'U-BOOT
+
+Pour U-boot on va chercher les fichier à l'adresse "https://ftp.denx.de/pub/u-boot/"
+
+Et on va choisir la version 2021.07 et comme il y a plusieurs liens et que je n'arrive pas à voir ce qui les différencient concrètement je vais prendre le premier qui se nomme `u-boot-2021.07-rc1.tar.bz2`
+
+Après avoir copié et extrait l'archive dans le répertoire /bootloaders je peux passer à la suite.
+
+Apparemment on devrait pouvoir configurer U-BOOT de la même manière que le bootloader at91...
+
+Deja en essayant de faire un `make mrproper` le make me casse les couilles à cause du même problème que sur la At91 quand j'ai voulu compiler. J'ai pas eu ce problème si tôt sur la at91 par ce que je n'avais pas encore changé le .bashrc pour cross compile.
+
+Après avoir changé le MakeFile comme avec le at91 j'ai pu faire le monsieur propre.
+
+## [Q4] Quelle configuration U-Boot avez-vous utilisée ?
+
+Dans le fichier config on peut en voir UN PAQUET !
+
+Pour trouver celle qui m'intéresse `ls | grep sama5d3` ca nous donne deja pas mal moins d'options et avec un `ls | grep sama5d3_xplained` il ne nous reste que deux configs et comme dans l'énoncé il est indiqué que notre U-Boot va trainer dans la NAND alors on peut prendre la config `sama5d3_xplained_nandflash_defconfig`
+
+Pour load la config on peut faire comme avec le bootloader et faire 
+
+`make sama5d3_xplained_nandflash_defconfig`
+
+En faisant cette commande je me tape encore une erreur qui me dit que je n'ai pas BISON (wtf?)
+
+du coup bah `sudo apt install bison` par ce mon linux m'a dit wallah
+
+Encore une erreur cette fois c'est flex qu'il me manque... `sudo apt install flex`
+
+La ca a l'air de marcher. Pas d'erreur même si il me dit que il a pas trouvé mon compilateur. Mais comme il n'indique pas d'erreur je vais faire comme si de rien n'était . Si ca se trouve c'est la facon dont j'ai modifi le makefile qui le fait geuler.
+
+
+La on peut faire un `make menuconfig` pour verifier différentes choses comme précédemment.
+
+## [Q5] Sur quel type de support de stockage est sauvegardé l’environnement d’U-Boot ?
+
+Clairement ce menuconfig est plus fournis que pour le bootloader de niveau 1 et c'est beacoup plus dur de s'y retrouver.
+
+Après genre 10min à me balader j'ai pu trouver que dans le menu `Environnement` on peut choisir dans quel environnement U-BOOT est sauvegardé. Et on peut voir que  "ENVIRONNEMENT IN A NAND DEVICE" est selectionné. C'est donc bien en NAND que U-BOOT sera stocké pour que le bootloader de niveau 1 puisse venir le chercher.
+
+## [Q6] A quelles adresses se trouvent l’environnement et son backup ?
+
+On a l'addresse de l'environnement qui est la suivante :
+
+`0x140000`
+
+Et une addresse vers un environnement redondant qui est donc celui de backup je pense qui est à 
+
+`0x100000`
+
+## [Q7] Quelle est la taille de l’environnement ?
+
+Toujours dans le même menu ENVIRONNEMENT on peut voir que la taille de l'environnement est de 
+
+`0x20000`
+
+Ou 131072 bytes ou juste un peu plus de 131kb
+
+## Menu de boot
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+