J'en retiendrais aussi les provisions patch/callback périodique qui ont été bien utiles pour la reproduction et le patch sans ajouter le risque de flinguer la ROM... a noter que les compilateurs peuvent proposer des possibilités de cet ordre (par exemple gcc et son -finstrument-functions permettant d'appeler une fonction d'instru, par défaut un simple retour à l'appelant, à chaque appel de fonction de son code ; impact perf mais en général dans ce contexte c'est pas forcément le principal souci).
Le truc qui fait bien tilter qd même: L'EDAC qui n'a eu qu'une revue de code (qui a dit que ça ne servait bien trop souvent qu'à se chamailler sur la forme sans trouver les pb de fond?) pour test par le fournisseur! Dans ce contexte, aie-aie-aie, mais je reconnais bien là les pratiques toujours en cours sur la gestion des soft "3rd party". Aie confiance, crois en moi ((c) Le Livre de la Jungle!)...
Les mecs n'ont pas trop cherché quand même car il y a forcément un moyen de tester cela (pour les propres besoins du fondeur), même si ici le processeur ne semblait pas implémenter une véritable injection d'erreur comme c'est le cas sur tout ce que j'ai pu voir (à base PPC/x86/ARM) comme contrôleur DDRx.
Surtout que 5000 pages, en fait, c'est pas grand chose de nos jours: Les premiers SoC PowerPC sur lesquels j'ai travaillé à la fin des années 90 (famille MPC860) devaient en être à peu près à ce chiffre pour la totalité du contenu des différents contrôleurs intégrés hors jeu d'instruction. Les derniers (famille QorIQ), on devait en avoir 1 de ce volume par IP conséquente intégrée (contrôleurs, différents accélérateurs, système de trace/debug intégré...) et peut-être 5 ou 6 en tout! Là clairement, le boulot de généraliste type support/validation devenait assez difficile sans un bon carnet d'adresse en interne et chez les FAE du fondeur.
Maintenant, les pb apparus après tout changement touchant au build (version, options), j'ai également qq souvenirs... Jusqu'à même tomber sur un errata processeur alors non documenté, via un changement dans l'allocation des registres généraux, qui faisait au gré des build parfois tomber dans une instruction qui fournissait un résultat dans le registre d'à côté de celui de l'opcode (correct) généré.
# Merci pour ce partage!
Posté par lym . En réponse à la dépêche « It works on my satellite » ou l'histoire d'un bug dans l'espace. Évalué à 4. Dernière modification le 12 janvier 2026 à 11:06.
J'en retiendrais aussi les provisions patch/callback périodique qui ont été bien utiles pour la reproduction et le patch sans ajouter le risque de flinguer la ROM... a noter que les compilateurs peuvent proposer des possibilités de cet ordre (par exemple gcc et son -finstrument-functions permettant d'appeler une fonction d'instru, par défaut un simple retour à l'appelant, à chaque appel de fonction de son code ; impact perf mais en général dans ce contexte c'est pas forcément le principal souci).
Le truc qui fait bien tilter qd même: L'EDAC qui n'a eu qu'une revue de code (qui a dit que ça ne servait bien trop souvent qu'à se chamailler sur la forme sans trouver les pb de fond?) pour test par le fournisseur! Dans ce contexte, aie-aie-aie, mais je reconnais bien là les pratiques toujours en cours sur la gestion des soft "3rd party". Aie confiance, crois en moi ((c) Le Livre de la Jungle!)...
Les mecs n'ont pas trop cherché quand même car il y a forcément un moyen de tester cela (pour les propres besoins du fondeur), même si ici le processeur ne semblait pas implémenter une véritable injection d'erreur comme c'est le cas sur tout ce que j'ai pu voir (à base PPC/x86/ARM) comme contrôleur DDRx.
Surtout que 5000 pages, en fait, c'est pas grand chose de nos jours: Les premiers SoC PowerPC sur lesquels j'ai travaillé à la fin des années 90 (famille MPC860) devaient en être à peu près à ce chiffre pour la totalité du contenu des différents contrôleurs intégrés hors jeu d'instruction. Les derniers (famille QorIQ), on devait en avoir 1 de ce volume par IP conséquente intégrée (contrôleurs, différents accélérateurs, système de trace/debug intégré...) et peut-être 5 ou 6 en tout! Là clairement, le boulot de généraliste type support/validation devenait assez difficile sans un bon carnet d'adresse en interne et chez les FAE du fondeur.
Maintenant, les pb apparus après tout changement touchant au build (version, options), j'ai également qq souvenirs... Jusqu'à même tomber sur un errata processeur alors non documenté, via un changement dans l'allocation des registres généraux, qui faisait au gré des build parfois tomber dans une instruction qui fournissait un résultat dans le registre d'à côté de celui de l'opcode (correct) généré.