Project

General

Profile

Actions

Bug #560

closed

activer la vérification du cache du Leon3FT

Added by Veronique bouzid over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
SRS
Target version:
-
Start date:
04/11/2015
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Lors de la vérification de l'activation du cache Alexis a posé la question suivante à Paul:

"J'ai trouvée ça dans la doc(grip p822 70.11.4 Cache control register) pour le cache: 20:19 FT scheme (FT) - “00” = no FT, “01” = 4-bit checking implemented. Tu l'actives?"

La réponse de Paul
Ma réponse était non. Il faudra que je le fasse pour une utilisation dans le cadre FT.

Il faut donc implemeter cette fonctionalité et mettre à jour la SRS en conséquence.
Il reste à déterminer comment valider la mise en place de cette fonctionalité (Alexis et Véronique!!)


Related issues

Related to Task #636: bad management of HK_LFR_AHB_CORRECTABLE ClosedVeronique bouzid26/02/2016

Actions
Actions #1

Updated by bruno katra over 8 years ago

  • Category set to SRS
Actions #2

Updated by paul leroy about 8 years ago

Plusieurs choses à faire sur la carte EQM:
Lancer le soft en développement (>= 3.0.0.14) et vérifier que le Leon3FT est bien détecté (cf messages de boot ou alors lecture des registres plug&play 0xfffff000). 0x01:0x003 pour Leon3, 0x01:0x053 pour Leon3FT.
Ensuite, vérifier les stratégies de protection des register files Integer Unit et Floating Point Unit (registre ASR16, adresse 0x90400040)
Vérifier si les protections sont activées par défaut (cf page du wiki Leon3FT_fault_tolerance)
Vérifier la valeur par défaut du champ FT du registre CCR (ASI 2, offset 0).

Actions #3

Updated by paul leroy about 8 years ago

  • Assignee changed from paul leroy to bruno katra

L'aspect FT est activé par défaut. En tout cas, c'est ce que j'ai constaté sur l'EQM. Se référer à Leon3FT_fault_tolerance.

L'activation du cache était déjà faite sur l'EM, c'est la même chose pour le FT.

J'ai ajouté au logiciel des possibilités de remonter les statistiques d'erreurs EDAC liées au cache et aux register files (integer unit et floating point unit). Il semblerait qu'il y ait des moyen de test pour les register files (se référer à Leon3FT_fault_tolerance).

Actions #4

Updated by Veronique bouzid about 8 years ago

Précisions demandées à Paul
1- Tu as ecrit
J'ai ajouté au logiciel des possibilités de remonter les statistiques d'erreurs EDAC liées au cache et aux register files (integer unit et floating point unit). Il semblerait qu'il y ait des moyen de test pour les register files (se référer à Leon3FT_fault_tolerance <https://hephaistos.lpp.polytechnique.fr/redmine/projects/lfr-fsw/wiki/Leon3FT_fault_tolerance&gt;).

Ok, tu as ajouté la possibilité mais est ce que tu les remontes dans les HK.

Les champs décrits dans la SRS (en partie le SSS-
SEU counters (counter of the correctable errors and a counter of the not correctable
errors detected by the EDAC)

J ai donc regardé dans les hk et j ai trouvé
les erreurs EDAC semblent correspondre à AHB (IDB du DPU c est ecrit dans ce doc)
--> LE_CNT erreur si memory corruption detected
--> ME_CNT
il faut egalement renseigner LAST_FAIL_ADDR

Hors il me semble que tu as dit que tu ne renseignais pas ces champs.

--> peux tu m'éclairer

La réponse de Paul
Deux fonctions permettent de relever les compteurs et de les remettres à zéros:

void CCR_getInstructionAndDataErrorCounters( unsigned int* instructionErrorCounter, unsigned int* dataErrorCounter )
void ASR16_get_FPRF_IURF_ErrorCounters( unsigned int* fprfErrorCounter, unsigned int* iurfErrorCounter)

Les deux fonctions sont appelées par:

void set_hk_lfr_ahb_correctable() {
/** This function builds the error counter hk_lfr_ahb_correctable using the statistics provided * by the Cache Control Register (ASI 2, offset 0) and in the Register Protection Control Register (ASR16) on the * detected errors in the cache, in the integer unit and in the floating point unit. * * @param void * * @return void * * All errors are summed to set the value of the hk_lfr_ahb_correctable counter. *
*/

unsigned int ahb_correctable;
unsigned int instructionErrorCounter;
unsigned int dataErrorCounter;
unsigned int fprfErrorCounter;
unsigned int iurfErrorCounter;
CCR_getInstructionAndDataErrorCounters( &instructionErrorCounter, &dataErrorCounter);
ASR16_get_FPRF_IURF_ErrorCounters( &fprfErrorCounter, &iurfErrorCounter);
ahb_correctable = instructionErrorCounter
+ dataErrorCounter
+ fprfErrorCounter
+ iurfErrorCounter
+ housekeeping_packet.hk_lfr_ahb_correctable;
if (ahb_correctable > 255)
{
housekeeping_packet.hk_lfr_ahb_correctable = 255;
}
else {
housekeeping_packet.hk_lfr_ahb_correctable = ahb_correctable;
}

}

Je ne relève pas l'adresse de la dernière adresse fausse. En fait, le champ hk_lfr_ahb_correctable est le champ qui me paraissait approprié pour remonter les erreurs EDAC (provenant des register files ou du cache) mais je ne remonte aucune erreur liées aux transmissions sur le bus AHB.

Actions #5

Updated by Veronique bouzid about 8 years ago

  • Status changed from New to Closed

Je ferme et ouvre un autre Bug avec les modifications à effectuer.

Actions #6

Updated by Veronique bouzid about 8 years ago

  • Related to Task #636: bad management of HK_LFR_AHB_CORRECTABLE added
Actions

Also available in: Atom PDF