Je crois que pour les arm, tu n'as pas de bios, non? Du coup il faut avoir une distribution adaptée à cette machine, ou utiliser le bootloader fourni par le constructeur, et ça peut être compliqué...
C'est ça grosso modo.
Sur ARM le CPU démarre avec des réglages minimaux internes puis va chercher le reste de la config d'amorçage selon un ordre de priorité plus ou moins fixe : D'abord EEPROM (en SPI ou I2C), puis NAND, SD, SATA (quand c'est disponible) et sur USB. Du coup il est souvent plus facile d'intégrer un u-boot spécifique à la carte dans l'image Linux qui contient aussi les pilotes spécifiques au matériel.
Olimex travaille sur une EEPROM avec un u-boot pour leurs modèles Olinuxino contenant un Allwinner A20. Ça permettrait de faire une image OS unique pour toute la gamme. On trouve d'ailleurs pas mal de vieux matériel avec le chargeur d'amorçage sur EEPROM.
Sur x86, le CPU ne va faire qu'une seule chose au démarrage : lire le contenu du port SPI (donc l'EEPROM) pour lancer le POST.
Le BIOS est plus bas niveau et contient davantage de choses que u-boot comme la découverte de matériel, les tests internes, le réglage interactif de la configuration, la priorité d'amorçage des supports, etc.
la grosse différence avec son ordinateur, c'est que le 701 est un x86.
Ça facilite beaucoup les choses mais à partir du moment où tu as le bon chargeur d'amorçage u-boot ou un UEFI (ça existe aussi sur ARM), tu peux installer un OS, ajouter GRUB (pour faire du multiboot), etc.
Le problème c'est pas vraiment de choper un u-boot fonctionnel pour l'appareil (suffit de piquer celui utilisé pour le système préinstallé) mais qu'ici le SOC a un support déplorable.
Il n'est pas dans la branche principale du noyau Linux et le suivi semble abandonné depuis plus de cinq ans. Puis c'est de l'armV5, c'est très vieux, extrêmement lent comparé à un Core-m et pas supporté par les distributions donc aucune image préconstruite, aucun dépot de binaires, obligation de tout compiler soi-même. Et évidemment pour ce genre de petite machine, vaut mieux cross-compiler.
[^] # Re: ARM
Posté par Anonyme . En réponse au message choix de Distribution, aide. Évalué à 3.
C'est ça grosso modo.
Sur ARM le CPU démarre avec des réglages minimaux internes puis va chercher le reste de la config d'amorçage selon un ordre de priorité plus ou moins fixe : D'abord EEPROM (en SPI ou I2C), puis NAND, SD, SATA (quand c'est disponible) et sur USB. Du coup il est souvent plus facile d'intégrer un u-boot spécifique à la carte dans l'image Linux qui contient aussi les pilotes spécifiques au matériel.
Olimex travaille sur une EEPROM avec un u-boot pour leurs modèles Olinuxino contenant un Allwinner A20. Ça permettrait de faire une image OS unique pour toute la gamme. On trouve d'ailleurs pas mal de vieux matériel avec le chargeur d'amorçage sur EEPROM.
Sur x86, le CPU ne va faire qu'une seule chose au démarrage : lire le contenu du port SPI (donc l'EEPROM) pour lancer le POST.
Le BIOS est plus bas niveau et contient davantage de choses que u-boot comme la découverte de matériel, les tests internes, le réglage interactif de la configuration, la priorité d'amorçage des supports, etc.
Ça facilite beaucoup les choses mais à partir du moment où tu as le bon chargeur d'amorçage u-boot ou un UEFI (ça existe aussi sur ARM), tu peux installer un OS, ajouter GRUB (pour faire du multiboot), etc.
Le problème c'est pas vraiment de choper un u-boot fonctionnel pour l'appareil (suffit de piquer celui utilisé pour le système préinstallé) mais qu'ici le SOC a un support déplorable.
Il n'est pas dans la branche principale du noyau Linux et le suivi semble abandonné depuis plus de cinq ans. Puis c'est de l'armV5, c'est très vieux, extrêmement lent comparé à un Core-m et pas supporté par les distributions donc aucune image préconstruite, aucun dépot de binaires, obligation de tout compiler soi-même. Et évidemment pour ce genre de petite machine, vaut mieux cross-compiler.