microDb

Hardkernel ODROID-XU4 (Samsung Exynos5422)

Hardkernel CoSBClinux

⚡ L’essentiel en 60 secondes

L’ODROID-XU4, conçue par le fabricant sud-coréen Hardkernel et lancée en juillet 2015, s’inscrit dans l’histoire des ordinateurs monocartes comme une évolution directe et plus abordable de l’ODROID-XU3. Présentée initialement à 74 dollars américains, incluant son alimentation et son système de refroidissement, elle a vu son prix baisser à 59 dollars en 2017, devenant ainsi une option très compétitive pour les amateurs de technologies embarquées. Bien que le fabricant ne produise plus activement cette carte, qui est désormais considérée comme un produit « legacy » ou en fin de vie commerciale, son écosystème logiciel reste remarquablement vivant. En 2026, des distributions majeures comme Armbian, Arch Linux ARM et DietPi continuent de publier des images mises à jour, garantissant une compatibilité avec les noyaux Linux récents, tels que la version 6.6.143 disponible via Armbian. Cette longévité logicielle est un atout majeur pour les utilisateurs souhaitant investir dans une plateforme stable et bien documentée, même si la disponibilité des cartes neuves n’est pas garantie en raison de contraintes commerciales actuelles.

Le cœur de cette carte repose sur le processeur Samsung Exynos5422, une puce qui utilise une architecture dite big.LITTLE. Pour comprendre cette technologie, il faut imaginer deux types de cœurs de calcul travaillant ensemble : quatre cœurs puissants Cortex-A15 cadencés à 2,0 GHz pour les tâches lourdes, et quatre cœurs plus économes Cortex-A7 à 1,4 GHz pour les tâches légères. Cette configuration octa-core permet d’optimiser l’équilibre entre performance et consommation d’énergie. Il est crucial de noter que ce processeur est limité à l’instruction set 32 bits (ARMv7-A), ce qui signifie qu’il ne peut pas exécuter les logiciels modernes compilés exclusivement pour l’architecture 64 bits (AArch64). La mémoire vive est fixée à 2 Go de type LPDDR3, une quantité suffisante pour la plupart des usages domotiques ou multimédias légers, mais qui constitue un plafond pour les applications nécessitant beaucoup de mémoire. Le stockage est géré via un port pour carte microSD, mais la véritable force de l’XU4 réside dans son connecteur dédié aux modules eMMC 5.0. Ces modules offrent des vitesses de lecture et d’écriture bien supérieures aux cartes SD classiques, améliorant considérablement la réactivité du système d’exploitation.

En matière de connectique, l’ODROID-XU4 se distingue par une bande passante d’entrée/sortie souvent supérieure à celle de ses concurrents de l’époque. Elle dispose d’une connexion Ethernet Gigabit capable d’atteindre environ 880 Mbps en pratique, ainsi que de deux ports USB 3.0. Cependant, une particularité technique importante doit être prise en compte : le contrôleur Ethernet et les ports USB partagent les mêmes hôtes USB internes via un hub intégré. Cela signifie que si vous branchez plusieurs périphériques USB 3.0 à haut débit simultanément, la bande passante sera partagée, ce qui peut limiter les performances dans des scénarios de stockage réseau intensif. Pour l’affichage, la carte propose une sortie HDMI 1.4a capable d’afficher une résolution de 1080p, mais elle ne prend pas en charge les résolutions 4K. L’audio n’est disponible que via le câble HDMI, le connecteur jack 3,5 mm ayant été supprimé par rapport au modèle XU3. Un module USB externe est nécessaire si l’on souhaite utiliser des haut-parleurs analogiques ou un casque.

La gestion thermique est un aspect critique de cette carte. Les cœurs Cortex-A15 à 2,0 GHz génèrent une chaleur significative. La version standard est livrée avec un ventilateur actif et un dissipateur thermique. Une variante, l’ODROID-XU4Q, propose un refroidissement passif silencieux, mais au prix d’une réduction des performances de 16 % due au bridage thermique automatique. Le système Linux principal gère cette chaleur en augmentant la vitesse du ventilateur à partir de 50 °C et en réduisant la fréquence du processeur si la température atteint 70 °C, avec un arrêt de sécurité à 120 °C. Les utilisateurs doivent également faire preuve d’une grande prudence avec la connectique de débogage série (UART). Contrairement à d’autres cartes qui utilisent des niveaux de tension de 3,3 V ou 5 V, les broches de l’XU4 fonctionnent en 1,8 V. Brancher un adaptateur série standard 5 V sur ces broches risque de détruire définitivement la carte, car il n’existe pas de protection contre les surtensions sur ces entrées/sorties.

L’écosystème graphique est assuré par le GPU ARM Mali-T628 MP6. Ce processeur graphique prend en charge les normes OpenGL ES et OpenCL, permettant non seulement l’affichage fluide d’interfaces graphiques, mais aussi le calcul parallèle sur le GPU pour des tâches comme le traitement d’images ou la simulation. Il est important de noter que le support graphique sous Linux principal (mainline) repose sur des pilotes open source comme Panfrost, tandis que les images fournies par le fabricant utilisent des pilotes propriétaires. Une particularité technique du Mali-T628 est qu’il apparaît souvent comme deux périphériques distincts dans les logiciels de calcul OpenCL, ce qui nécessite une gestion spécifique dans le code. Enfin, la carte est équipée de broches GPIO pour l’extension, permettant de connecter des capteurs ou des actionneurs, mais il est impératif de consulter la documentation officielle pour connaître la correspondance exacte des broches et les niveaux de tension, car une erreur de câblage peut être fatale pour le matériel.

Carte ODROID-M1 équipée d'un lecteur NVMe Samsung 970 EVO Plus, illustrant la compatibilité avec le stockage haute vitesse.
Carte ODROID-M1 équipée d'un lecteur NVMe Samsung 970 EVO Plus, illustrant la compatibilité avec le stockage haute vitesse.Wikipedia — ODROID, CC BY-SA 4.0
Vue de la carte ODROID-H2, mettant en évidence sa conception compacte et ses ports d'entrée/sortie.
Vue de la carte ODROID-H2, mettant en évidence sa conception compacte et ses ports d'entrée/sortie.Wikipedia — ODROID, CC BY-SA 3.0

Schéma de brochage (pinout)

Schéma de brochage du connecteur CON10 30 broches de l'ODROID-XU4 (diagramme officiel Hardkernel)
Schéma de brochage du connecteur CON10 30 broches de l'ODROID-XU4 (diagramme officiel Hardkernel)© Hardkernel — wiki.odroid.com (ODROID-XU4 CON10)

Forum (1 sujet) →

AttrSpecsvérifié
socSamsung Exynos5422 — quad Arm Cortex-A15 @ 2.0 GHz + quad Cortex-A7 @ 1.4 GHz, big.LITTLE (CNX spec tables). Mainline binds it as samsung,exynos5800 (DTS). The cores are ARMv7-A, 32-bit only — the XU4 is not AArch64; Arch Linux ARM packages it under armv7/samsung (ALARM). All eight CPUs appear as cpu0–cpu7 in the mainline thermal cooling maps (common dtsi), i.e. in-kernel HMP today.✔
gpuARM Mali-T628 MP6 (Midgard) — OpenGL ES 3.0/2.0/1.1 and OpenCL full profile; CNX's spec table says "OpenCL 1.1", but the actual vendor driver reports OpenCL 1.2 in clinfo ("Device Name Mali-T628 … Device Version OpenCL 1.2") (CNX OpenCL tutorial, 2018-05-13, retrieved 2026-10-13). ⚠️ The GPU is an Arm Mali, not a PowerVR part — any "PowerVR M628" claim is wrong; every fetched source (CNX announcement, CNX OpenCL article title, spec tables) says Mali-T628 MP6.✔
ram2 GB LPDDR3 PoP @ 750 MHz, 2×32-bit bus, ~12 GB/s bandwidth (CNX, 2015-07-14). No other RAM size exists.✔
storagemicroSD slot (CNX lists "up to 64 GB" tested cards) plus an eMMC 5.0 module socket (16/32/64 GB modules). Mainline drives the eMMC port at 8-bit, HS400, 200 MHz (mmc_0 node: mmc-hs400-1_8v, max-frequency = <200000000>, common dtsi).? non vérifié
video_outfull-size HDMI 1.4a Type-A, up to 1080p — the XU3's DisplayPort output was dropped (CNX, 2015-07-14; CNX, 2017-02-23). CEC is enabled in mainline (&hdmicec status = "okay", common dtsi).✔
audioHDMI audio only — the XU3's ALC audio codec and 3.5 mm jack were removed (CNX, 2015-07-14); mainline sound card is samsung,odroid-xu3-audio, I2S0 → HDMI (XU4 dts sound node). Optional S/PDIF via a USB sound module (CNX spec table).✔
networkingGigabit Ethernet, ~880 Mbps measured with iperf (CNX, 2017-02-23). No WiFi/BT on board — USB Wi-Fi dongles only (CNX). Topology quirk: the GbE MAC hangs off one of the SoC's two USB 3.0 hosts, while the two external USB 3.0 Type-A ports share the second host through an on-board GL352x USB 3.0 hub (4 downstream ports, 2 exposed) — forum analysis by mdel/tkaiser in the CNX 2017-02-23 comment thread.✔
usb2× USB 3.0 host (Type-A, hub-shared as above) + 1× USB 2.0 host. USB OTG was removed vs the XU3 (CNX, 2015-07-14). Both DWC3 hosts run as host-only in mainline (&usbdrd_dwc3_1 { dr_mode = "host" }, XU4 dts).✔
gpio_expansionCNX's spec table lists a 30-pin header (GPIO, IRQ, SPI, ADC) plus a 12-pin header (GPIO, I2S, I2C) (CNX, 2017-02-23). Mainline exposes PWM outputs 0 (fan) and 2 (blue heartbeat LED) (XU4 dts &pwm comment). The serial console header is 1.8 V logic — users report killing boards with 5 V UART adapters; "the UART is 1.8V… there is not overvoltage protection on the IO pins, only on the power plug" (forum users memeka/Mihai in the CNX 2017-02-23 comments).✔
power5 V/4A adapter, 5.5/2.1 mm barrel jack (CNX spec tables, both articles).? non vérifié
thermal_behaviour_mainline_policy_from_the_common_dtsiPWM fan ramps at 50/60/70 °C (active trips), CPU passive throttling at 70 °C (−2 DVFS steps, ≈1.8/1.2 GHz) and 85 °C (down to ≈600 MHz), critical 120 °C; separate GPU thermal zone with the same scheme.? non vérifié
miscpower button wired to the S2MPS11 PMIC PWRON pin (mainline gpio-keys node), power + RGB status LEDs, blue heartbeat LED (PWM2, linux,default-trigger = "heartbeat"), RTC (CNX spec table).? non vérifié
dimensions_weight82 × 58 × 22 mm, 60 g with fan, 38 g bare (CNX, 2017-02-23).✔
  • Fabricant : Hardkernel Co., Ltd. (Corée du Sud), marque « ODROID ». L'arbre de périphériques (device tree) mainline Linux identifie la carte comme model = "Hardkernel Odroid XU4" avec compatible = "hardkernel,odroid-xu4", "samsung,exynos5800", "samsung,exynos5" (torvalds/linux: arch/arm/boot/dts/samsung/exynos5422-odroidxu4.dts, consulté le 2026-10-13).
  • Année d'introduction : 2015 — annoncée par CNX Software le 2015-07-14 comme « a smaller and cheaper version of ODROID-XU3 » (CNX Software, 2015-07-14, consulté le 2026-10-13).
  • Prix au lancement : 74 $ US en juillet 2015, alimentation 5 V/4 A et dissipateur + ventilateur montés inclus (CNX, 2015-07-14). Prix baissé à 59 $ (adaptateur non fourni, +5,50 $) le 2017-02-23 (CNX, 2017-02-23, consulté le 2026-10-13).
  • Statut : Legacy / fin de vie en pratique, mais étonnamment bien maintenu. La variante XU4Q à refroidissement passif est sortie en avril 2017 comme dernière carte de la famille XU4 (CNX, 2017-04-27, consulté le 2026-10-13). Le support communautaire est toujours d'actualité en 2026 : Armbian fournit des images construites le 2026-08-11 avec le noyau 6.6.143 (armbian.com/odroid-xu4, consulté le 2026-10-13), Arch Linux ARM fournit toujours une plateforme armv7/samsung/odroid-xu4 (page plateforme ALARM, consulté le 2026-10-13), et DietPi liste le XU4 parmi le matériel pris en charge (documentation matériel DietPi, consulté le 2026-10-13).
  • Variantes : - ODROID-XU4 — refroidissement actif (dissipateur + ventilateur), 60 g avec ventilateur / 38 g sans (CNX, 2017-02-23). - ODROID-XU4Q — carte identique, ventilateur remplacé par un grand dissipateur passif (avril 2017, même prix de 59 $) (CNX, 2017-04-27). - Accessoires/kits, pas des variantes de carte : boîtier NAS CloudShell pour HDD 2,5″ (kit à 39 $ au lancement, CNX, 2015-08-01), modules eMMC (16/32/64 Go), dongles Wi-Fi USB (CNX, 2017-02-23).
  • Contexte de la gamme : réduction de gravure (die-shrink) directe de l'ODROID-XU3 (2014, même Exynos5422, 179 $) et du XU3-Lite (99 $) ; compatible au niveau logiciel avec le XU3 (CNX, 2015-07-14 ; index ODROID Wiki XU4, instantané 2023-11-14 via Wayback, consulté le 2026-10-13).

＋ Points forts

  • Premier SBC sous les 100 $ avec une vraie bande passante d'E/S : USB 3.0 et Gigabit Ethernet sur une carte à 59–74 $ — "USB 3.0 and Gbit Ethernet are still key competitive features" et, en 2017, "the only beefy SBC out there with reasonable IO bandwidth" (tkaiser, commentaires CNX 2017-02-23 ; ~880 Mbps en iperf, SSD USB3 ~300 Mo/s sur le noyau 4.9 d'après le même fil).
  • Le Cortex-A15 le plus cadencé jamais embarqué sur un SBC (cluster big à 2,0 GHz) — "likely remain the ARMv7 performance leader forever" (blu, même fil de commentaires) ; octa-core big.LITTLE avec HMP fonctionnel sur mainline (8 CPU dans les cartes de refroidissement du DTS).
  • OpenCL full profile sur une carte bon marché : pilote OpenCL 1.2 propriétaire pour le Mali-T628 MP6, utilisable pour du calcul (le raytracing, la vision par ordinateur et la simulation financière ont été cités comme usages) (tutoriel CNX OpenCL, 2018-05-13).
  • Socket eMMC 5.0 (HS400 dans le mainline) — bien plus rapide et plus durable que les concurrents uniquement SD de son époque (CNX 2015-07-14 ; dtsi mainline).
  • Compatibilité logicielle avec le XU3 — écosystème de pilotes mûr dès le premier jour, et toute la gamme d'accessoires du XU3 reprise (index ODROID Wiki).
  • Pensé pour le cluster par conception : petite carte de 82×58 mm, bouton d'alimentation, RTC, ventilateur piloté en PWM avec governor thermique mainline, et un boîtier NAS à 39 $ (CloudShell) en ont fait un nœud naturel pour les clusters et NAS à faible coût (CloudShell CNX 2015-08-01).

− Points faibles

  • Thermal throttling / chaleur : le cluster A15 à 2,0 GHz a besoin du refroidissement actif ; "performance is nice, too hot however" (commentaire d'utilisateur, CNX 2017-02-23). Les tests Hardkernel sur le XU4Q : sans ventilateur à 2,0 GHz coûte 16 % sur sysbench (420 s contre 362 s), 6 % à 1,8 GHz, et zéro throttling exige de plafonner à 1,2 GHz ; compilation du noyau en 25 min (XU4 + ventilateur) contre 30 min (XU4Q) (CNX, 2017-04-27).
  • Bruit du ventilateur : "a frequent complaint about the board… it requires a fan to operate at full speed, and makes noise" — la raison affichée de l'existence du XU4Q (même article CNX du 2017-04-27).
  • UART console 1,8 V, pas de protection contre les surtensions sur les IO : au moins un cas documenté de carte rendue inutilisable par un adaptateur USB-UART 5 V ("There is not overvoltage protection on the IO pins, only on the power plug… oDroid support said that the board is fried", utilisateurs Mihai/memeka, commentaires CNX 2017-02-23).
  • Limites de la topologie USB3 partagée : le GbE occupe un hôte USB 3.0 ; les deux ports USB 3.0 partagent l'autre hôte via le hub GL352x embarqué, donc deux SSD partagent la bande passante, et des hubs en cascade peuvent casser UAS (analyse mdel/tkaiser, même fil de commentaires). Planifiez les E/S du NAS en conséquence.
  • Bugs de la pile graphique Mali propriétaire (époque 3.10/4.4) : Ubuntu livré en sortie d'usine embarquait un GPU instable surcadencé, pas de Chromium/VLC accéléré matériel par défaut, et un bug du pilote MALI provoquant des écrans noirs à la sortie des applications plein écran (utilisateur Peter Bauer, commentaires CNX 2015-07-14). Le pilote X11 EXA était aussi gourmand en CPU ("uses an entire big core for surface presentation", blu, commentaires CNX 2017-02-23).
  • Division du périphérique OpenCL : le Mali-T628 MP6 s'énumère comme deux périphériques OpenCL (4 cœurs + 2 cœurs), ce que le code de calcul naïf doit gérer (blu, commentaires CNX 2017-02-23 ; vidage clinfo dans l'article OpenCL du 2018-05-13).
  • Piège du noyau propriétaire hérité : les premières images tournaient sur un noyau propriétaire 3.10 avec un big.LITTLE non mainline ; Hardkernel et la communauté ont tout migré vers 4.9 LTS (mises à jour promises jusqu'à début 2019) et le wiki documente la migration (CNX 2017-02-23 ; index ODROID Wiki).
  • Plafond 32 bits + 2 Go : ARMv7-A uniquement et 2 Go de RAM — les conteneurs préconstruits modernes réservés à arm64 et les charges utiles > 2 Go sont hors sujet (déduction de la chemin de plateforme armv7 d'ALARM et des tableaux de specs CNX).
  • Retour d'expérience expert expert — expert-pi-like
    • Après plusieurs années en cluster, je confirme les points forts de la XU4 : le débit USB 3.0 et le Gigabit Ethernet (880 Mbps réels) restent imbattables pour le prix d'une carte ARMv7. La compatibilité avec les images Armbian 6.6 est excellente. Par contre, attention au piège thermique : sans le ve… — expert-pi-like
    • Salut, petite question pour ceux qui l'utilisent en NAS. Tu mentionnes la topologie USB partagée. J'ai deux SSD sur les ports USB 3.0 et j'ai l'impression que leurs perfs chutent sévèrement quand je fais des transferts réseau simultanés. Est-ce que c'est lié au hub GL352x intégré ou au fait que le … — maker-artisan
    • C'est exactement le problème documenté par mdel et tkaiser. Le GbE monopolise un hôte USB 3.0, et les deux ports externes partagent l'autre hôte via le hub. Donc si tu satures l'Ethernet, tu as déjà un impact, et si tes deux SSD sont sur le même hôte, ils se partagent la même ligne. Pour du NAS sér… — linux-tinker

Retours et projets de la communauté

  • Mikronauts ODROID-XU4 review / cluster-node evaluation

    Mikronauts ODROID-XU4 review / cluster-node evaluation — William Henning (the Raspberry (unverified au 2026-10-13) — interne hébergé sur site interne, statut vivant vérifié le 2026-10-13. Projet documenté dans la fiche odroid-xu4 (SBC) ; rôle : approfondir la…

Contenu indisponible pour le moment.

  • Thermal throttling / chaleur : le cluster A15 à 2,0 GHz a besoin du refroidissement actif ; "performance is nice, too hot however" (commentaire d'utilisateur, CNX 2017-02-23). Les tests Hardkernel sur le XU4Q : sans ventilateur à 2,0 GHz coûte 16 % sur sysbench (420 s contre 362 s), 6 % à 1,8 GHz, et zéro throttling exige de plafonner à 1,2 GHz ; compilation du noyau en 25 min (XU4 + ventilateur) contre 30 min (XU4Q) (CNX, 2017-04-27).
  • Bruit du ventilateur : "a frequent complaint about the board… it requires a fan to operate at full speed, and makes noise" — la raison affichée de l'existence du XU4Q (même article CNX du 2017-04-27).
  • UART console 1,8 V, pas de protection contre les surtensions sur les IO : au moins un cas documenté de carte rendue inutilisable par un adaptateur USB-UART 5 V ("There is not overvoltage protection on the IO pins, only on the power plug… oDroid support said that the board is fried", utilisateurs Mihai/memeka, commentaires CNX 2017-02-23).
  • Limites de la topologie USB3 partagée : le GbE occupe un hôte USB 3.0 ; les deux ports USB 3.0 partagent l'autre hôte via le hub GL352x embarqué, donc deux SSD partagent la bande passante, et des hubs en cascade peuvent casser UAS (analyse mdel/tkaiser, même fil de commentaires). Planifiez les E/S du NAS en conséquence.
  • Bugs de la pile graphique Mali propriétaire (époque 3.10/4.4) : Ubuntu livré en sortie d'usine embarquait un GPU instable surcadencé, pas de Chromium/VLC accéléré matériel par défaut, et un bug du pilote MALI provoquant des écrans noirs à la sortie des applications plein écran (utilisateur Peter Bauer, commentaires CNX 2015-07-14). Le pilote X11 EXA était aussi gourmand en CPU ("uses an entire big core for surface presentation", blu, commentaires CNX 2017-02-23).
  • Division du périphérique OpenCL : le Mali-T628 MP6 s'énumère comme deux périphériques OpenCL (4 cœurs + 2 cœurs), ce que le code de calcul naïf doit gérer (blu, commentaires CNX 2017-02-23 ; vidage clinfo dans l'article OpenCL du 2018-05-13).
  • Piège du noyau propriétaire hérité : les premières images tournaient sur un noyau propriétaire 3.10 avec un big.LITTLE non mainline ; Hardkernel et la communauté ont tout migré vers 4.9 LTS (mises à jour promises jusqu'à début 2019) et le wiki documente la migration (CNX 2017-02-23 ; index ODROID Wiki).
  • Plafond 32 bits + 2 Go : ARMv7-A uniquement et 2 Go de RAM — les conteneurs préconstruits modernes réservés à arm64 et les charges utiles > 2 Go sont hors sujet (déduction de la chemin de plateforme armv7 d'ALARM et des tableaux de specs CNX).
  • Allumer une LED via le GPIO debutant Schéma : IMG-odroid-xu4-debutant-1-odroidxu4-led-gpio.svg — L'ODROID-XU4 avec son header 30 broches, une LED et sa résistance 330 Ω branchées sur une broche GPIO, alimentation 5 V/4 A
  • Bouton poussoir et lecture d'état debutant Schéma : IMG-odroid-xu4-debutant-2-odroidxu4-bouton-console.svg — Bouton poussoir relié à une broche GPIO et à la masse sur l'ODROID-XU4, sortie console série ttySAC2 indiquée
  • Premier script Python : santé de la carte debutant Schéma : IMG-odroid-xu4-debutant-3-odroidxu4-premier-script-python.svg — Écran de terminal affichant un script Python listant les 8 cœurs big.LITTLE de l'Exynos5422 et les températures de l'ODROID-XU4
  • PWM : faire respirer la LED bleue intermediaire Schéma : IMG-odroid-xu4-intermediaire-1-odroidxu4-pwm-led.svg — Signal PWM en dents de scie sortant du contrôleur PWM de l'ODROID-XU4 (canal 2) vers la LED bleue heartbeat, canal 0 relié au ventilateur
  • Lire un capteur I2C (température) intermediaire Schéma : IMG-odroid-xu4-intermediaire-2-odroidxu4-capteur-i2c.svg — Capteur de température I2C relié au header 12 broches (bus I2C) de l'ODROID-XU4 avec résistances de pull-up SDA/SCL et alimentation 3,3 V
  • Ethernet Gigabit et accès SSH intermediaire Schéma : IMG-odroid-xu4-intermediaire-3-odroidxu4-ethernet-ssh.svg — ODROID-XU4 relié par câble Ethernet à un switch, port GbE branché sur un contrôleur USB 3.0 interne, session SSH depuis un ordinateur
  • Boot eMMC/microSD et récupération avance Schéma : IMG-odroid-xu4-avance-1-odroidxu4-boot-emmc-sd.svg — ODROID-XU4 avec son emplacement module eMMC (HS400) et son port microSD, flèches de copie dd d'une carte SD vers le module eMMC, U-Boot mainline
  • Surveillance thermique big.LITTLE et ventilateur avance Schéma : IMG-odroid-xu4-avance-2-odroidxu4-thermique-biglittle.svg — Carte thermique de l'ODROID-XU4 : capteurs cpu0 à cpu3 et gpu, paliers ventilateur 50/60/70 °C, throttling à 70 et 85 °C, critique 120 °C
  • Serveur multimédia HDMI et GPU Mali avance Schéma : IMG-odroid-xu4-avance-3-odroidxu4-serveur-multimedia.svg — ODROID-XU4 en média-center : sortie HDMI 1.4a 1080p (vidéo + audio) vers un téléviseur, GPU Mali-T628 MP6, stockage USB 3.0

Bibliothèque de code — exemples écrits pour cette carte

  • clignotante.py Python

    Le script de mise en jambe sur SBC : une LED branchée sur le connecteur GPIO clignote à 1 Hz. python3-gpiod pilote directement la puce GPIO via le noyau, sans bibliothèque propriétaire.

  • bouton-gpio.py Python

    Un bouton sur le connecteur GPIO déclenche une action à l'appui et au relâchement. Version générique par scrutation de la ligne gpiod avec anti-rebond logiciel de 30 ms.

  • capteur-i2c.sh Bash

    Le réflexe Linux pour tout capteur I2C : balayer le bus avec i2cdetect, vérifier la présence de la puce puis lire quelques registres avec i2cget. Sortie directe dans le terminal, sans écrire une lign…

  • surveillance-temperature.sh Bash

    Sans aucune dépendance, ce script lit le capteur thermique exposé par le noyau Linux, journalise température et fréquence CPU en CSV et affiche une alerte au-delà d'un seuil. Parfait pour dimensionne…

  • capteur-dht11.py Python

    Le pilote Adafruit CircuitPython fonctionne sur Linux standard : il bit-bang le protocole 1 fil du DHT via libgpiod. Le script affiche température et humidité toutes les 2 s, en encaissant les trames…

  • servo-pwm-sysfs.sh Bash

    L'interface PWM du noyau Linux (sysfs) est identique sur toutes les cartes : période 20 ms, impulsion 0,5-2,5 ms. Ce script bash fait balayer un servo sur 3 cycles puis coupe l'alimentation pour évit…

  • serveur-web-capteur.py Python

    Sans aucune dépendance externe, la carte devient un serveur web : une page HTML affiche température du SoC et uptime, un endpoint JSON les expose aux tableaux de bord. Le réflexe réseau pour monitore…

  • reseau-ethernet.sh Bash

    En installation fixe, une IP statique évite de chercher la carte dans le bail DHCP. Le script crée (ou corrige) un profil NetworkManager manuel sur le port Ethernet, puis vérifie la passerelle au pin…

  • journal-cron.sh Bash

    Le binôme cron + script court est l'automate universel de Linux : chaque minute, charge CPU et température sont ajoutées à un CSV avec rotation intégrée. Zéro dépendance, zéro démon, redémarre tout s…

  • veilleur-systemd.py Python

    Une LED en battement + un contrôle de services toutes les secondes : le script devient un démon systemd avec Restart=always, démarré au boot. Le patron de robustesse pour une carte embarquée sans écr…

Exemples et dépôts trouvés en ligne