31 KiB
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.
- 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.
- 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...
[TODO] aller chercher sur google la datasheet du composant RAM pour trouver ses specs précises
- “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.
- 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.
En fait je suis un connard et en fait l'addresse est trouvable sous FLASH_OFFSET 0x26... c'est l'addresse en ram ou uboot va aller chercher le kernel la vraie addresse d'offset est 0x00040000
- 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
La on aimerait mettre en place un menu de boot.
Dans un premier temps il faut verifier que CONFIG_MENU et CONFIG_CMD_BOOTMENU soient présents dans la config de U-BOOT. On va donc faire une recherche dans le fichier .config avec le / qui permet de rechercher.
Et malheureusement on ne trouve pas les bonnes valeurs dans le fichier de config.
Je suis ensuite allé chercher dans COMMAND LINE INTERFACE puis BOOT_COMMANDS et j'ai pu voir que l'option Bootmenu n'était pas cochée Je l'ai donc cochée puis j'ai sauvegardé.
Maintenant quand je retourne dans le fichier .config et la je peux y voir les valeurs qu'on attendait être bien présentes et avec "=y" après.
Je pense que j'aurais pu le faire manuellement mais au risque que d'autres valeurs doivent être changées sur le moment et que je les loupes donc c'est mieux de passer par le menuconfig.
EDIT: Il y a aussi une autre chose à modifier, il faut aller activer "CONFIG_AUTOBOOT_MENU_SHOW" car sinon il n'y aura pas de menu au moment du boot ce qui est chiant plus tard.
On peut activer ca sous Boot options > Autoboot options et cocher "show a menu on boot"
Dans la version de U-BOOT que on utilise, on doit faire un changement dans le code source pour permettre de faire fonctionner correctement les inputs clavier.
Dans le répertoire /cmd on peut trouver le fichier bootmenu.c que on peut éditer.
Dans ce fichier il y a une fonction bootmenu_loop(){}
Dans laquelle on rajoute à la fin
if(c=='1')
*key == KEY_UP;
if(c=='2')
*key == KEY_DOWN;
ATTENTION !!!! J'AI PASSE DEUX HEURES A ESSAYER DE COMPILER MAIS J'AVAIS TOUT LE TEMPS DES PROBLEMS DE arm-linux-gcc not found. IL FAUT METTRE DANS LE PATH UN CHEMIN ABSOLU !!!! LA PUTAIN DE SA RACE
Ensuite on peut compiler avec make
[Q8] Quelle est la taille en octet du fichier U-Boot à flasher ?
Sur ma machine virtuelle comme elle ne tourne pas en natif X86 la compilation est plutôt lente.
Mais quand c'est fini, j'imagine que le fichier qui nous intéresse c'est le fichier u-boot.bin et quand je fais un
du -sh u-boot.bin
J'ai une réponse :
760K u-boot.bin
Donc l'image fait apparemment 760kb
[Q9] Est-ce que cette taille est compatible avec la taille maximum d’U-Boot supportée par AT91Bootstrap ?
Dans la question 1.5 de ce fichier on a la réponse, je cite :
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.
Comme 760KB < 786KB ca veut dire que U-Boot en théorie devrait tenir, mais bon ca donne pas une super marge de manoeuvre.
Flash d'AT91 et U-Boot sur la carte
Il faut aller chercher le programme SAM-BA à l'addresse
https://www.microchip.com/en-us/development-tool/SAM-BA-In-system-Programmer
Et comme je suis dans un environnement sans interface graphique il me faut le lien de téléchargement de la version 3.5 avec le lien
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareTools/sam-ba_3.5-linux_x86_64.tar.gz
On peut ensuite
wget https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareTools/sam-ba_3.5-linux_x86_64.tar.gz
Je fais cela à la racine de l'utilisateur par ce que c'est un outil
Et pour décompresser notre tar.gz on va utiliser la commande tar -xf
Dans notre cas tar -xf sam-ba_3.5-linux_x86_64.tar.gz
Ensuite on peut essayer
./sam-ba
SAM-BA Command Line Tool v3.5
Copyright 2018 Microchip Technology
Usage: ./sam-ba [options]
Options:
-v, --version Displays version information.
-h, --help Displays this help.
-t, --tracelevel <trace_level> Set trace level to <trace_level>.
-L, --applet-buffer-limit <SIZE> Set applet buffer limit to <SIZE>
bytes (default 131072).
-x, --execute <script.qml> Execute script <script.qml>.
-p, --port <port[:options:...]> Communicate with device using <port>.
-d, --device <device[:options:...]> Connected device is <device>.
-b, --board <board[:options:...]> Connected board is <board>.
-m, --monitor <command[:options:...]> Run monitor command <command>.
-a, --applet <applet[:options:...]> Load and initialize applet <applet>.
-c, --command <command[:args:...]> Run command <command>.
-w, --working-directory <DIR> Set working directory to <DIR>.
Ce qui nous donne une liste d'arguments disponibles.
Note: la doc est dispo sous doc/index.html dans le répertoire samba et dans l'énoncé on propose d'aller lire doc/samad3.html
Dans l'énoncé on nous parle d'un applet nommé "nandflash" et comme je ne sais pas ce que c'est ou comment l'utiliser je suis allé regarder le fichier "nandflash.html" aussi dispo dans le répertoire doc
Dedans il y a un exemple de commande pour avoir l'aide qui est la suivante
./sam-ba -p serial -d sama5d3 -a nandflash:help
Mais il me manque apparemment une lib nommée libgl, pour la trouver j'ai fait comme plus haut :
sudo apt search libgl | grep dev
Et en demandant à un camarade il semble que le paquet
libgl1-mesa-dev/noble-updates 24.0.9-0ubuntu0.1 amd64
soit le bon. Dans les faits on a pas besoin de la version dev car on ne va pas compiler samba mais bon ca marche donc voila
Maintenant que j'ai les bonnes libs je peux lancer la commande et j'ai le résultat attendu dans la doc
./sam-ba -p serial -d sama5d3 -a nandflash:help
Syntax: nandflash:[<ioset>]:[<bus_width>]:[<header>]
Parameters:
ioset I/O set
bus_width NAND bus width (8/16)
header NAND header value
Examples:
nandflash use default board settings
nandflash:2:8:0xc0098da5 use fully custom settings (IOSET2, 8-bit bus, header is 0xc0098da5)
nandflash:::0xc0098da5 use default board settings but force header to 0xc0098da5
For information on NAND header values, please refer to SAMA5D3 datasheet section "11.4.4 Detailed Memory Boot Procedures".
De ce que j'ai compris on va avoir besoin des actions suivantes avec nandflash
- erase (car on doit dabord effacer la zone de la NAND)
- writeboot (pour écrire le bootloader level 1 at91 avec un header)
- write pour écrire le bootloader level 2 u-boot
On peut commencer par erase la memoire pour voir si notre communication fonctionne avec la carte
./sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash -c erase
CEPENDANT. Pour que cette commande fonctionne il faut des étapes préablables.
- On ouvre PICOCOM sur la carte comme avant.
- On retire le jumper JP5 (le jumper le plus proche du port USB d'alim)
- On appuie sur le bouton RESET (bouton le plus proche du derrière de la carte avec marqué RESET)
- On est sensé voir le message "RomBoot" dans le picocom
- On ferme picocom
On peut ensuite lancer notre commande.
Cependant j'ai perdu beaucoup de temps à ne pas comprendre pourquoi ca ne voulait pas marcher. Mais comme je suis sur une VM j'avais pas pensé à autoriser le second USB d'atteindre la VM. En fait Picocom peut parler avec le port série, cependant le port usb d'alim est celui par lequel on va flasher notre carte. Il faut donc que les deux USB soient autorisés sur la carte.
Et maintenant la commande devrait marcher. Cependant c'est une mauvaise pratique de tout erase comme je l'ai fait. Je l'ai fait juste pour tester.
Dans l'idéal il faut calculer exactement la zone de erase. C'est ce qu'il faudra faire les prochaines fois.
Dans la doc pour écrire Sama5d3-xplained pour écrire notre bootloader at91 il faudrait utiliser la commande
$ sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash -c writeboot:bootstrap.bin -c verifyboot:bootstrap.bin
Seul problème c'est que apparemment il faudrait ajouter un genre de header pour que cela fonctionne et ce dernier demande quelques calculs.
On peut ajouter un header avec le -a
Et pour avoir les infos à propos de ca on peut effectuer la commande :
./sam-ba -p serial -d sama5d3 -a nandflash:help
Syntax: nandflash:[<ioset>]:[<bus_width>]:[<header>]
Parameters:
ioset I/O set
bus_width NAND bus width (8/16)
header NAND header value
Examples:
nandflash use default board settings
nandflash:2:8:0xc0098da5 use fully custom settings (IOSET2, 8-bit bus, header is 0xc0098da5)
nandflash:::0xc0098da5 use default board settings but force header to 0xc0098da5
For information on NAND header values, please refer to SAMA5D3 datasheet section "11.4.4 Detailed Memory Boot Procedures".
On devrait ajouter à notre commande 'nandflash:2:8:0xc0098da5' mais en faisant nos calculs pour ajouter notre header
Dans l'énoncé il est mentionné que on veut utiliser un IOSET de 1 et un bus_width de 8 donc notre commande ressemblerait plutôt 'nandflash:1:8:0xc0098da5'
Et maintenant on veut calculer notre header
- 4 premiers bits : 12 (0xC) 1100
- 1 bit à 0
- 9 bits pour faire 36 000100100
- 2 bit pour faire 00
- 3 bit pour faire 1 (001) 001
- 9 bits pour faire 64 001000000
- 3 bits pour faire 2 010
- 1 bit pour faire 1 1
full 1100 0000 1001 0000 0010 0100 0000 0101
0xC0902405
Header final : 0xC0902405
Et donc notre commande ressemble désormais à ca
./sam-ba -p serial -d sama5d3 -a nandflash:1:8:0xC0902405
[Q10] Donnez la commande complète vous ayant permis de flasher AT91Bootstrap et U-Boot dans la NAND de votre carte.
Voici la commande complete pour at91
./sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash:1:8:0xC0902405 -c writeboot:sama5d3-bootstrap.bin -c verifyboot:sama5d3-bootstrap.bin
en imaginant que on aie amané le at91 bootstrap dans le dossier de sam-ba
maintenant la commande pour u-boot de la doc est la suivante $ sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash -c write:u-boot-sama5d3-xplained.bin:0x00040000 -c verify:u-boot-sama5d3-xplained.bin:0x00040000 mais il faut modifier le 0x00040000 avec la bonne addresse à laquelle at91 va regarder
Pour ca on peut revenir à la question 1.4
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.
En fait je suis un connard et en fait l'addresse est trouvable sous FLASH_OFFSET 0x26... c'est l'addresse en ram ou uboot va aller chercher le kernel la vraie addresse d'offset est 0x00040000
On peut donc modifier notre commande pour qu'elle ressemble à ca :
./sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash -c write:u-boot.bin:0x00040000 -c verify:u-boot.bin:0x00040000
Voici donc les commandes à faire pour flasher at91 et bootstrap :
./sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash -c erase
./sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash:1:8:0xC0902405 -c writeboot:sama5d3-bootstrap.bin -c verifyboot:sama5d3-bootstrap.bin
./sam-ba -p serial -b sama5d3-xplained -t 5 -a nandflash -c write:u-boot.bin:0x00040000 -c verify:u-boot.bin:0x00040000
Et donc maintenant on devrait avoir une carte flashée.
Test d'Uboot
Quand on fait un picocom --b 115200 /dev/ttyUSB0 et que on reboot la carte on a bien un bootloader qui fonctionne !!
Après quelques secondes on est greeted par un invite de commande et si on fait un help et on voit que ca répond.
En faisant un bdinfo on récupère :
boot_params = 0x20000100
DRAM bank = 0x00000000
-> start = 0x20000000
-> size = 0x10000000
flashstart = 0x00000000
flashsize = 0x00000000
flashoffset = 0x00000000
baudrate = 115200 bps
relocaddr = 0x2ff44000
reloc off = 0x09044000
Build = 32-bit
Error: ethernet@f0028000 address not set.
current eth = unknown
ethaddr = (not set)
IP addr = <NULL>
fdt_blob = 0x2fb37f50
new_fdt = 0x2fb37f50
fdt_size = 0x0000bf60
lmb_dump_all:
memory.cnt = 0x1
memory.reg[0x0].base = 0x20000000
.size = 0x10000000
reserved.cnt = 0x1
reserved.reg[0x0].base = 0x2fb36d58
.size = 0x4c92a8
arch_number = 0x00000000
TLB addr = 0x2fff0000
irq_sp = 0x2fb37f40
sp start = 0x2fb37f30
Early malloc usage: 14d4 / 2000
setenv permet de créer une variable d'environnement
editenv permet de modifier une variable d'environnement
saveenv permet de sauver l'environnement
par exemple
setenv aled
editenv aled (Et je la set à 64)
echo $aled (retourne 64)
saveenv
Après un reboot
echo $aled (retourne toujours 64 :D)
[Q11] Comment avez-vous inspecté le contenu de la NAND et retrouvez-vous bien le contenu escompté ?
J'ai fais un nand dump off je suis sur que il y a un meilleur moyen mais comme les variables d'environnement sont sauvegardée correctement je ne pense pas avoir besoin d'un moyen plus efficace pour le moment.
Ensuite il est demandé de réaliser un bootmenu avec trois entrées et des timeout infinis et que tout soit selectionnable correctement
[Q12] Listez les commandes que vous avez écrites pour parvenir au résultat demandé.
Je n'ai pas trouvé la réponse dans le support de cours ou dans la doc que l'on avait à notre disposition ou dans le help de u-boot donc j'ai été forcé d'aller sur internet chercher la réponse.
J'ai fini par trouver que pour ajouter des entrées il fallait faire cette commande :
setenv bootmenu_[index] [description];[command]
setenv bootmenu_0 'Boot from a SD Card=echo "booting from sd card"'
setenv bootmenu_1 'Boot from ethernet =echo "booting from ethernet"'
setenv bootmenu_2 'Boot from local =echo "booting from local"'
setenv bootmenu_delay -1
ATTENTION ne pas utiliser de _ nulle part car sinon tout plante...
ATTENTION dans tous les exemples que j'ai vu sur internet il faut utiliser un ";" entre la description et la commande mais ici c'est un "=" ca m'a pas du tout fait perdre mes cheveux et 2h de ma vie c'est cool
ensuite ne pas oublier de faire un saveenv
On a donc un bootmenu qui va s'afficher avec un timeout infini dans lequel on se déplace avec les touches numériques 1 et 2 par ce que on a codé ca comme des chiens dans le code du bootmenu.
On peut selectionner une des 4 entrées (une de plus permet de simplement accèder à la console)
accès en ethernet
Comme je ne suis pas sur ubuntu mais sur macos j'ai du faire des choses un peu différement.
Pour localiser l'interface ethernet j'ai fais un ifconfig dans un fichier puis j'ai branché le cable et j'ai fait un ifconfig dans un autre et j'ai fait un git diff entre les deux fichiers et voici la ligne importante qui a changé :
ether 64:4b:f0:20:6e:10
inet6 fe80::1886:1312:6bbd:bf64%en6 prefixlen 64 secured scopeid 0x17
Donc pour assigner une addresse temporaire à cette interface on peut utiliser :
sudo ifconfig en6 192.168.1.200 netmask 255.255.255.0 up
Pour la forcer à une addresse. Cependant si on redémarre l'interface, le DHCP va la changer. Mais je préfère garder tout comme ca pour l'instant comme ca en cas de problème je peux juste redémarrer mon laptop.
Et le up à la fin de la commande devrait indiquer à l'intreface de s'allumer.
Il faut ensuite config l'interface de notre board rappel :picocom --b 115200 /dev/ttyUSB0
editenv ipaddr ensuite je la set à 192.168.1.201`
editenv serverip ensuite je la set à 192.168.1.202`
editenv ethaddr set à 00:01:02:03:04:05`
NE PAS OUBLIER DE FAIRE UN SAVEENV !!
Et evidemment quand j'essaie de ping ma machine ca marche putain de pas comme d'hab.
j'arrive pas à ping ma propre interface depuis ma machine donc il doit y avoir un autre problème mais je comprends pas quoi
J'ai essayé d'utiliser la commande tcpdump pour voir si je recevais les paquets sur mon interface et effectivement je recois bien un paquet de ma board mais je lui répond pas.
BOOON !!! C'est en fait un problème sur MacOS et j'ai passé genre 1h a debug pourquoi ca voulait pas marcher mais après avoir configuré manuellement l'addresse depuis l'interface graphique ca marche :
=> ping 192.168.1.240
ethernet@f0028000: PHY present at 7
ethernet@f0028000: Starting autonegotiation...
ethernet@f0028000: Autonegotiation complete
ethernet@f0028000: link up, 1000Mbps full-duplex (lpa: 0x2800)
Using ethernet@f0028000 device
host 192.168.1.240 is alive
On peut maintenant communiquer avec la board via ethernet.
Setup TFTP
Sur la machine hôte on peut installer le package sduo apt install tftp-hpa
Ensuite on peut aller changer la config de notre serveur tftpd dans le fichier /etc/default/tftpd-hpa
Exemple
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/home/moi/shared_tfpt"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"
J'ai changé le TFTP_DIRECTORY en /home/moi comme demandé dans l'énoncé
pour appliquer les changements sudo systemctl restart tftpd-hpa
Pour tester je me suis mis dans un autre repertoire et j'ai fait un
tftp localhost
ensuite dans l'invite de commande de tftp j'ai fait un
get test.txt test.txt étant un fichier de test que j'ai créé pour l'occasion
pour sortir de tftp c'est quit
Et quand je sors de l'invite de commande tftp on peut bien voir que le fichier a été copié vers mon repertoire courant avec le bon contenu à l'interieur.
[Q13] Comment pouvez-vous vous assurer que votre serveur TFTPD est bien en attente de connexions (indice : ss. . . ) ?
En cas de problème avec l'autonegiciation c'est intéressant d'essayer de changer le port ethernet utilisé sur la carte.
Pour verifier que tftpd fonctionne, on peut utiliser la commande sudo ss -ulpn | grep :69
SS = socket statistics
sudo ss -ulpn permet de lister les sockets
- -u permet de montrer les sockets udp
- -l affiche les sockets en ecoute
- -p affiche les informations du processus
- -n permet d'afficher le port (utile pour le grep)
et ensuite on fait un grep qui récupère tous les sockets qui utilisent le port 69 qui est le port pour le tftpd
on recoit
UNCONN 0 0 0.0.0.0:69 0.0.0.0:* users:(("in.tftpd",pid=160419,fd=4))
UNCONN 0 0 [::]:69 [::]:* users:(("in.tftpd",pid=160419,fd=5))
UNCONN veut dire que le port est en écoute mais que aucun client n'est connecté.
Pour tester l'histoire on va essayer de transfèrer un fichier texte suivant :
Tu peux pas test!
avec un nom de fichier suivant test.txt
Sur u-boot on peut tenter le coup avec cette commande : tftp 0x22000001 192.168.1.240:test.txt
=> tftp 0x22000001 192.168.1.240:test.txt
ethernet@f0028000: PHY present at 7
ethernet@f0028000: Starting autonegotiation...
ethernet@f0028000: Autonegotiation complete
ethernet@f0028000: link up, 1000Mbps full-duplex (lpa: 0x7800)
Using ethernet@f0028000 device
TFTP from server 192.168.1.240; our IP address is 192.168.1.201
Filename 'test.txt'.
Load address: 0x22000001
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Il y a un problème par ce que je passe depuis une VM et mon bridge doit pas être setup correctement mais normalement wallah ca marche.
[Q14] Comment avez-vous pu vérifier que le fichier a été transféré correctement ? Détaillez votre méthode.
On peut directement aller lire la rom à l'addresse ou le fichier est sensé se trouver. Je n'ai pas la commande la tout de suite mais je l'ajouterai dans le futur.
[Q15] Donnez le contenu du script, comment vous l’avez converti en image et comment vous l’avez récupéré et exécuté depuis U-Boot.
Setup le tftpd sur macos
instructions trouvées sur https://bacnh.com/howto-start-tftp-server-on-macos
sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist
Sur la board :
=> tftp 0x22000001 192.168.1.240:test.txt
ethernet@f0028000: PHY present at 7
ethernet@f0028000: Starting autonegotiation...
ethernet@f0028000: Autonegotiation complete
ethernet@f0028000: link up, 1000Mbps full-duplex (lpa: 0x7800)
Using ethernet@f0028000 device
TFTP from server 192.168.1.240; our IP address is 192.168.1.201
Filename 'test.txt'.
Load address: 0x22000001
Loading: #
0 Bytes/s
done
Bytes transferred = 18 (12 hex)
On a donc bien réussi à transfèrer le fichier sur la board mais maintenant si on veut le voir on doit aller à l'addresse 0x22000001 avec la commande md
md 0x22000001 0x10
22000001: 70207554 20787565 20736170 74736574 Tu peux pas test
22000011: 8a4d0a21 a2a81380 a9c0a46c c0001be0 !.M.....l.......
22000021: 03020040 10381110 48a02044 82a49b12 @.....8.D .H....
22000031: 78241d82 c2e4924d 0014100e 41080120 ..$xM....... ..A
Et on peut voir que le fichier a bien été transfèré :)