FR2828294A1 - Procede pour generer une image en memoire morte - Google Patents
Procede pour generer une image en memoire morte Download PDFInfo
- Publication number
- FR2828294A1 FR2828294A1 FR0209594A FR0209594A FR2828294A1 FR 2828294 A1 FR2828294 A1 FR 2828294A1 FR 0209594 A FR0209594 A FR 0209594A FR 0209594 A FR0209594 A FR 0209594A FR 2828294 A1 FR2828294 A1 FR 2828294A1
- Authority
- FR
- France
- Prior art keywords
- image
- data
- rom memory
- data image
- rom
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Stored Programmes (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
Abstract
Un système et un procédé génèrent une image (214) en mémoire morte (ROM). Le générateur de l'image en mémoire ROM opère avec un constructeur (202) d'image de données. Le générateur traite un fichier d'entrée (204) pour identifier des images de données pour une construction. L'identificateur d'image (210) génère des objets (206). Un constructeur (202) utilise des objets comme entrée pour construire chaque image de données. Un constructeur (212) construit l'image en mémoire ROM (214) en utilisant chaque construction d'image de données et génère une signature de validation de ladite construction. Une fois que chaque construction d'image de données et la signature de validation associée sont écrites sur l'image en mémoire ROM (214), l'image en mémoire ROM (214) est complétée avec une somme de contrôle de la totalité de l'image en mémoire ROM (214).
Description
réception infrarouge relié au port série d'un ordinateur.
1 2828294
Procédé pour énérer une imae en mémoire morte La présente invention concerne le domaine de générer une image en mémoire morte (ROM). La présente invention concerne le domaine de générer une image en mémoire morte (ROM). L'invention est particulièrement utile pour générer un fichier image pour programmer des mémoires ROM ou autres dispositifs de mémoire tels que des mémoires ROM programmables (PROM), des mémoires ROM programmables effaçables (EPROM) et des mémoires ROM reprogrammables effaçables électriquement (EEPROM) qui
contiennent le microprogramme dans un système.
Un microprogramme est un code qui opère pour un système informatique et qui est rarement changé. Certains microprogrammes opèrent au moment de la mise sous tension jusqu'au moment o un processeur appelle le processus d'amorçage. D'autres microprogrammes contiennent un code d'opération en temps rcel qui fait opérer différents périphériques ou poursuit d'une autre façon un traitement pour le système informatique. Un microprogramme peut par exemple tester la bonne santé d'un système informatique dans lequel il réside. Ce microprogramme réside souvent à l'intérieur d'une mémoire, telle qu'une ou plusieurs mémoires ROM, une mémoire ROM programmable (PROM), une mémoire ROM programmable effaçable (EPROM) et/ou une mémoire ROM
programmable effaçable électriquement (EEPROM).
La mémoire ROM contient des fichiers exécutables et des donnces associces parfois désignés sous le nom d'images. Ces images sont écrites en mémoire ROM ou, sinon, mémorisées sous
forme de processus de " construction ".
Une image en mémoire ROM est un fichier ou autre code exécutable et/ou des données mémorisces en mémoire, telle qu'une
mémoire ROM, une mémoire EPROM ou une mémoire EEPROM.
L'image en mémoire ROM contient une ou plusieurs images de donnces qui sont compilées et lices pour crécr l'image en
2 2828294
mémoire ROM. Les images de données peuvent être une section d'un code exécutable, des données pour emploi par un programme compilé, un signal de sortie d'un programme compilé, une section de donnces ou d'un code qui peut être transférée sur un dispositif programmable, une section d'un code ou de données pour emploi par un système ayant une configuration spécifique, ou un autre code ou d'autres donnces utilisables pour le fonctionnement des systèmes informatiques. Chaque image de données dans la construction a une adresse de début et une dimension initiale en mémoire. Toutefois, au cours de la vie du système informatique, la dimension d'une ou plusieurs
images de données dans l'image en mémoire ROM peut augmenter.
Ceci peut survenir par exemple si le code écrit sur l'image de données augmente ou est autrement modifiée si des bogues sont réparés, si des caractéristiques additionnelles sont ajoutées au
système ou si le microprogramme est modifié autrement.
Dans des systèmes antérieurs, des images en mémoire ROM étaient construites manuellement par fixation d'une série d'adresses pour des images de données à placer dans l'image en mémoire ROM. Du fait que l'image de données peut augmenter de taille, des jeux étaient laissés entre les images de donnces pour prévoir leur expansion. Si la dimension de l'image de donnces augmentait trop fortement de façon qu'elle nécessite de l'espace déj à pris par une autre image de données, alors cette image de données expansée ainsi que d'autres images de données étaient déplacées manuellement pour compenser l' expansion de leur dimension. Ce mouvement manuel d'images de données prenait du
temps et était sujet à erreur.
En outre, dans l'art antérieur, une unique somme de contrôle ou un unique contrôle cyclique par redondance (CRC) existait pour la totalité de l'image en mémoire ROM. Par conséquent toutes les images de données se trouvant dans une mémoire ROM programmée avec l'image en mémoire ROM devaient être vérifices de façon que la somme de contrôle ou le contrôle cyclique par redondance CRC puisse être calculé, même si une ou plusieurs images de donnces ou
3 2828294
une portion de la mémoire ROM n'étaient pas utilisées dans l'exécution du microprogramme. Pour une mémoire ROM importante ceci ajoutait un temps significatif pour amorcer le système. Par conséquent des nouveaux systèmes et de nouveaux procédés sont nécessaires pour réduire les problèmes associés avec la validation des images de données, l'image en mémoire ROM et une mémoire ROM programmoe avec l'image en mémoire ROM, de façon à réduire le temps d'amorçage. En outre de nouveaux systèmes et de nouveaux procédés sont nécessaires pour écrire facilement des images de données sur une image en mémoire ROM et confirmer ensuite les dimensions et les adresses de ces images de données. En outre de nouveaux systèmes et de nouveaux procédés sont nécessaires pour fournir des validations, tels que des sommes de contrôle ou des contrôles cycliques par redondance CRC pour les
images de données sélectionnces et les images en mémoire ROM.
La présente invention concerne un procédé pour générer une image en mémoire ROM comportant au moins une construction d'une image de donnces. Le procédé consiste à traiter un fichier d'entrée pour identifier au moins une image de données pour une construction d'image en mémoire ROM et à générer un fichier
d'objets comportant au moins un objet pour l'image de données.
L'image de données est traitée avec son fichier d'objets associé pour créer la construction d'image de données. Une signature de validation de la construction d'image de données est générce pour la construction d'image de données. La construction d'image de données et la signature de validation de la construction d'image de donnces sont écrites sur l'image en mémoire ROM. Une signature de validation de l'image en mémoire ROM est générée pour l'image en
mémoire ROM.
En outre la présente invention concerne un procédé pour
4 2828294
générer une image en mémoire ROM comprenant au moins une construction d'une image de données. Le procédé consiste à traiter un fichier d'entrée pour générer un fichier d'objets et un fichier d'objets temporaire, le fichier d'objets et le fichier d'objets temporaire représentant chacun des objets pour chaque image de données identifiée dans le fichier d'entrce. Le fichier d'objet est comparé avec le fichier d'objets temporaire et, si ce sont les mêmes, une signature de validation de l'image de données est générée pour chaque image de données. Chaque image de données et chaque signature de validation de l'image de données sont écrites sur l'image en mémoire ROM et ensuite une signature de validation de l'image en mémoire ROM, distincte, est générce pour l'image en
mémoire ROM.
En outre encore, la présente invention concerne un procédé pour générer une image en mémoire ROM en utilisant des entrées provenant d'un fichier d'entrée. Le procédé consiste à identifier une pluralité d'image de données à placer dans l'image en
mémoire ROM sur la base des entrées provenant du fichier d'entrée.
Une signature validant l'image de données est générée pour chaque image de donnces avec son entrce associée Chaque image de données et la signature validant l'image de donnces sont écrites à l'adresse de début de l'image en mémoire ROM. Au moins une adresse de début est allouée dynamiquement. Ensuite une signature validant l'image en mémoire ROM est générce pour l'image en mémoire ROM. Les images de données avec les signatures validant les images de donnces et la signature validant l'image en mémoire ROM sont transmises en mémoire pour mémorisation en
tant qu'image en mémoire ROM.
La figure 1 est un diagramme par blocs illustrant un système générant une image en mémoire ROM conformément à une forme de
réalisation de la présente invention.
La figure 2 est un ordinogramme illustrant la génération d'une image en mémoire ROM conformément à une forme de réalisation
de la présente invention.
2828294
La figure 3 est un ordinogramme illustrant la génération d'une image en mémoire ROM conformément à une autre forme de
réalisation de la présente invention.
La figure 4 est un ordinogramme illustrant un processus de paramétrage d'image de données conformément à une forme de
réalisation de la présente invention.
La figure 5 est un ordinogramme illustrant un processus de conflit d'adressage d'image conformément à une forme de
réalisation de la présente invention.
La figure 6 est un ordinogramme illustrant un processus de conflit d' adressage de début d ' image de données conformément à
une forme de réalisation de la présente invention.
La figure 7 est un ordinogramme illustrant une opération d' écriture d ' image de données conformément à une forme de
réalisation de la présente invention.
La figure 8 est un ordinogramme illustrant un processus de validation en mémoire ROM en accord avec une forme de réalisation
de la présente invention.
Dans une première forme de réalisation, la présente invention propose des systèmes et des procédés pour construire une image en mémoire telle qu'une image en mémoire morte (ROM), dans laquelle se trouvent une ou plusieurs images de donnces, des adresses associées, des dimensions associces de multiplets de données et des résultats de validation. Cette forme de réalisation automatise la création d'une image en mémoire ROM et réduit le temps d'amorçage de l'image en mémoire ROM en réduisant le temps nocessaire pour valider chaque image de données se trouvant
dans l'image en mémoire ROM.
Une image en mémoire ROM est un fichier ou autre code exécutable et/ou des donnces mémorisces en mémoire, telle qu'une
mémoire ROM, une mémoire EPROM ou une mémoire EEPROM.
Une image en mémoire ROM peut être vue sous forme d'un fichier binaire qui est programmé dans un dispositif de mémoire
programmable tel qu'une mémoire permanente ou semi-permanente.
Un système de programmation est un système pour transférer
6 2828294
l'image en mémoire ROM dans une mémoire ROM, une
mémoire EPROM, une mémoire EEPROM et/ou une autre mémoire.
Les images de données sont compilées et liées pour créer l'image en mémoire ROM. Les images de données peuvent être chacune une section d'un code exécutable, des donnces pour emploi par un code exécutable, un programme compilé, une section de données ou de codes qui peut être transférée dans un dispositif programmable tel qu'un code de configuration d'un tableau de portes programmable sur le champ (FPGA). Une section de code ou de données pour emploi par un système ayant une configuration spécifique, ou un autre code ou d'autres données utilisables pour le fonctionnement d'un système informatique. Le terme " ROM " peut inclure ou être remplacé par une mémoire, telle qu'une ou plusieurs mémoires PROM, EPROM et/ou EEPROM Un utilisateur peut changer un fichier de configuration pour aj outer ou supprimer des images de données pour une image en mémoire ROM. Comme telle, l'invention peut 8tre configurée pour ajouter un code à une image en mémoire ROM, pour enlever un code d'une image en mémoire ROM ou pour ne pas ajouter un code à une image en mémoire ROM, sur la base des demandes d'un utilisateur
ou autres demandes identifiées dans un fichier de configuration.
Des adresses de début d'images de données peuvent 8tre désignces à l 'intérieur de l' image en mémoire ROM. Les adresses de début peuvent 8tre fixées, ou bien la dimension d'une image de données peut 8tre calculée et une adresse de début peut 8tre générée
dynamiquement pour cette image de donnces.
Dans la forme de réalisation préférée, l'invention translate automatiquement une image de données dans une image en mémoire ROM, là o elle est nécessaire, et génère automatiquement une nouvelle adresse de début pour l'image de données. Elle peut également écrire automatiquement l'image de données sur l'image en mémoire ROM. Une image de données peut 8tre déplacce ou modifiée au fur et à mesure que l'image de données grandit et par ailleurs l'image de donnces peut recevoir des ajouts, si nécessaire, par conséquent il n'est pas nocessaire d'avoir des jeux entre les
7 2828294
images de données. Ceci se traduit par une économie d'espace en mémoire ROM et assure une meilleure efficacité de mémorisation, de récupération et d'exécution de l'image en mémoire ROM. En outre il n'est pas nécessaire de calculer ou d'exécuter des sommes de contrôle ou autres signatures de validation pour un espace vide. L'invention peut être configurce pour ajouter des multiplets à une extrémité d'une image de données de façon que l'image de donnces corresponde à un multiple pair d'une valeur spécifiée de multiplets. Par exemple un fichier de configuration peut spécifier que des images de donnces doivent se terminer sur une limite à quatre multiplets. Par conséquent un ou plusieurs multiplets seront ajoutés, si nécessaire, à une image de données de façon qu'elle se termine sur une limite à quatre multiplets et qu'elle soit ainsi d'une longueur égale à un multiple pair de quatre multiplets. Ceci procure certains avantages pour exécuter complètement des sommes de contrôle et d'autres algorithmes qui nocessitent une longueur de mot particulière. L'invention peut également créer un fichier d'objets. Le fichier d'objets est généralement une chaîne de texte contenant des données qui peuvent être utilisées au cours de la construction d'une image en mémoire ROM. Le fichier d'objets peut inclure une liste d'objets tels qu'une somme de contrôle, des images de données de la
mémoire ROM et/ou d'autres données.
Dans la forme de réalisation préférée, l' invention utilise des signatures de validation telles que des sommes de contrôle. La signature de validation est par exemple un calcul basé sur des données contenues dans une image, par exemple une somme de contrôle, un contrôle cyclique par redondance (CRC) ou un autre processus de validation. Une signature de validation peut également être calculée sur la base à la fois des données contenues dans l'image et d'une clé d'identification telle que connue dans l'art des documents signés par voie numérique, telle qu'une clé privée pour emploi avec un algorithme de cryptage de clé publique. Dans certaines formes de réalisation, une portion de la signature de validation peut être masquée ou ignorée. Par exemple une signature
8 2828294
de validation calculée peut être de 64 bits. Dans cet exemple, les 32 bits supérieurs de cette signature de 64 bits peuvent être masqués de sorte que ce sont les 32 bits inférieurs qui sont utilisés
pour la validation.
La figure 1 représente une forme de réalisation, prise à titre d'exemple, d'un système générateur d'image en mémoire ROM de la présente invention. Le système générateur d'image 102 de la figure 1 comporte une mémoire morte (ROM) 104, un processeur 106 et un générateur d'image en mémoire ROM 108. Le
système générateur d'image 102 peut inclure un dispositif 110.
La mémoire ROM 104 est par exemple un support numérique en mémoire, un ensemble de puces ou un autre dispositif de mémorisation non volatil. La mémoire ROM 104 peut être une mémoire programmable, effaçable, électriquement effaçable ou un
autre type de mémoire ROM ou d'autres mémoires.
Le processeur 106 est un processeur configuré pour traiter le générateur d'image en mémoire ROM 108. Le processeur 106 peut être configuré pour commander d'autres dispositifs internes ou externes associés au système générateur d'image 102. Par exemple le processeur 106 peut être configuré pour traiter un dispositif
d'entrée/sortie ou un dispositif programmable.
Le générateur d'image en mémoire ROM 108 est configuré pour identifier des images de donnces pour une construction d'image en mémoire ROM. L'image en mémoire ROM est alors
construite sur la base des images de données.
Le dispositif 110 est un dispositif interne ou externe associé au système générateur d'image 102. Le dispositif 110 peut être par exemple un dispositif de lecture ou d'écriture sur support, tel qu'une mémoire ROM sur disque compact (CD), une mémoire volatile, une mémoire non volatile, un dispositif programmable, un
dispositif d'entrée, un dispositif de sortie ou un autre dispositif.
La figure 2 représente une forme de réalisation, prise à titre d'exemple, d'un processus 108a de générateur d'image en mémoire ROM opérant avec un processus 202 de construction d'image de données. Le processus 108a de générateur d'image en
9 2828294
mémoire ROM et le processus 202 de constructeur d'image de données peuvent utiliser un fichier d'entrce 204, des objets 206 pour construire une image et une signature de validation 208 pour
chaque image de données.
Un fichier d'entrée 204 est communiqué à un processus identificateur d'image à l'étape 210 pour identifier des images de données pour une construction. Les objets 206 pour construire l'image sont ajoutés et chaque image de donnces est construite par un processus constructeur de l'image de donnces à l'étape 202. A l'étape 212 une signature de validation 208 pour chaque image de données est ajoutée et une image en mémoire ROM 214 est
construite par un processus constructeur de l'image de données.
Chaque processus comporte un ou plusieurs modules de programme associés configurés pour exécuter le processus. C'est ainsi que le processus 108a générateur d'une image en mémoire ROM, le processus 202 constructeur d'une image de donnces, le processus 210 identificateur d'image et le processus 212 constructeur d'une image en mémoire ROM comportent un constructeur d' image en mémoire ROM associé, un constructeur d ' image de données, un identificateur d' image et un constructeur d'image en mémoire ROM, respectivement. On se rendra compte de ce que plus qu'un seul module de programme peut étre associé à chaque processus. Par exemple le processus 210 identificateur d'image peut avoir un premier identificateur d' image et un second identificateur d'image associés dans lesquels un ou plusieurs des
processus identificateurs d'image sont exécutés.
Une explication des formes de réalisation du fichier d'entrce 204, des objets pour construire l'image 206, et de la signature de validation 208 se trouve immédiatement ci-dessous,
suivie par une description plus extensive du processus 108a
générateur d'une image en mémoire ROM à chacune de ses étapes pour une forme de réalisation. Il existe d'autres formes de réalisation. Le fichier d'entrée 204 peut être un fichier de configuration identifiant des obj ets ou autres signaux d'entrée pour chaque
1 0 2828294
construction. Le fichier d'entrée contient l'information nocessaire pour construire une image en mémoire ROM 214 pour différentes configurations. Par conséquent l'information qui se trouve dans un fichier d'entrce peut varier pour une construction particulière 212 d'une image en mémoire ROM. Dans une forme de réalisation, le fichier d'entrce contient une adresse de début d'une image en mémoire ROM, une dimension de l'image en mémoire ROM, la dimension d'une somme de contrôle, un contr81e cyclique par redondance CRC ou une autre signature de validation, un masque pour la signature de validation, un identificateur de programme pour la signature de validation et/ou un motif de remplissage pour des
positions non utilisées dans l'image en mémoire ROM.
L'identificateur de programme pour signature de validation peut être un nom de fichier d'un programme utilisé pour calculer la signature de validation. La signature de validation peut être une somme de contrôle, un contrôle cyclique par redondance CRC, un résultat d'un algorithme de cryptage à base d'une clé ou une autre
signature de validation.
Un motif de remplissage peut identifier un procédé pour lequel une image de données peut être alignée. L'image de donnces peut avoir une valeur d'alignement, telle qu'un pavé d'alignement spécifiant le nombre de multiplets qu'il faut ajouter à une image de donnces pour qu'elle soit alignée, comme demandé, avec le motif de remplissage. En variante, la valeur d'alignement peut spécifier la valeur, exprimée en multiplets, à laquelle l'image de données doit se terminer. Par exemple le motif de remplissage peut spécifier qu'une image de donnces doit contenir un multiple pair de la longueur, ou d'une portion définie de la longueur, du motif de remplissage. En variante, une valeur d'alignement fixée peut être définie pour chaque image de données. Par exemple la valeur d'alignement peut alors être définie à deux multiplets et ce sont alors zéro ou un multiplet qu'il faudrait ajouter à l'image de donnces pour faire en sorte qu'elle occupe un nombre pair de
deux multiplets.
Le motif de remplissage et la valeur d'alignement facilitent le calcul en temps récl d'une signature de validation de sorte que l' algoritUme d' exécution puisse faire des hypothèses sur la dimension d'une image de données. Par exemple un algorithme de somme de contrôle peut supposer que la dimension d'une image de
donnces est un multiple de mots de 64 bits.
En outre le fichier d'entrée 204 peut contenir une information validant chaque image de données à placer dans l'image en mémoire ROM. L' information pour chaque image de données peut contenir un nom de fichier, une adresse de début, à l'intérieur de l'image en mémoire ROM, à laquelle l'image de donnces peut être écrite, une adresse ou autre position à l'intérieur de l'image en mémoire ROM à laquelle une signature de validation peut être mémorisée, une position dans l'image en mémoire ROM à laquelle une adresse de début de l'image de donnces est mémorisée, la dimension et/ou le masque de la signature de validation et/ou une
valeur d'alignement pour une image de données.
L'adresse de début à l'intérieur de l'image en mémoire ROM peut être fixe ou dynamiquement identifiée. Si l'adresse de début est dynamiquement identifiée, un identificateur dynamique présentant une valeur particulière telle que " -1 " peut être spécifié dans le fichier d'entrée. Si une signature de validation n'est pas demandée, alors un identificateur de signature de validation nulle peut être utilisé, tel que " -1 ". Si l'adresse de début d'une image de données doit être ignorée, alors un identificateur d'adresse de début nulle, tel que " -2 " peut être utilisé. En ce qui concerne la dimension et/ou le masque de la somme de contrôle, après que la somme de contrôle ou autre signature de validation ait été calculée pour l'image de données, un masque peut faire l'objet d'une opération OU exclusif ou d'une opération ET avec la somme de contrôle. L'homme de l'art se rendra compte de ce que d'autres identificateurs, tels que des identificateurs dynamiques, des identificateurs de signature et des identificateurs de l'adresse de
début peuvent être utilisés sans s'écarter de l'objet de l'invention.
12 2828294
Des objets 206 pour construire une image de donnces peuvent provenir d'un fichier d'entrée ou d'une autre source. Un objet 206 pour construire une image peut comporter une ou plusieurs adresses physiques de début pour l'image en mémoire ROM, la dimension de l' image en mémoire ROM, une valeur, exprimée en multiplets, des positions non utilisces de l'image en mémoire ROM et/ou l'adresse de la signature de validation globale de l'image en mémoire ROM
telle que la somme de contrôle de l'image en mémoire ROM.
D'autres objets peuvent inclure l'adresse à laquelle l'adresse de début de l'image en mémoire ROM est mémorisce, l'adresse à laquelle la dimension d'une image de données est mémorisée, une adresse à laquelle une signature de validation pour une image de données est mémorisée, une dimension d'une signature de validation, un masque pour une signature de validation et/ou une dimension de mot de données lu par un processeur lors de la validation d'une image de données en fonction d'une signature de validation. Les objets 206 de construction de l'image sont générés
dans un fichier d'objets ou dans un fichier d'objets temporaire.
La signature de validation 208 est utilisée pour valider chaque image de donnces. L'identificateur de signature de validation peut identifier un algorithme utilisé pour générer la signature de validation. Une somme de contrôle ou un algorithme de contrôle cyclique par redondance CRC peut être utilisé pour générer la
signature de validation dans des formes de réalisation particulières.
En se référant à nouveau à la figure 2, on va maintenant décrire de façon plus expansive, pour une forme de réalisation préférée, les étapes du processus générateur de l'image en mémoire ROM. A l'étape 210, l'identificateur d'image traite un fichier d'entrée pour identifier des images de données pour une construction d'image en mémoire ROM. Le fichier d'entrée 204 identifie les objets 206 qui spécifient les images de données à inclure dans l'image en
mémoire ROM.
Pour chaque image de données le fichier d'entrée 204 spécifie si, oui ou non, le processus 108A générateur de l'image en mémoire ROM doit identifier dynamiquement l'adresse de début. Si
13 2828294
l'adresse de début de l'image de données est fixe, le fichier d'entrée identifie l'adresse de début. En outre, le fichier d'entrée peut identifier des paramètres optionnels spécifiés ci-dessus. Lorsque le fichier d'entrce est traité, le fichier d'objets contenant les objets 206 pour chaque image de données à mettre dans l'image en
mémoire ROM sera créé.
Dans l'étape 202 de construction de l'image de données, le constructeur de l'image de données construit chaque image de donnces en utilisant les objets 206 identifiés dans le fichier d'objets pour cette image de donnces. L'étape 202 de construction de l'image de données comporte le fait de compiler et de lier chaque
image de donnces en utilisant les objets identifiés.
A l'étape 212 l'image en mémoire ROM se construit en plaçant chaque image de données présentant une position de début assignée à cette position dans l'image en mémoire ROM. A chaque image de données à laquelle n'a pas été assignée une position de début, est assignée une position libre dans l'image en mémoire ROM. Si une adresse de début, une dimension, ou une signature de validation est nécessaire pour l'une quelcouque des images de données, elles sont également placées dans l'image en mémoire ROM. Par conséquent chaque image de donnces et l'image en mémoire ROM peuvent avoir des processus de validation distincts qui peuvent être définis par une entrce, par l'utilisateur, de programmes de signature de
validation qui vont calculer les signatures de validation 208.
Aux étapes 210 et 212, l'identificateur d'image et le constructeur de l ' image en mémoire ROM valident l ' image en mémoire ROM 214 en testant qu'il n'y ait pas de recouvrement entre les images de données. Par conséquent, après construction de toutes les images de données et de l'image en mémoire ROM 214, le processus 108a générateur de l'image en mémoire ROM se répète de préférence pour confirmer que l'image en mémoire ROM 214 a été construite de façon précise. Lors de la seconde exécution, un fichier d'objets temporaire est créé et comparé au fichier d'objets quiavait été créé dans la première exécution. Si le fichier d'objets et le fichier d'objets temporaire sont les mêmes, l'image en
14 2828294
mémoire ROM a été construite de façon précise comme cela sera décrit plus complètement ci-dessous. La seconde exécution valide également que les obj ets pour chaque image de données sont compatibles et elle calcule les signatures de validation pour chaque image de donnces si cela est spécifié, ou pour la totalité de l'image
en mémoire ROM 214.
Dans une première forme de réalisation, l'image en mémoire ROM 214 est validée en utilisant une signature de validation 208 générée à l'étape 212. Toutefois du fait qu'un espace blanc ne fait pas partie de l'image en mémoire ROM 214, il n'est
pas nocessaire de valider la totalité de l'image en mémoire ROM.
Bien plutôt, seul ce qui est utilisé en mémoire ROM est validé, ce qui permet à l'image en mémoire ROM de croître et sauvegarde
l' exécution en temps d' exécution.
On se rendra compte de ce que plus d'un module de programme peut étre associé à chaque processus. Par exemple à l'étape 210 un premier identificateur d'images peut générer le fichier d'objets et un second identificateur d'images peut générer le fichier d'obj ets temporaire. Les processus et les modules peuvent être distribués ou
combinés selon différentes formes de réalisation.
La figure 3 représente une forme de réalisati on, pri se à titre d'exemple, d'un autre processus 108b générateur d'une image en mémoire ROM. Dans cette forme de réalisation, le processus 108b générateur de l'image en mémoire ROM est appelé deux fois. Le premier appel s'achève avant la construction de l'image en mémoire ROM et il est utilisé pour créer un fichier d'objets pour construire l'image en mémoire ROM. Le second appel s'achève après la construction de l'image en mémoire ROM et il est utilisé pour créer un fichier d'objets temporaire. Le fichier d'objets est comparé au fichier d'objets temporaire pour confirmer la précision de l'image en mémoire ROM et garantir que les images de donnces qui sont dans l'image en mémoire ROM sont compatibles avec ce
qui est attendu.
Par exemple, si l'image en mémoire ROM est bâtie, et si un fichier de configuration pour l'image en mémoire ROM est modifié
1 5 2828294
alors que l' image en mémoire ROM est en cours de génération, alors l'image en mémoire ROM ne pourrait pas identifier avec précision des images de donnces pour l'image en mémoire ROM. Dans ce cas, le fichier d'objets sera différent du fichier d'objets temporaire du fait que le fichier d'objets sera créé avant que le fichier de configuration soit modifié tandis que le fichier d'objets temporaire sera créé après que le fichier de configuration soit modifié. Si le fichier d'objets n'est pas le même que le fichier d'objets temporaire, le processus peut être configuré pour sortir et redémarrer. En variante, le processus peut être configuré pour
redémarrer sans sortir.
Le processus 108b générateur de l'image en mémoire ROM de
la figure 3 peut être modifié de façon qu'un seul appel soit effectué.
Toutefois le processus à deux appels garantit une image en
mémoire ROM précise.
Lorsqu'un fichier d'objets ou un fichier d'objets temporaire est créé, les donnces provenant du fichier d'entrée sont lues et écrites dans le fichier d'objets ou dans le fichier d'objets temporaire. Les données qui sont dans le fichier d'objets sont utilisées pour construire l'image en mémoire ROM. Par exemple, si la construction de l'image en mémoire ROM est basce sur un fichier source en code C, le fichier d'objets comporte un fichier d'en-tête contenant des #définitions utilisées pour lister les paramètres. Le processeur 108b générateur de l'image en mémoire ROM vérifie l' existence des #définitions pour aj outer ou enlever le code pendant le temps d'exécution lorsque l'image en mémoire ROM est construite. Le processus 108b générateur de l'image en mémoire ROM peut également utiliser les #définitions pour déterminer par exemple les positions des images de données, les sommes de contrôle et les dimensions des images de donnces qui
sont dans l'image en mémoire ROM.
En se reportant au processus représenté sur la figure 3, le processus 108b générateur de l'image en mémoire ROM traite un fichier d'entrce à l'étape 302. Le fichier d'entrée est lu pour obtenir
une information d'entrée pour construire l'image en mémoire ROM.
16 2828294
L'information fournie par le fichier d' entrce peut inclure l' adresse de début de l'image en mémoire ROM, la dimension de l'image en mémoire ROM, un motif de remplissage et une valeur d'alignement, une dimension d'une somme de contrôle pour l'image en mémoire ROM et un identificateur de la somme de contrôle. Un masque pour une somme de contrôle peut également étre inclus. Le fichier d'entrée est lu pour chaque image de données pour déterminer le nom du fichier de l'image de données, l'adresse de début de l'image de donnces à l'intérieur de l'image en mémoire ROM, la position dans l'image en mémoire ROM pour mémoriser la somme de contrôle pour cette image de données, la position dans l'image en mémoire ROM pour mémoriser l'adresse de l'image de données, la dimension de la somme de contrôle pour l'image de données et la valeur d'alignement pour
l'image de données.
L'étape 304 détermine si un fichier d'objets devrait étre créé pour la construction de l'image en mémoire ROM. Si c'est le premier appel du processus 108b générateur de l 'image en mémoire ROM de sorte que l'image en mémoire ROM n'a pas
encore été construite, un fichier d'objets 306 est crcé à l'étape 308.
Le processus passe à l'étape 310 et l'image en mémoire ROM est construite. Si c'est le second appel du processus 108b générateur de l'image en mémoire ROM, c'est-à-dire si l'image en mémoire ROM a déjà été construite, alors un fichier d'objets temporaire 312 est
créé à l'étape 314.
Une fois que le fichier d'objets 306 et le fichier d'objets temporaire 312 sont créés, la construction de l'image en mémoire ROM débute par une comparaison du fichier d' obj ets 3 06 et du fichier d'objets temporaire 312 à l'étape 316. Si le fichier d'objets 306 et le fichier d'objets temporaire 312 correspondent, alors la construction originale de l'image en mémoire ROM et la détermination actuelle du fichier d'objets sont les mémes. Par conséquent aucune image de données n'a été ajoutée, modifiée ou effacée et aucun autre changement n'a été effectué, tel qu'un fichier de configuration. Si le fichier d'objets et le fichier d'objets
17 2828294
temporaire ne correspondent pas, alors une image de données a été ajoutée, modifiée ou supprimoe ou une autre modification est
survenue après la construction.
Si le fichier d'objets et le fichier d'objets temporaire ne correspondent pas à l'étape 316, le processus sort avec une erreur à l'étape 318. En option un message d'erreur peut être généré pour un dispositif de sortie. Si le fichier d'objets et le fichier d'objets temporaire correspondent à l'étape 316, chaque image de données est traitée à l'étape 320 pour déterminer la dimension de l'image de données et valider l'image de données, par exemple avec une somme de contrôle ou un contrôle cyclique par redondance CRC. Une valeur d'alignement peut être ajoutée (étape non représentée) à l'image de donnces de façon qu'un algorithme de validation puisse estimer les limites de dimension sur l'image de données lors du calcul de la signature de validation. La figure 4 représente une forme de réalisation, prise à titre d'exemple, d'un processus de
paramétrage d'image de donnces.
Des conflits d'adresses sont vérifiés à l'étape 322 pour déterminer si la position et la dimension de l'adresse de l'image de donnces sont en conflit avec d'autres images de données. Les paramètres de l'image de donnces sont comparés à toutes les autres images de données et à leurs paramètres associés pour déterminer si une position dans l'image en mémoire ROM est occupée par plus qu'une image de données ou par les paramètres associés à cette image de donnces. Si une position dans l'image en mémoire ROM est en fait utilisce par plus d'une image de données à un instant, une erreur existe. Par conséquent si un conflit d'adresses existe à l'étape 322, le processus sort avec une erreur à l'étape 324. La figure 5 décrit une forme de réalisation, prise à titre d'exemple,
d'un processus de vérification d'un conflit d'adresses.
Si aucun conflit d'adresses n'existe à l'étape 322, les images de donnces qui n'ont pas une adresse de début définie sont affectées d'une adresse de début à l'étape 326. Ces adresses sont affectées par voie itérative à travers chaque combinaison de positions non utilisées dans l'image en mémoire ROM et en affectant une position
1 8 2828294
jusqu'à ce que soit une correspondance soit détectée soit aucune combinaison ne soit trouvée. La figure 6 représente une forme de réalisation, prise à titre d'exemple, d'un processus d'affectation d'adresse. Si aucune combinaison n'est trouvée à l'étape 326, les adresses sont évaluées au point de vue risque de conflit à l'étape 328. Si un conflit existe, le processus sort avec une erreur à l'étape 330. Si une combinaison est trouvée à l'étape 326, alors aucun conflit d'adresse n'est trouvé à l'étape 328 et les images de données sont écrites sur
l'image en mémoire ROM à l'étape 332.
Lorsque les images de donnces sont écrites sur l'image en mémoire ROM, un fichier de sortie de l'image de donnces est ouvert et le premier multiplet du fichier de sortie est à la même position que le premier multiplet de l'image en mémoire ROM. Le processus 1S fait une itération en boucle à travers chaque multiplet de l'image en mémoire ROM et les données approprices pour chaque image de données sont écrites sur l'image en mémoire ROM. Ces données pour image de données peuvent inclure l'image de données elle méme, la dimension de l'image de données, la position de l'image
de données et/ou la somme de contrôle de l'image de donnces.
D'autres donnces pour les images de données peuvent inclure un code exécutable pour un dispositif programmable, des donnces utilisées dans l'exécution de l'image en mémoire ROM ou d'autres données. Si une position non occupée par des données est découverte, le motif de remplissage avec la valeur d'alignement est écrit sur l'image en mémoire ROM. En variante, un motif de remplissage avec une valeur d'alignement peut étre écrit sur l'image en mémoire ROM et les données appropriées pour chaque image de donnces peuvent être écrites sur l'image en mémoire ROM. Le fichier de sortie est fermé lorsque le dernier multiplet de l'image en mémoire ROM est traité. Une forme de réalisati on, pri se à titre d'exemple, du processus d'écriture de l'image de données est
représentée sur la figure 7.
Après que le fichier de sortie est fermé, la somme de contrôle pour la totalité de l'image en mémoire ROM est calculée à
19 2828294
l'étape 334 et écrite sur l'image en mémoire ROM. Le processus sort alors à l'étape 310. Un système de programmation, tel que le dispositif 110 de la figure 1, peut 8tre configuré pour transférer l'image en mémoire ROM dans une mémoire telle qu'une mémoire ROM, PROM, EPROM ou EEPROM. La figure 4 décrit une forme de réalisation, prise à titre
d'exemple, d'un processus de paramétrage d'une image de données.
Le processus 320A de paramétrage de l'image de données exécute une itération en boucle à travers chaque image de données pour générer les paramètres de l'image de donnces à l'étape 402. La
dimension de chaque image de donnces est calculée à l'étape 404.
Chaque dimension de l'image de données est garnie d'une valeur d'alignement pour aligner l'image de donnces à la limite demandée à l'étape 406 (si demandé et/ou si nécessaire). La somme de contrôle, le contr81e cyclique par redondance CRC ou autre signature de validation de l'image de données avec la valeur d'alignement ajoutée, s'il y a lieu, sont déterminés à l'étape 408. En option, la somme de contr81e est masquée à l'étape 410. Si c'est le masque qui est choisi, par exemple, les 32 bits supérieurs de la somme de contrôle peuvent être masqués. D'autres processus de masquage peuvent 8tre utilisés. Le processus 320A revient alors pour exécuter une itération en boucle à travers l'image de données
suivante à l'étape 402.
La figure 5 décrit une forme de réalisation, prise à titre d'exemple, d'un processus de vérification d'un conflit d'adresse. Le processus 322A de vérification de conflit d'adresse effectue une
boucle d'itération à travers chaque image de données à l'étape 502.
Si l'adresse de début d'une image de données est en conflit avec l'adresse de début d'une autre image de données à l'étape 504, le conflit est identifié à l'étape 506. Si la position de la somme de contr81e d'une image de données est en conflit avec la position de la somme de contrôle d'une autre image de données à l'étape 508, un conflit est identifié à l'étape 506. Si la position d'adresse d'une image de donnces est en conflit avec la position d'adresses d'une autre image de données à l'étape 510, un conflit est identifié à
2828294
l'étape 506. Si la position de dimension d'une image de données est en conflit avec la position de dimension d'une autre image de données à l'étape 512, un conflit est identifié à l'étape 506. Si aucun conflit n'est identifié aux étapes 502, 508, 510 ou 512, le processus 322A effectue une boucle d'itération à travers l'image de
données suivante à l'étape 502.
La figure 6 décrit une forme de réali sati on, pri se à titre d'exemple, d'un processus d'affectation de l'adresse d'une image de donnces. Le processus 326A d' affectation d'une adresse effectue une itération en boucle à travers chaque image de données à l'étape 602. Le processus est achevé pour les images de données auxquelles une adresse de début est allouce dynamiquement. A l'étape 604, lorsqu'une section de mémoire est ouverte dans l'image en mémoire ROM, et si cette section de mémoire n'est pas repérée comme déjà essayée, alors cette position de mémoire est affectée à l'image de données à l'étape 606. Une section de mémoire dans l'image en mémoire ROM est ouverte si n'y sont actuellement mémorisés ni images de donnces ni paramètres associés. Une section de mémoire n'est pas repérée comme essayée si le processus d' affectation d'adresse n' a pas déjà essayé de sélectionner cette
position de mémoire pour mémorisation.
Si la position de mémoire n'est pas suffisante pour contenir l'image de donnces sélectionnée ou le paramètre sélectionné, ou si cette position de mémoire est repérée comme déjà essayée pour l'image de données sélectionnée à l'étape 604, le processus 326A détermine à l'étape 608 si cette adresse de début est affectée à une autre image de données précédente. Du fait que les positions d'adresse sont sélectionnces séquentiellement avant que le processus passe à l'étape 608, tout bloc de mémoire ouvert et disponible sera sélectionné. Toutefois ce processus itératif se produit à l'étape 604 et le passage à l'étape 608 suppose qu'aucun autre bloc ouvert à l' intérieur de l'image en mémoire ROM n' est suffisant. A l'étape 608 il est déterminé si une adresse de départ actuelle de l'image en mémoire ROM est affectée à une image de données
21 2828294
précédente et si l'image de donnces actuelle va tenir dans l'espace identifié par l'adresse de début actuelle. Dans ce cas, l'adresse de début actuelle de l'image en mémoire ROM est désaffectée pour l'image de données précédente, l'adresse de début actuelle est affectée à l'image de données actuelle et l'adresse de début actuelle est repérée comme déjà essayée pour l'image de données précédente à l'étape 610. Le processus 326A effectue une boucle d'itération à l'étape 604 pour essayer de faire tenir l'image de données
précédente à une nouvelle adresse de début.
A l'étape 608, si l'adresse de début actuelle n'est pas affectée à l' image de données précédente, et si la dernière adresse de début de l'image en mémoire ROM n'a pas été sélectionnée (pour déterminer si l'image de donnces actuelle va y tenir) à l'étape 612, la plus proche adresse précédente est sélectionnée à l'étape 614. Le processus d'itération se poursuit à l'étape 608 jusqu'à ce que la dernière adresse disponible de l'image en mémoire ROM apparaisse à l'étape 612. Si le processus passe à la dernière image précédente ayant la dernière adresse de début précédente à l'étape 612 et si cette adresse de début ne peut pas être affectée à l'image de données actuelle, le processus 326 va sortir
avec une erreur à l'étape 616.
La figure 7 décrit une forme de réalisation prise à titre
d'exemple d'une opération d'écriture sur l'image de données.
L' opération 3 32A d' écriture sur l'image de données effectue une itération en boucle à travers chaque multiplet se trouvant dans l'image en mémoire ROM à l'étape 702. Si une position du multiplet se trouvant dans l'image en mémoire ROM en cours de traitement est la même que la position d'un paramètre d'une image de données sélectionnée, l' opération 3 32A d' écriture sur l'image de données écrit la position du paramètre sur le multiplet en cours de traitement. Les positions de paramètre peuvent inclure une position de somme de contrôle, une position de dimension, une position de mémoire à laquelle est mémorisée la position de début d'une image
de données, une position de début, ou d'autres paramètres.
22 2828294
En se reportant à la figure 7, si la position du multiplet se trouvant dans l'image en mémoire ROM est la même que la position de la somme de contrôle de l'image de donnces, la position de la somme de contr81e est écrite sur ce multiplet à l'étape 706. Le multiplet se trouvant dans l'image en mémoire ROM, en cours de traitement, est actualisé par la dimension des données qui viennent d'être écrites dans le fichier de sortie à l'étape 708. Le processus effectue alors une itération en boucle à travers le multiplet suivant se trouvant dans l'image en mémoire ROM à l'étape 702. Si la position du multiplet n'est pas la même que la position de la somme de contr81e pour l'image de données à l'étape 704, mais que la position du multiplet est la même que la position de dimension de l'image de données à l'étape 710, alors la dimension de l'image de données est écrite sur ce multiplet à l'étape 712. Le multiplet se trouvant dans l'image en mémoire ROM est actualisé à l'étape 708 et le processus 332A effectue une itération en boucle à travers le multiplet suivant se trouvant dans l'image en mémoire ROM à
l'étape 702.
Si la position du multiplet n'est pas la même que la position de dimension de l'image de donnces à l'étape 710, mais que la position du multiplet est la même que là o la position de début de l'image de données (DISL) est mémorisée à l'étape 714, la position de l'image de donnces est écrite sur l'image en mémoire ROM à l'étape 716. Le multiplet se trouvant dans l'image en mémoire ROM est actualisée à l'étape 708 et le processus effectue une itération en boucle à travers le multiplet suivant se trouvant dans l'image en
mémoire ROM à l'étape 702.
Si la position du multiplet n'est pas la même que là o la position de début de l'image de données est mémorisée à l'étape 714, mais que la position du multiplet est la même que la position de début de l'image de données à l'étape 718, alors l'image de donnces est écrite dans le fichier à l'étape 720. Une valeur d'alignement d'un motif de remplissage sélectionné est écrite sur
l'image en mémoire ROM à l'étape 722, si nocessaire et si demandé.
Le multiplet se trouvant dans l'image en mémoire ROM est
23 2828294
actualisé à l'étape 708 et le processus effectue une itération en boucle à travers le multiplet suivant se trouvant dans l'image en
mémoire ROM à l'étape 702.
Si la position du multiplet n'est pas la même que la position de début de l'image de données à l'étape 718, alors une valeur d'alignement d'un motif de remplissage est écrite sur l'image en mémoire ROM à l'étape 724. Le multiplet se trouvant dans l'image en mémoire ROM est actualisé en 708 et le processus effectue une itération en boucle à travers le multiplet suivant se trouvant dans
l'image en mémoire ROM à l'étape 702 jusqu'à achèvement.
La figure 8 représente une forme de réalisation, prise à titre d'exemple, d'un processus de validation en mémoire ROM. Le processus 802 de validation en mémoire ROM peut être utilisé pour
valider une image en mémoire ROM mémorisée en mémoire ROM.
Par exemple le processus 802 de validation en mémoire ROM peut étre utilisé pour valider une image en mémoire ROM ou une ou plusieurs image de données après que l'image en mémoire ROM est mémorisée dans la mémoire ROM, par exemple après utilisation d'un système de calcul. En variante ou en supplément, le processus 802 de validation en mémoire ROM peut être utilisé pour valider séparément une ou plusieurs images de données dans l'image en mémoire ROM. On se rendra compte de ce que le processus 802 de validation en mémoire ROM a un module de validation en
mémoire ROM associé.
Le processus de validation en mémoire ROM démarre à l'étape 804 en faisant effectuer une itération en boucle à une première image de donnces, sélectionnée, de l'image en mémoire ROM. Bien que, typiquement, la première image de donnces sélectionnce ait une adresse de début au premier multiplet des image de donnces dans l'image en mémoire ROM, n'importe
quelle image de données peut être sélectionnée.
La totalité de l'image en mémoire ROM peut ne pas demander de validation. Dans certains cas seule une portion de l'image en mémoire ROM va demander la validation et une ou plusieurs images de donnces seulement nécessiteront la validation. Ceci peut se
24 2828294
produire lorsque seules des images de donnces sélectionnées sur l'image en mémoire ROM sont nocessaires pour faire fonctionner un système informatique ou un autre système. Par exemple une image en mémoire ROM peut contenir trois sections, chacune contenant un code pour une opération différente. Dans un exemple particulier, il est possible que deux des trois sections seulement puissent être nécessaires pour l'opération. Par conséquent le processus 802 de validation en mémoire ROM peut valider sélectivement, ou ne pas valider, une ou plusieurs des sections de l'image en mémoire ROM, c'est-à-dire une ou plusieurs des images de données, ce qui
accélère la validation.
L'adresse de début et la longueur de l'image de données sont lues à l'étape 806 et la signature originale de validation de l'image de données est lue à l'étape 808. D'autres paramètres de l'image de données peuvent 8tre lus sous d'autres formes de réalisation. Par exemple le type de signature de validation peut être identifié en tant que paramètre de l'image de données. Toutefois, en l'absence de spécification, le type de signature de validation est déterminé à l'étape 808. Dans certaines formes de réalisation, la signature de validation pour l'image de données peut être une somme de contrôle, un contrôle cyclique par redondance CRC ou le résultat d'un algorithme de cryptage à base d'une clé, par exemple une clé privée pour emploi avec un algorithme de cryptage d'une clé
publique. D'autres types de signatures de validation existent.
Un algorithme de validation de l'image de données est sélectionné pour générer une nouvelle signature de validation de l'image de données à l'étape 810. L'algorithme de validation de l'image de données est sélectionné sur la base du type de signature de validation de l'image de données identifié à l'étape 808. La nouvelle signature de validation de l'image de données est générée à l'étape 812 et la nouvelle signature de validation de l'image de donnces est comparée avec la signature originale de validation de l'image de donnces provenant de l'image en mémoire ROM à l'étape 814. Si la nouvelle signature de validation de l'image de données ne correspond pas à la signature originale de validation de
2828294
l'image de données à l'étape 814, le processus 802 sort avec une erreur à l'étape 816. En variante, le processus 802 peut étre configuré pour redémarrer ou répéter les étapes 806-814 ou un sous-ensemble de ces étapes, si la signature originale et la nouvelle signature de validation de l'image de données ne correspondent pas. En variante le processus 802 peut 8tre configuré pour noter que la signature originale et la nouvelle signature de validation de l'image de données ne correspondent pas, sauter cette image de données et effectuer une itération en boucle pour la nouvelle image de donnces à l'étape 804. Des mesures correctives peuvent être prises pour
l'image de donnces sautée.
Si la signature originale et la nouvelle signature de validation de l'image de donnces ne coïncident pas à l'étape 814 et si l'image de données que l'on vient de traiter n'était pas la dernière image de données dans l'image en mémoire ROM à l'étape 818, le processus 802 effectue une itération en boucle pour l'image de données suivantes se trouvant dans l'image en mémoire ROM à l'étape 804. Si l'image de données que l'on vient de traiter était la dernière image de données se trouvant dans l'image en
mémoire ROM à l'étape 818, le processus passe à l'étape 820.
A l'étape 820 la signature originale de validation pour l'image en mémoire ROM est lue. Le type de signature de validation peut être spécifié comme paramètre optionnel. Toutefois s'il n'est pas spécifié le type de signature de validation est déterminé à l'étape 820. Dans certaines formes de réalisation, la signature de validation pour l'image en mémoire ROM peut être une somme de contrôle, un contrôle cyclique par redondance CRC, ou le résultat d'un algorithme de cryptage à base de clé, tel qu'une clé privée pour emploi avec un algorithme de cryptage à clé publique. D'autres
types de signature de validation existent.
Un algorithme de validation est sélectionné pour générer une nouvelle signature de validation de l'image en mémoire ROM à l'étape 822. L'algorithme de validation de l'image en mémoire ROM est sélectionné sur la base du type de signature de validation de l'image en mémoire ROM identifié à l'étape 820. La
26 2828294
nouvelle signature de validation de l'image en mémoire ROM est générce à l'étape 824 et la nouvelle signature de validation de l'image en mémoire ROM est comparce avec la signature originale de validation de l'image en mémoire ROM, provenant de l'image en mémoire ROM, à l'étape 826. Si la nouvelle signature de validation de l'image en mémoire ROM ne correspond pas avec la signature originale de validation de l'image en mémoire ROM à l'étape 826, le processus 802 sort avec une erreur à l'étape 816. Si la nouvelle signature de validation de l'image en mémoire ROM correspond à la signature originale de validation de l'image en mémoire ROM à l'étape 826, l'image en mémoire ROM est validée à l'étape 828 et le
processus sort à l'étape 830.
Les processus identifiés aux étapes 820-830 sont optionnels. En outre les processus des étapes 820-830 peuvent être dans un
processus distinct ou un module distinct provenant des étapes 804-
818. Si les processus des étapes 820-830 sont un processus ou un module distincts ou ne sont pas inclus d'autre façon, le processus 802 de validation de la mémoire ROM se termine après que la dernière signature de validation de l'image de donnces pour la dernière image de donnces soit déterminée en 818. D'autres formes de réalisation pour le processus 802 de validation de la
mémoire ROM existent.
L'homme de l'art se rendra compte que des variantes par rapport aux formes de réalisation spécifiques décrites ci-dessus sont envisagées par l'invention. L'invention ne doit donc pas être limitée aux formes de réalisation ci-dessus, mais doit étre mesurée
par les revendications qui suivent.
Z / 2828294
Claims (10)
1. Procédé de génération d'une image en mémoire ROM (214) comportant les étapes consistant à: traiter un fichier d'entrée (204) pour générer un fichier d'objets (206) représentant des objets pour chaque image de données (210) identifiée dans le fichier d'objets (206); traiter chaque image de donnces avec son fichier d'objets associé pour créer une construction d'image de données (202) pour chaque image de données; générer une signature validant l'image de données pour chaque image de donnces (212); écrire chaque image de données et chaque signature validant l'image de données pour chaque construction d'image de données (212) sur l'image en mémoire ROM (214);et générer une signature (208) validant l'image en mémoire ROM
pour l'image en mémoire ROM.
2. Le procédé de la revendication 1 comportant en outre le fait d'aligner chaque image de donnces dans chaque construction d' image de données, si nocessaire, en utilisant un motif de remplissage et une valeur d'alignement (406) avant de générer
chaque signature validant l'image de donnces.
3. Le procédé de la revendication 1 comportant en outre le fait d' affecter dynamiquement une adresse de début pour l 'image en
mémoire ROM à au moins une image de données (326).
4. Le procédé de la revendication 1 dans lequel une première position de mémoire est affectée à une première image de données pour l'image en mémoire ROM (214), le procédé comportant en outre le fait de réaffecter dynamiquement la première position de mémoire à une seconde image de données et d'affecter une nouvelle position de mémoire à la première
image de donnces (610).
5. Le procédé de la revendication 1 dans lequel l'étape de génération de la signature validant l'image de donnces comporte l'utilisation d'au moins un élément d'un groupe
28 2828294
constitué d'une somme de contrôle (334) et d'un contrôle
cyclique par redondance pour valider l'image de données.
6. Le procédé de la revendication 1 comportant en outre les étapes consistant à: traiter le fichier d'entrée (206) pour générer un fichier d'objets temporaire (312) après avoir généré le fichier d'objets (306), le fichier d'objets temporaire représentant également les objets pour chaque image de donnces identifiée dans le fichier d'entrée (309); et comparer le fichier d'objets (206) avec le fichier d'objets temporaire (316) et, si ce sont les mêmes, traiter chaque image de données avec son fichier d'objets associé (206) pour créer
l'image en mémoire ROM (214).
7. Le système de la revendication 6 comportant en outre le fait de générer le fichier d'objets (206) avec un premier identificateur d'image et de générer le fichier d'objets temporaire (312) avec
un second identificateur d' image.
8. Le procédé de la revendication 1 comportant en outre le fait de masquer au moins une signature (410) validant une image de données.
9. Le procédé de la revendication 1 comportant en outre le fait d'effectuer une itération en boucle à travers chaque multiplet de l'image en mémoire ROM (702) et, si une position du multiplet de l'image en mémoire ROM en cours de traitement est la même que la position d'un paramètre d'une image de donnces sélectionnce, écrire la position du paramètre sur le
multiplet de l'image en mémoire ROM en cours de traitement.
10. Le système de la revendication 1 comportant en outre le fait de transférer l'image en mémoire ROM (214), d'un système de programmation, à au moins un élément d'un groupe constitué d'une mémoire ROM, d'une mémoire PROM, d'une
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/918,974 US7055035B2 (en) | 2001-07-31 | 2001-07-31 | Method for generating a read only memory image |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2828294A1 true FR2828294A1 (fr) | 2003-02-07 |
Family
ID=25441260
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0209594A Withdrawn FR2828294A1 (fr) | 2001-07-31 | 2002-07-29 | Procede pour generer une image en memoire morte |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7055035B2 (fr) |
| JP (1) | JP2003058433A (fr) |
| FR (1) | FR2828294A1 (fr) |
Families Citing this family (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8149048B1 (en) | 2000-10-26 | 2012-04-03 | Cypress Semiconductor Corporation | Apparatus and method for programmable power management in a programmable analog circuit block |
| US8103496B1 (en) | 2000-10-26 | 2012-01-24 | Cypress Semicondutor Corporation | Breakpoint control in an in-circuit emulation system |
| US7765095B1 (en) | 2000-10-26 | 2010-07-27 | Cypress Semiconductor Corporation | Conditional branching in an in-circuit emulation system |
| US6724220B1 (en) | 2000-10-26 | 2004-04-20 | Cyress Semiconductor Corporation | Programmable microcontroller architecture (mixed analog/digital) |
| US8176296B2 (en) | 2000-10-26 | 2012-05-08 | Cypress Semiconductor Corporation | Programmable microcontroller architecture |
| US7406674B1 (en) | 2001-10-24 | 2008-07-29 | Cypress Semiconductor Corporation | Method and apparatus for generating microcontroller configuration information |
| US8078970B1 (en) | 2001-11-09 | 2011-12-13 | Cypress Semiconductor Corporation | Graphical user interface with user-selectable list-box |
| US8042093B1 (en) | 2001-11-15 | 2011-10-18 | Cypress Semiconductor Corporation | System providing automatic source code generation for personalization and parameterization of user modules |
| US7844437B1 (en) | 2001-11-19 | 2010-11-30 | Cypress Semiconductor Corporation | System and method for performing next placements and pruning of disallowed placements for programming an integrated circuit |
| US8069405B1 (en) | 2001-11-19 | 2011-11-29 | Cypress Semiconductor Corporation | User interface for efficiently browsing an electronic document using data-driven tabs |
| US7770113B1 (en) | 2001-11-19 | 2010-08-03 | Cypress Semiconductor Corporation | System and method for dynamically generating a configuration datasheet |
| US6971004B1 (en) | 2001-11-19 | 2005-11-29 | Cypress Semiconductor Corp. | System and method of dynamically reconfiguring a programmable integrated circuit |
| US7774190B1 (en) | 2001-11-19 | 2010-08-10 | Cypress Semiconductor Corporation | Sleep and stall in an in-circuit emulation system |
| US8103497B1 (en) | 2002-03-28 | 2012-01-24 | Cypress Semiconductor Corporation | External interface for event architecture |
| US7308608B1 (en) | 2002-05-01 | 2007-12-11 | Cypress Semiconductor Corporation | Reconfigurable testing system and method |
| US7761845B1 (en) | 2002-09-09 | 2010-07-20 | Cypress Semiconductor Corporation | Method for parameterizing a user module |
| US7295049B1 (en) | 2004-03-25 | 2007-11-13 | Cypress Semiconductor Corporation | Method and circuit for rapid alignment of signals |
| US20060010326A1 (en) * | 2004-07-08 | 2006-01-12 | International Business Machines Corporation | Method for extending the CRTM in a trusted platform |
| US8082531B2 (en) * | 2004-08-13 | 2011-12-20 | Cypress Semiconductor Corporation | Method and an apparatus to design a processing system using a graphical user interface |
| US8286125B2 (en) | 2004-08-13 | 2012-10-09 | Cypress Semiconductor Corporation | Model for a hardware device-independent method of defining embedded firmware for programmable systems |
| US8069436B2 (en) * | 2004-08-13 | 2011-11-29 | Cypress Semiconductor Corporation | Providing hardware independence to automate code generation of processing device firmware |
| US7332976B1 (en) | 2005-02-04 | 2008-02-19 | Cypress Semiconductor Corporation | Poly-phase frequency synthesis oscillator |
| US7400183B1 (en) | 2005-05-05 | 2008-07-15 | Cypress Semiconductor Corporation | Voltage controlled oscillator delay cell and method |
| US8089461B2 (en) | 2005-06-23 | 2012-01-03 | Cypress Semiconductor Corporation | Touch wake for electronic devices |
| US8255108B2 (en) * | 2005-08-31 | 2012-08-28 | Spx Corporation | Dynamic file system creation for scan tools |
| US8067948B2 (en) | 2006-03-27 | 2011-11-29 | Cypress Semiconductor Corporation | Input/output multiplexer bus |
| US8040266B2 (en) | 2007-04-17 | 2011-10-18 | Cypress Semiconductor Corporation | Programmable sigma-delta analog-to-digital converter |
| US8092083B2 (en) | 2007-04-17 | 2012-01-10 | Cypress Semiconductor Corporation | Temperature sensor with digital bandgap |
| US7737724B2 (en) * | 2007-04-17 | 2010-06-15 | Cypress Semiconductor Corporation | Universal digital block interconnection and channel routing |
| US8026739B2 (en) | 2007-04-17 | 2011-09-27 | Cypress Semiconductor Corporation | System level interconnect with programmable switching |
| US8130025B2 (en) | 2007-04-17 | 2012-03-06 | Cypress Semiconductor Corporation | Numerical band gap |
| US9564902B2 (en) | 2007-04-17 | 2017-02-07 | Cypress Semiconductor Corporation | Dynamically configurable and re-configurable data path |
| US8516025B2 (en) | 2007-04-17 | 2013-08-20 | Cypress Semiconductor Corporation | Clock driven dynamic datapath chaining |
| US8065653B1 (en) | 2007-04-25 | 2011-11-22 | Cypress Semiconductor Corporation | Configuration of programmable IC design elements |
| US9720805B1 (en) | 2007-04-25 | 2017-08-01 | Cypress Semiconductor Corporation | System and method for controlling a target device |
| US8266575B1 (en) | 2007-04-25 | 2012-09-11 | Cypress Semiconductor Corporation | Systems and methods for dynamically reconfiguring a programmable system on a chip |
| US8049569B1 (en) | 2007-09-05 | 2011-11-01 | Cypress Semiconductor Corporation | Circuit and method for improving the accuracy of a crystal-less oscillator having dual-frequency modes |
| TWI401566B (zh) * | 2009-04-01 | 2013-07-11 | Inventec Corp | 磁碟陣列設定檔更新方法 |
| US9448964B2 (en) | 2009-05-04 | 2016-09-20 | Cypress Semiconductor Corporation | Autonomous control in a programmable system |
| US9244769B2 (en) | 2010-09-28 | 2016-01-26 | Pure Storage, Inc. | Offset protection data in a RAID array |
| US9135436B2 (en) * | 2012-10-19 | 2015-09-15 | The Aerospace Corporation | Execution stack securing process |
| CN103226505B (zh) * | 2013-04-22 | 2016-08-03 | 华为技术有限公司 | 一种校验基本输入输出系统bios的方法及设备 |
| US10255287B2 (en) * | 2015-07-31 | 2019-04-09 | Hiveio Inc. | Method and apparatus for on-disk deduplication metadata for a deduplication file system |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5235551A (en) * | 1991-01-08 | 1993-08-10 | Pacific Data Products, Inc. | Memory addressing scheme |
| US5623604A (en) * | 1992-11-18 | 1997-04-22 | Canon Information Systems, Inc. | Method and apparatus for remotely altering programmable firmware stored in an interactive network board coupled to a network peripheral |
| JPH1049360A (ja) * | 1996-08-06 | 1998-02-20 | Nec Eng Ltd | フラッシュメモリへの書き込み方式 |
| JP3266560B2 (ja) * | 1998-01-07 | 2002-03-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 情報処理システム及びその制御方法 |
| US6092189A (en) * | 1998-04-30 | 2000-07-18 | Compaq Computer Corporation | Channel configuration program server architecture |
| US6223284B1 (en) * | 1998-04-30 | 2001-04-24 | Compaq Computer Corporation | Method and apparatus for remote ROM flashing and security management for a computer system |
| US6715074B1 (en) * | 1999-07-27 | 2004-03-30 | Hewlett-Packard Development Company, L.P. | Virus resistant and hardware independent method of flashing system bios |
-
2001
- 2001-07-31 US US09/918,974 patent/US7055035B2/en not_active Expired - Fee Related
-
2002
- 2002-07-05 JP JP2002197000A patent/JP2003058433A/ja active Pending
- 2002-07-29 FR FR0209594A patent/FR2828294A1/fr not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| US20030028772A1 (en) | 2003-02-06 |
| US7055035B2 (en) | 2006-05-30 |
| JP2003058433A (ja) | 2003-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2828294A1 (fr) | Procede pour generer une image en memoire morte | |
| TWI220962B (en) | Firmware updating method and related apparatus for checking content of replacing firmware before firmware updating | |
| EP0546048B1 (fr) | Procede et dispositif de mise a jour d'informations dans une memoire et leur utilisation dans les cartes a memoire | |
| FR3072798A1 (fr) | Ordonnancement de taches dans un processeur a fils d'execution multiples | |
| EP0565389A1 (fr) | Procédé de personnalisation d'une carte à puce | |
| FR2667171A1 (fr) | Support portable a micro-circuit facilement programmable et procede de programmation de ce micro-circuit. | |
| WO2013079885A1 (fr) | Ecriture de donnees dans une memoire non volatile de carte a puce | |
| US9697668B2 (en) | Automatically configurable smart card and method of automatically configuring a smart card | |
| FR2713368A1 (fr) | Procédure et procédé de communication entre machines et procédé généralisé de préparation de programmes afférents. | |
| EP3293637A1 (fr) | Gestion d'index dans une mémoire flash | |
| CN108694049B (zh) | 一种更新软件的方法和设备 | |
| CN111026398B (zh) | 基于缓存的数据集成的构建方法与构建系统 | |
| FR2828295A1 (fr) | Systeme pour generer une image en memoire morte | |
| EP3246820A1 (fr) | Gestion du stockage dans une mémoire flash | |
| EP0838053B1 (fr) | Procede et dispositif permettant a un programme fige de pouvoir evoluer | |
| CN114816509A (zh) | 区块链版本兼容性验证方法及装置、电子设备 | |
| EP3284206B1 (fr) | Procédé de sécurisation de l' exécution d'un programme | |
| WO2003027851A1 (fr) | Procede et dispositif de verifieur de code optimise | |
| EP0512881B1 (fr) | Procédé et dispositif de sélection d'informations utilisables par une unité locale reliée à un système de transmission numérique | |
| US20060149894A1 (en) | Method of downloading main code to flash memory | |
| EP2383746B1 (fr) | Procédé d'écriture et de lecture dans une mémoire d'atomicité | |
| CN116127480A (zh) | 一种智能合约检测方法及装置 | |
| FR3103590A1 (fr) | Procédé de construction d’une signature caractéristique des accès, par un microprocesseur, à une mémoire | |
| CN116719577A (zh) | 一种引导参数修改的方法、装置、设备及介质 | |
| EP3246819A1 (fr) | Compteur en mémoire flash |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20060331 |