• # Il faut l'apprivoiser

    Posté par (site web personnel) . En réponse au journal Debian, installations automatiques et ARM. Évalué à 10. Dernière modification le 17 janvier 2019 à 11:08.

    Comme pour tous les outils, il y a de l'apprentissage...

    Déjà, il faut bien comprendre que U-boot vient du monde de l'embarqué, avec toutes les casseroles que ça implique, et du coup, pas le choix, il faut "s'y mettre".
    Concernant le process de boot par exemple, on est sur des processeurs qui n'accèdent qu'à une toute petite RAM directement intégrée au SoC, la SRAM (quelques dizaines de ko tout au plus), bien trop petite pour faire plus qu'une initialisation basique. Donc une version minimale d'U-boot y est chargée pour initialiser la RAM et pouvoir y mettre le U-boot complet (SPL), qui va ensuite initialiser les périphériques internes (notamment réseau et stockage) pour pouvoir charger (commandes tftp, mmc read, fatload etc...) et booter le noyau (bootm ou booti).
    Et encore, sur ARM64 par exemple, c'est pire, il y a ARM Trusted Firmware au milieu de tout ça...

    Ceci dit, je suppose que tu utilises une version ancienne et/ou sans en personnaliser la configuration. U-boot, c'est comme le kernel : si tu as un besoin spécifique, make menuconfig est ton meilleur ami.

    En l'occurrence, tu n'as sans doute pas vu qu'une commande pxe existait, ce qui t'aurait surement fait gagner du temps.
    De même, packager ton kernel dans un format uImage contenant kernel + initrd (ou kenel + dtb, je ne me rappelle plus) est une bonne idée, voire même, avec une version raisonnablement récente, une fitImage contenant kernel + initrd + dtb. Moins de fichiers à gérer, des scripts plus digestes, etc...

    surtout le fait de faire des one-liners

    C'est une question de formatage : les scripts sont stockés dans des variables d'environnement, et une variable ne peut contenir qu'une ligne de texte. Quand on fait les choses bien, on découpe son script en plusieurs variables (des "fonctions" en quelques sortes) qu'on va appeler via run, mais je te l'accorde, ça demande un peu de pratique pour être à l'aise avec ça.

    Concernant la documentation, tu as un répertoire doc dans les sources qui, a l'instar du kernel, contient énormément d'infos utiles. Et s'il te manque une info, tu la trouveras dans le code lui-même, qui est raisonnablement bien rangé (le répertoire cmd en particulier est d'une aide précieuse, puisqu'il contient le code de toutes les commandes du shell).

    PS: Pour la suite, tu peux aller regarder cet article qui parle de la problématique des MàJ avec système de fallback sous U-boot