Nous avons du matériel personnalisé exécutant 3,2 Angstrom sur un processeur SAM9G45. Tout fonctionne bien. Récemment, nous avons conçu un matériel similaire qui utilise le processeur SAM9G25. Nous avons constaté que le noyau 2.6 fonctionnait bien sur le SAM9G25, mais nous devions porter le noyau 3.2 sur la plate-forme pour tirer parti de certains pilotes sans fil. Nous avons terminé le portage, mais nous venons de découvrir que l'horloge n'est pas fiable. Il fonctionne bien pendant environ 20 minutes - puis l'heure (rapportée par "date") avancera de quelques heures ou jours. Le noyau 2.6 fonctionne toujours bien, donc nous pensons que c'est quelque chose que nous n'avons pas porté correctement. Nous avons tout regardé, mais pas de chance jusqu'à présent. Je ne sais pas où chercher ensuite.
Réponse finale :Atmel fournit un correctif pour le noyau 2.6, au fichier tcb_clksrc.c. Nous avons manqué cela dans notre port vers le noyau 3.2. Merci pour la perspicacité !
Réponse acceptée :
Essayez de démarrer le système avec l'option du noyau clocksource=jiffies ou nohpet .
J'ai un cas ouvert à propos de SLES11 SP2 (utilisant le noyau 3.0) où j'observe des décalages temporels sur les machines virtuelles.
Le clocksource=jiffies aggravé la situation dans mon cas, mais dans le vôtre, cela pourrait aider.
Actuellement, le support se concentre sur le minuteur d'événements de haute précision (mais je doute que votre système embarqué dispose d'un tel appareil).