Ne suivez pas ce lien ou vous tomberez dans un trou noir et vous serez banni du site.Et je rajoute la v324:
en date du 30/12/2011 ...
JackJean, do you give up?
en date du 30/12/2011 ...
JackJean, do you give up?
Un technicien de l'atelier ASUS en direct : 08 90 21 38 48 (0,80c/min)
X53SV Ethernet Realtek ne peut pas démarrer
- Auteur de la discussion jackjean
- Date de début
0 personne(s) consulte(nt) ce sujet : 0 membre(s) et 0 invité(s).
bonsoir,
je vois que tu as laissé choir ^^
bon; la comparaison des 2 fichiers de BIOS (le dump / la MàJ Asus) n'a rien donné
par contre j'ai appris des choses
- déjà, en recherchant sur le web, j'ai appris que
--- l'UUID et la m@c se retrouvent bien dans le MainBIOS quand l'ordinateur est en route
--- l'UUID se trouve à une adresse - 1 offset bien spécifique: A01B8~0xA01C7
--- l'adresse m@c se trouve elle aussi, mais à 2 offsets différents spécifiques (?)
Cf ce topic:
J'ai donc vérifié dans mes petits fichiers, voici le résultat:
- dans le fichier MainBIOS.bin issu du dump de l'EEPROM, il n'y a pas d'UUID ni d'adresse m@c aux offsets indiqués:
D'ailleurs, il n'y a rien dut tout, rien qu'une suite hexa interminable de FFFF ...
- dans le fichier de BIOS, version 324, et ce que je n'avais pas vu c'est que l'italien qui l'a mis à dispo, l'avait aussi dumpé depuis sa machine suite au retour de son PC de RMA, il y a l'adresse m@c, à 2 offsets différents, mais pas l'UUID, ou en tout cas, juste 1 semblant:
Voici l'adresse m@c, et on peut facilement vérifier qu'elle vient bien d'Asus ici: https://standards.ieee.org/develop/regauth/oui/public.html
Celle-ci est répétée plus loin aux offsets A81D7 - A81DC.
Voici les offsets de l'UUID, ou du semblant d'UUID:
Sur les 20 caractères que compte la 1ère partie de l'UUID, seulement 2 semblent correcte (entourés en rouge), les autres, c'est que du blabla version FFFFF.
Il y a quand même 1 problème, car sur 1 dump du BIOS de mon M70Vn, réalisé avec Universal BIOS Backup Toolkit, les 2 sont bien présentes (à des plages d'offsets différentes, mais, - déjà c'est 1 machine complétement différente, basée sur une autre plateforme matérielle et esnuite, c'est aussi une version de BIOS différent (AmiBIOS 8) de celui du K53SV (Aptio), tout ceci expliquant certainement cela en grande partie).
La différence entre les 2 me confirme dans ce que j'avais précédemment supposé: le dump de l'EEPROM du K53SV issu du site 1Bios.ru a été effectué d'1 façon ou d'1 autre, machine éteinte, alors que le dump du BIOS du K53SV réalisé par l'italien, l'a été machine allumée, soit depuis 1 OS, soit d'1 autre façon (DOS ou DOS-Like?).
Une conséquence directe de cela, c'est que même en reflashant ton PC avec le BIOS v324 de l'italien, ou en reprogrammant l'EEPROM (après avoir joint/réuni les 2 parties, la 1ère "soustraite" du dump du site 1Bios.ru, et la 2nde le MainBIOS v324 issu du dump de l'italien), ne te permettra sans doute pas de récupérer l'UUID -- peut-être l'adresse m@c, et encore pas certain.
Aussi, a contrario de ce que j'avais suppose avant, les UUID/adresse m@c ne se trouvent pas dans l'1 des modules relatifs au SMBIOS, mais ailleurs dans le MainBIOS, dans 1 (des) région(s) différente(s) -- il reste à déterminer à quoi celle(s)-ci corresponde(ent).
En recherchant des cas similaires au tien (perte de l'UUID et de l'adresse m@c), j'ai voulu pousser plus loin mes recherches, mais en tout cas, j'ai continué de fil en aiguilles, et ... comme par enchantement, via ce topic, je suis tombé sur 1 petit outil développé par Intel, s'appelant Intel Flash Programming Tool et qui, je dois l'avouer est vraiment pas mal. Ce petit outil FPT est partie intégrante d'1 suite s'appelant Intel System Tools. Il ne peut être exécuté que sur 1 PC disposant d'1 chipset Intel (et encore, ça va dépendre de quelle famille/série ^^).
Entre autres choses, il permet de dumper les différentes régions de l'EEPROM, il peut y en avoir jusque 5 en tout:
cf System Tools User Guide for Intel® Management Engine Firmware 6.0 (à partir de la page 59).
A la page 60, la structure d'1 EEPROM est décrite:
J'ai donc testé sur 1 X55VD (sur mon M70Vn, ça passe pas, malgré diverses versions testées: soit il m'envoie dans les fraises en me disant que je n'ai pas les droits même en ayant tout fait pour les obtenir, soit il me jette aux orties en citant ma plateforme (ICH9M) et que l'opération ne peut être réalisée sur cette dernière).
Je donne les résultats demain, je fatigue là.
je vois que tu as laissé choir ^^
bon; la comparaison des 2 fichiers de BIOS (le dump / la MàJ Asus) n'a rien donné
par contre j'ai appris des choses
- déjà, en recherchant sur le web, j'ai appris que
--- l'UUID et la m@c se retrouvent bien dans le MainBIOS quand l'ordinateur est en route
--- l'UUID se trouve à une adresse - 1 offset bien spécifique: A01B8~0xA01C7
--- l'adresse m@c se trouve elle aussi, mais à 2 offsets différents spécifiques (?)
Cf ce topic:
J'ai donc vérifié dans mes petits fichiers, voici le résultat:
- dans le fichier MainBIOS.bin issu du dump de l'EEPROM, il n'y a pas d'UUID ni d'adresse m@c aux offsets indiqués:
D'ailleurs, il n'y a rien dut tout, rien qu'une suite hexa interminable de FFFF ...
- dans le fichier de BIOS, version 324, et ce que je n'avais pas vu c'est que l'italien qui l'a mis à dispo, l'avait aussi dumpé depuis sa machine suite au retour de son PC de RMA, il y a l'adresse m@c, à 2 offsets différents, mais pas l'UUID, ou en tout cas, juste 1 semblant:
Voici l'adresse m@c, et on peut facilement vérifier qu'elle vient bien d'Asus ici: https://standards.ieee.org/develop/regauth/oui/public.html
Celle-ci est répétée plus loin aux offsets A81D7 - A81DC.
Voici les offsets de l'UUID, ou du semblant d'UUID:
Sur les 20 caractères que compte la 1ère partie de l'UUID, seulement 2 semblent correcte (entourés en rouge), les autres, c'est que du blabla version FFFFF.
Il y a quand même 1 problème, car sur 1 dump du BIOS de mon M70Vn, réalisé avec Universal BIOS Backup Toolkit, les 2 sont bien présentes (à des plages d'offsets différentes, mais, - déjà c'est 1 machine complétement différente, basée sur une autre plateforme matérielle et esnuite, c'est aussi une version de BIOS différent (AmiBIOS 8) de celui du K53SV (Aptio), tout ceci expliquant certainement cela en grande partie).
La différence entre les 2 me confirme dans ce que j'avais précédemment supposé: le dump de l'EEPROM du K53SV issu du site 1Bios.ru a été effectué d'1 façon ou d'1 autre, machine éteinte, alors que le dump du BIOS du K53SV réalisé par l'italien, l'a été machine allumée, soit depuis 1 OS, soit d'1 autre façon (DOS ou DOS-Like?).
Une conséquence directe de cela, c'est que même en reflashant ton PC avec le BIOS v324 de l'italien, ou en reprogrammant l'EEPROM (après avoir joint/réuni les 2 parties, la 1ère "soustraite" du dump du site 1Bios.ru, et la 2nde le MainBIOS v324 issu du dump de l'italien), ne te permettra sans doute pas de récupérer l'UUID -- peut-être l'adresse m@c, et encore pas certain.
Aussi, a contrario de ce que j'avais suppose avant, les UUID/adresse m@c ne se trouvent pas dans l'1 des modules relatifs au SMBIOS, mais ailleurs dans le MainBIOS, dans 1 (des) région(s) différente(s) -- il reste à déterminer à quoi celle(s)-ci corresponde(ent).
En recherchant des cas similaires au tien (perte de l'UUID et de l'adresse m@c), j'ai voulu pousser plus loin mes recherches, mais en tout cas, j'ai continué de fil en aiguilles, et ... comme par enchantement, via ce topic, je suis tombé sur 1 petit outil développé par Intel, s'appelant Intel Flash Programming Tool et qui, je dois l'avouer est vraiment pas mal. Ce petit outil FPT est partie intégrante d'1 suite s'appelant Intel System Tools. Il ne peut être exécuté que sur 1 PC disposant d'1 chipset Intel (et encore, ça va dépendre de quelle famille/série ^^).
Entre autres choses, il permet de dumper les différentes régions de l'EEPROM, il peut y en avoir jusque 5 en tout:
cf System Tools User Guide for Intel® Management Engine Firmware 6.0 (à partir de la page 59).
A la page 60, la structure d'1 EEPROM est décrite:
J'ai donc testé sur 1 X55VD (sur mon M70Vn, ça passe pas, malgré diverses versions testées: soit il m'envoie dans les fraises en me disant que je n'ai pas les droits même en ayant tout fait pour les obtenir, soit il me jette aux orties en citant ma plateforme (ICH9M) et que l'opération ne peut être réalisée sur cette dernière).
Je donne les résultats demain, je fatigue là.
- Modèle
- Plusieurs machines ASUS (X66-52 -53-73, N61-53)
- Système
- Win 7
Pas mal du tout, ça... Dommage que FITC (utilitaire de génération de l'image) ne tourne pas sur W7, et en tous cas pas en X64. ça aurait été sympa de m'en tenir à un seul enesemble d'outils du même éditeur.
Ne soyons pas fine bouche...
ça t'intéresserait que je t'envoie le dump de mon X53SV (que je ferais avec Universal BIOS Backup Toolkit) ? Afin peut être de comparer avec celui de l'italien?
Bon, le fait de perdre espoir au sujet de l'UUID ne me gêne pas plus que ça, ça n'enlève pas vraiment de fonctionnalité à la machine.
Par contre l'adresse M@C qui semble plus facilemant localisable est déjà un beau succès je trouve...
Allez, bonne nuit
Ne soyons pas fine bouche...
ça t'intéresserait que je t'envoie le dump de mon X53SV (que je ferais avec Universal BIOS Backup Toolkit) ? Afin peut être de comparer avec celui de l'italien?
Bon, le fait de perdre espoir au sujet de l'UUID ne me gêne pas plus que ça, ça n'enlève pas vraiment de fonctionnalité à la machine.
Par contre l'adresse M@C qui semble plus facilemant localisable est déjà un beau succès je trouve...
Allez, bonne nuit
re,
NB: petite édition de mon précédent post, avec quelques liens web en + ^^
(pourtant je suis sûr qu'il existe une version du SW pouvant faire son job -- j'ai vu 1 donc Intel qui en parlait (pour les chipsets 4 Série))
Intel FPT fonctionne aussi sur Windows 8 (je l'ai utilisé avec succès sur Win8 64 bits)
Donc, ne me semble pas adéquat. En tout cas, je ne l'ai pas utilisé sur le X55VD, mais l'outil Intel FPT.
NB: petite édition de mon précédent post, avec quelques liens web en + ^^
si, si, il tourne très bien sous Win7, tout aussi bien que sous Win7 64 bits: c'est juste qu'il ne peut travailler sur des plateformes matérielles plus anciennes tel que celle de mon M70Vn, aka le chipset ICH9M -- enfin avec les versions de FPT que j'ai réussi à trouver jusque là. J’arrive sur plateforme ICH9M et Win7 64 bits sur mon M70VN, à appeler l'aide du programme, c'est donc qu'il fonctionne -- mais dès qu'il s'agit de dumper le BIOS dans 1 fichier, nada, rien à faire
(pourtant je suis sûr qu'il existe une version du SW pouvant faire son job -- j'ai vu 1 donc Intel qui en parlait (pour les chipsets 4 Série))
Intel FPT fonctionne aussi sur Windows 8 (je l'ai utilisé avec succès sur Win8 64 bits)
oui, mais tu ne feras pas le dump avec UBBT, ce SW est assez ancien et ne risque par de fonctionner sur ta plateforme, enfin je veux dire avec 1 APtioBIOS ; de +, même s'il fonctionnait, il risquerait de louper certaines régions de la puce (Desc region, ME region, GBe region etPDR region).
Donc, ne me semble pas adéquat. En tout cas, je ne l'ai pas utilisé sur le X55VD, mais l'outil Intel FPT.
on n'en a pas fini avec ça ^^
Bon je poursuis avec mes tests réalisés avec l'outil FPT sur 1 X55VD(R)
De fait, j'ai 1 bonne base pour trouver UUID + m@c dans les dumps réalisés avec FPT puisque, dans mon cas, je les connaît:
La recherche par valeur hexa dans les dumps obtenus en est grandement facilitée!
Tout d'abord, je tiens à préciser que j'ai réalisé les dumps:
- depuis 1 Win8 en 64 bits
- avec FPT en version 8.0.10.1464 et en version Windows 64 bits (fptw64.exe)
NB: en fonction de la plateforme (chipset) dont dispose votre système, il est nécessaire d'utiliser une version adaptée à celle-ci, càd qui supporte votre plateforme (chipset):
Comme je l'avais déduit, il existe bien 1 outils pour ICH9-M.
Référez-vous à ce tableau pour connaître la version de l'outil adéquat:
- qu'il m'a fallu copier le dossier contenant l’utilitaire (et les fichiers nécessaires) à la racine de C:, donner les autorisations en Contrôle total à tous les utilisateurs au dossier contenant les fichiers nécessaires à l'exécution du programme, ainsi que de paramétrer le programme en mode Administrateur et compatibilité Windows 7 sur tous les utilisateurs, sinon on a droit à 1 refus d'exécution de la sauvegarde (dump) des différentes régions de l'EEPROM (l'appel à l'aide du programme fonctionne bien même sans cela).
Téléchargement: ici ou là ou encore là.
Pour info, voici les diverses commandes, options et paramètres disponibles dans la version de ce programme:
Comme vous pouvez le constater, c'est 1 programme très puissant à utiliser avec 1 très grande prudence et 1 très grande précaution et surtout en évitant la précipitation.
Pour la sauvegarde, les seules commandes qui nous sont utiles et nous intéressent ici sont:
et c'est tout!! Les autres commandes, options & paramètres de l'outil sont inutiles dans notre cas.
Passons aux choses sérieuses, le dump des différentes régions
Tout d'abord, le MainBIOS:
Par exemple:
Comme on peut le constater, majuscules ou minuscules pour les options à passer au programme, n'a pas d'importance.
Le retour de la commande nous affiche quelques infos bien intéressantes
- la plateforme du système, aka le chipset,
pour le X55VD(R), il s’agit d'1 PCH HM76 Express Chipset (Panther Point)
cf également ces docs: HM76 Express Chipset Product Brief
Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) [Datasheet]
Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) [Spec. Update]
- une opération de lecture dans le registre HSFSTS (HSFS = registre Hardware Sequencing Flash Status & TS?).
J'avoue ne pas trop comprendre à quoi ça correspond, et que je ne vais pas non plus approfondir, mais le principal, c'est que ça retourne 1 descripteur flash valide.
Si vous voulez en savoir plus, référez-vous à ces documents:
Intel® 7 Series / C216 Chipset Family Platform Controller Hub (PCH), section 22, Serial Peripheral Interface (SPI)
Intel 7 Series Chipset and Intel C216 Chipset SPI Programming Guide, section 11.1 FAQ
- le modèle de puce, son ID et sa taille -- il ne reste alors plus qu'à rechercher sur le web, les caras de cette puce^^
Dans le cas du X55VD, c'est 1 Winbond W25Q64BV, Serial Flash Memory.
Puis vient enfin l'opération de dump, il me demande si je veux écraser le fichier existant, car j'ai déjà sauvegardé 1 fichier avec le même nom: la procédure de lecture de la puce et celle de dump sont effectuées ... et c'est très rapide.
De même, pour le dump des autres régions:
Il n'y a que pour la région PDR que ça ne passe pas:
Celle-ci ne semble pas exister ... à moins qu'elle soit autre part?
Faut-il lire vraisemblablement GPDR (GPIO (General Purpose Input/Output) Pin Direction Register) ou simplement PDR?
Je ne m'appesantis pas là-dessus, ça ne me paraît ps important outre mesure ...
NB: j'ai fait une petite erreur sur le nom de sortie des fichiers résultants du dump des différentes régions de la puce SPI, mais ça n'a aucune importance pour l'objectif recherché, il suffira des les renommés par la suite.
On se retrouve donc avec 4 fichiers de dump au final.
Poussons l'analyse plus loin...
... dans le prochain post, ici.
De fait, j'ai 1 bonne base pour trouver UUID + m@c dans les dumps réalisés avec FPT puisque, dans mon cas, je les connaît:
La recherche par valeur hexa dans les dumps obtenus en est grandement facilitée!
Tout d'abord, je tiens à préciser que j'ai réalisé les dumps:
- depuis 1 Win8 en 64 bits
- avec FPT en version 8.0.10.1464 et en version Windows 64 bits (fptw64.exe)
NB: en fonction de la plateforme (chipset) dont dispose votre système, il est nécessaire d'utiliser une version adaptée à celle-ci, càd qui supporte votre plateforme (chipset):
Comme je l'avais déduit, il existe bien 1 outils pour ICH9-M.
Référez-vous à ce tableau pour connaître la version de l'outil adéquat:
- qu'il m'a fallu copier le dossier contenant l’utilitaire (et les fichiers nécessaires) à la racine de C:, donner les autorisations en Contrôle total à tous les utilisateurs au dossier contenant les fichiers nécessaires à l'exécution du programme, ainsi que de paramétrer le programme en mode Administrateur et compatibilité Windows 7 sur tous les utilisateurs, sinon on a droit à 1 refus d'exécution de la sauvegarde (dump) des différentes régions de l'EEPROM (l'appel à l'aide du programme fonctionne bien même sans cela).
Téléchargement: ici ou là ou encore là.
Pour info, voici les diverses commandes, options et paramètres disponibles dans la version de ce programme:
Comme vous pouvez le constater, c'est 1 programme très puissant à utiliser avec 1 très grande prudence et 1 très grande précaution et surtout en évitant la précipitation.
Pour la sauvegarde, les seules commandes qui nous sont utiles et nous intéressent ici sont:
Code:
- D # pour dump (sauvegarde)
- BIOS # pour préciser que la région concernée est le BIOS
- DESC # pour préciser que la région concernée est le Descriptor
- ME # pour préciser que la région concernée est la ME
- GBe # pour préciser que la région concernée est la GBe
- PDR # pour préciser que la région concernée est la PDR
cf + haut le document Intel pour 1 description de ces différentes régionsPassons aux choses sérieuses, le dump des différentes régions
Tout d'abord, le MainBIOS:
Code:
fptw64 -BIOS -D nom_du_bios.romComme on peut le constater, majuscules ou minuscules pour les options à passer au programme, n'a pas d'importance.
Le retour de la commande nous affiche quelques infos bien intéressantes
- la plateforme du système, aka le chipset,
pour le X55VD(R), il s’agit d'1 PCH HM76 Express Chipset (Panther Point)
cf également ces docs: HM76 Express Chipset Product Brief
Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) [Datasheet]
Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) [Spec. Update]
- une opération de lecture dans le registre HSFSTS (HSFS = registre Hardware Sequencing Flash Status & TS?).
J'avoue ne pas trop comprendre à quoi ça correspond, et que je ne vais pas non plus approfondir, mais le principal, c'est que ça retourne 1 descripteur flash valide.
Si vous voulez en savoir plus, référez-vous à ces documents:
Intel® 7 Series / C216 Chipset Family Platform Controller Hub (PCH), section 22, Serial Peripheral Interface (SPI)
Intel 7 Series Chipset and Intel C216 Chipset SPI Programming Guide, section 11.1 FAQ
- le modèle de puce, son ID et sa taille -- il ne reste alors plus qu'à rechercher sur le web, les caras de cette puce^^
Dans le cas du X55VD, c'est 1 Winbond W25Q64BV, Serial Flash Memory.
Puis vient enfin l'opération de dump, il me demande si je veux écraser le fichier existant, car j'ai déjà sauvegardé 1 fichier avec le même nom: la procédure de lecture de la puce et celle de dump sont effectuées ... et c'est très rapide.
De même, pour le dump des autres régions:
Il n'y a que pour la région PDR que ça ne passe pas:
Celle-ci ne semble pas exister ... à moins qu'elle soit autre part?
Faut-il lire vraisemblablement GPDR (GPIO (General Purpose Input/Output) Pin Direction Register) ou simplement PDR?
Je ne m'appesantis pas là-dessus, ça ne me paraît ps important outre mesure ...
NB: j'ai fait une petite erreur sur le nom de sortie des fichiers résultants du dump des différentes régions de la puce SPI, mais ça n'a aucune importance pour l'objectif recherché, il suffira des les renommés par la suite.
On se retrouve donc avec 4 fichiers de dump au final.
Poussons l'analyse plus loin...
... dans le prochain post, ici.
Suite ...
(post précédent édité)
@ JackJean:
--------------------------
Bon je continue.
Il s'agit maintenant de déterminer dans quels fichiers de dump résident les UUIDs et adresse m@c.
En tout cas, pas dans les dumps des régions DESC, ME et GBE, qui sont complétement vierges d'1 quelconque mention à l'UUID et à l'adresse m@c.
Petite précision; il se peut que le région GBE ne corresponde aucunement à la carte ETH GBE Realtek, mais tout simplement à une carte LAN GBE Intel intégrée au chipset HM76 lui-même, comme cela est indiqué qu'il en dispose d'1 dans les documents cités plus haut.
Cette remarque ne s'applique pas uniquement au chipset HM76, mais peut très bien être valable pour d'autres chipsets Intel intégrant 1 LAN GBE: à vous de voir avec la doc° Intel disponible concernant celui-ci.
Ne reste donc plus que le dump du MainBIOS: l'UUID et la m@c s'y trouvent bien!
- A 2 endroits différents pour les 20 1ers caractères uniquement de l'UUID, aux plages d'adresses
30032-3003B & 301B8-301C1.
Noter que les 12 caractères suivants les 20 1ers sur la plage d'adresses 30032-3003B et qui devraient en principe correspondre à une m@c, ne renvoient à aucune m@c valide (vérifié avec les 3 1ers caractères correspondant au fabricant).
- A 2 endroits différents pour l'adresse m@c, aux plages d'offsets 301C2-301C7 & 301D7-301DC
Examinons d'1 peu plus près ce MainBIOS et tentons de voir dans quel volume/module peuvent bien être stockés l'UUID et la m@c.
Mais pour se faire, on n'utilisera pas cette fois MMTool car celui n'affiche que les volumes/modules du BIOS correspondant à 1 quelque chose de bien spécifique (pilote, routine, application, FW, etc. ) mais pas les parties correspondant à du padding ou à du vide.
Or, c'est dommage, car sur le fichier de dump réalisé, il y a pratiquement 50% d'espace vide (2,70 Mo d'espace libre sur une image de 6 Mo).
En conséquence, il se pourrait fort bien que l'on passe à côté de quelque chose... et précisément de ce que l'on recherche.
Pour visualiser la structure complète du MainBIOS & en extraire ces différentes parties, j'utiliserai donc l'outil Phoenix Tool qui le permet, et qui, contrairement à ce que semble indiquer son nom, n'est pas réservé au BIOS Phoenix/Award.
Téléchargement (version 2.12) ici.
Lançons le programme et ouvrons le fichier de dump du MainBIOS, une fois passé les différents messages et après avoir cliquer sur le bouton Structure, on obtient ceci:
C'est quand même plus complet que MMTool, on visualise mieux la structure du BIOS.
Par comparaison, ce qu'affiche MMTool:
Maintenant, on va essayer de trouver dans quel module ou partie se trouvent stockées UUID et m@c, et ce sans en omettre aucun(e). On pourrait extraire tout et passer en revue les 1 après les autres les différents fichiers obtenus, mais ça risque d'être long, passablement fastidieux et assez ennuyeux.
Cependant, l'on a déjà une petite info: on sait que les infos recherchées se trouvent en début du fichier de dump ... en toute logique, ces mêmes infos devraient donc se trouver dans l'1 des toutes 1ères parties ou volumes recensés dans l'affichage précédent de la structure du BIOS par Phoenix Tool.
C'est le cas: dans le 2ème Padding affiché, il suffit de l'extraire, et de l'ouvrir avec 1 éditeur hexa pour s'en rendre compte.
Bingo!
On y est enfin. Ceci dit, il est fort possible que pour d'autres BIOSes, la structure soit différente, et donc les résultats différents de ceux présentés ici.
(post précédent édité)
@ JackJean:
je ne sais pas plus
--------------------------
Bon je continue.
Il s'agit maintenant de déterminer dans quels fichiers de dump résident les UUIDs et adresse m@c.
En tout cas, pas dans les dumps des régions DESC, ME et GBE, qui sont complétement vierges d'1 quelconque mention à l'UUID et à l'adresse m@c.
Petite précision; il se peut que le région GBE ne corresponde aucunement à la carte ETH GBE Realtek, mais tout simplement à une carte LAN GBE Intel intégrée au chipset HM76 lui-même, comme cela est indiqué qu'il en dispose d'1 dans les documents cités plus haut.
Cette remarque ne s'applique pas uniquement au chipset HM76, mais peut très bien être valable pour d'autres chipsets Intel intégrant 1 LAN GBE: à vous de voir avec la doc° Intel disponible concernant celui-ci.
Ne reste donc plus que le dump du MainBIOS: l'UUID et la m@c s'y trouvent bien!
- A 2 endroits différents pour les 20 1ers caractères uniquement de l'UUID, aux plages d'adresses
30032-3003B & 301B8-301C1.
Noter que les 12 caractères suivants les 20 1ers sur la plage d'adresses 30032-3003B et qui devraient en principe correspondre à une m@c, ne renvoient à aucune m@c valide (vérifié avec les 3 1ers caractères correspondant au fabricant).
- A 2 endroits différents pour l'adresse m@c, aux plages d'offsets 301C2-301C7 & 301D7-301DC
Examinons d'1 peu plus près ce MainBIOS et tentons de voir dans quel volume/module peuvent bien être stockés l'UUID et la m@c.
Mais pour se faire, on n'utilisera pas cette fois MMTool car celui n'affiche que les volumes/modules du BIOS correspondant à 1 quelque chose de bien spécifique (pilote, routine, application, FW, etc. ) mais pas les parties correspondant à du padding ou à du vide.
Or, c'est dommage, car sur le fichier de dump réalisé, il y a pratiquement 50% d'espace vide (2,70 Mo d'espace libre sur une image de 6 Mo).
En conséquence, il se pourrait fort bien que l'on passe à côté de quelque chose... et précisément de ce que l'on recherche.
Pour visualiser la structure complète du MainBIOS & en extraire ces différentes parties, j'utiliserai donc l'outil Phoenix Tool qui le permet, et qui, contrairement à ce que semble indiquer son nom, n'est pas réservé au BIOS Phoenix/Award.
Téléchargement (version 2.12) ici.
Lançons le programme et ouvrons le fichier de dump du MainBIOS, une fois passé les différents messages et après avoir cliquer sur le bouton Structure, on obtient ceci:
C'est quand même plus complet que MMTool, on visualise mieux la structure du BIOS.
Par comparaison, ce qu'affiche MMTool:
Maintenant, on va essayer de trouver dans quel module ou partie se trouvent stockées UUID et m@c, et ce sans en omettre aucun(e). On pourrait extraire tout et passer en revue les 1 après les autres les différents fichiers obtenus, mais ça risque d'être long, passablement fastidieux et assez ennuyeux.
Cependant, l'on a déjà une petite info: on sait que les infos recherchées se trouvent en début du fichier de dump ... en toute logique, ces mêmes infos devraient donc se trouver dans l'1 des toutes 1ères parties ou volumes recensés dans l'affichage précédent de la structure du BIOS par Phoenix Tool.
C'est le cas: dans le 2ème Padding affiché, il suffit de l'extraire, et de l'ouvrir avec 1 éditeur hexa pour s'en rendre compte.
Bingo!
On y est enfin. Ceci dit, il est fort possible que pour d'autres BIOSes, la structure soit différente, et donc les résultats différents de ceux présentés ici.
Pourquoi tout ce détour?
Déjà pour bien démontrer qu'il y a 1 problème sur tes PCs K53Sv/K52Jr qui n'ont pas l'UUID & la m@c ... tu me diras que je ne dis que ce que tu savais déjà. Certes, mais que je le dise ne me suffit pas, et il me faut toujours que j'essaye de prouver ce que j'avance, savoir pourquoi et comprendre.
Ensuite pour tenter de déterminer les raisons de ce problèmes et, si possible trouver une solution.
Les causes possibles selon moi:
- récupération des infos via SMBIOS corrompue?
- mauvaise programmation de la puce?
- mauvais flashage?
- détérioration d'1 autre composant suite au problème d'alim° défectueuse?
Ce que tu peux tenter:
- voir avec Intel FPT si, en créant 1 dump du BIOS de tes PCs, tu as plus de chance de récupérer les infos lisibles concernant l'UUID et la m@c qu'avec les autres logiciels déjà testés;
Et si OK, mais ça m'étonnerait, tenter la procédure DMIEdit for Aptio.
- récupérer une UUID d'1 autre PC et tenter la manip avec DMIEdit for Aptio.
Sache, qu'en faisant une petite recherche sur Google, tu peux trouver des UUID avec des m@cs valides (j'en ai déjà trouvé 4 sans me fatiguer trop).
Plus haut dans ton topic, tu proposais d'entrer l'UUID d'1 de tes K53Sv: juste une remarque, à ce sujet. Tu vas te retrouver avec 2 PCs ayant 2 adresses m@C identiques, ce n'est pas gênant outre mesure si le PC est directement connecté à Internet via 1 appareil qui ne sert que de passerelle, qui fonctionne en mode "bridge" donc, et que ton PC récupère une IP publique avec laquelle on peut naviguer sur le web.
Par contre, dans une configuration en mode routeur, en réseau privé donc, si tu as 2 PCs, avec les mêmes adresses m@cs, ça risque de poser de gros problèmes (justement d'identification des machines sur le réseau, et vraisemblablement de configuration & d'adressage IP voire tout simplement de connexion au réseau).
cf ce doc: On Duplicate MAC Addresses
Évidemment, en LAN, avec des PCs ayant 1 m@c différente, et même si le PC se connecte à Internet via 1 routeur, pas de problème non +, les m@c ne "traversant" pas les routeurs (cf MAC): dc, même si 1 PC possède la même adresse m@c à l'autre bout du monde, aucun souci à se faire ...
Petite précision: l'adresse m@c FF:FF:FF:FF:FF:FF est 1 adresse de diffusion broadcast qui sert, via une requête ARP, à identifier l'adresse m@c d'1 NIC spécifique appartenant à 1 réseau & possédant telle adresse IP bien précise: toutes les machines du réseau reçoivent & lisent alors la requête ARP, mais seule la machine avec l'adresse IP bien précise répond vua une réponse ARP, en unicast (càd adressée à la seule machine ayant fait la demande); du même coup, la machine de départ met à jour son cache ARP sous la forme IP@mac (XXX:XXX:XXX:XXX@YY:YY:YY:YY). Je te laisse imaginé ce qu'il peut advenir s'il y a 1 seule adresse m@c associée à 2 IPs différentes ... qui est qui?)
cf ici: ARP: A quoi tu sers?
Aussi, je te propose de te refiler l'UUID figurant sur la CM HS du X93SM dont il y a la photo en 1ère page.
Ou alors, 3ème possibilité, je modifie le BIOS v324 afin qu'il intègre l'UUID et la m@c: il ne restera plus qu'à flasher la machine ...
Déjà pour bien démontrer qu'il y a 1 problème sur tes PCs K53Sv/K52Jr qui n'ont pas l'UUID & la m@c ... tu me diras que je ne dis que ce que tu savais déjà. Certes, mais que je le dise ne me suffit pas, et il me faut toujours que j'essaye de prouver ce que j'avance, savoir pourquoi et comprendre.
Ensuite pour tenter de déterminer les raisons de ce problèmes et, si possible trouver une solution.
Les causes possibles selon moi:
- récupération des infos via SMBIOS corrompue?
- mauvaise programmation de la puce?
- mauvais flashage?
- détérioration d'1 autre composant suite au problème d'alim° défectueuse?
Ce que tu peux tenter:
- voir avec Intel FPT si, en créant 1 dump du BIOS de tes PCs, tu as plus de chance de récupérer les infos lisibles concernant l'UUID et la m@c qu'avec les autres logiciels déjà testés;
Et si OK, mais ça m'étonnerait, tenter la procédure DMIEdit for Aptio.
- récupérer une UUID d'1 autre PC et tenter la manip avec DMIEdit for Aptio.
Sache, qu'en faisant une petite recherche sur Google, tu peux trouver des UUID avec des m@cs valides (j'en ai déjà trouvé 4 sans me fatiguer trop).
Plus haut dans ton topic, tu proposais d'entrer l'UUID d'1 de tes K53Sv: juste une remarque, à ce sujet. Tu vas te retrouver avec 2 PCs ayant 2 adresses m@C identiques, ce n'est pas gênant outre mesure si le PC est directement connecté à Internet via 1 appareil qui ne sert que de passerelle, qui fonctionne en mode "bridge" donc, et que ton PC récupère une IP publique avec laquelle on peut naviguer sur le web.
Par contre, dans une configuration en mode routeur, en réseau privé donc, si tu as 2 PCs, avec les mêmes adresses m@cs, ça risque de poser de gros problèmes (justement d'identification des machines sur le réseau, et vraisemblablement de configuration & d'adressage IP voire tout simplement de connexion au réseau).
cf ce doc: On Duplicate MAC Addresses
Évidemment, en LAN, avec des PCs ayant 1 m@c différente, et même si le PC se connecte à Internet via 1 routeur, pas de problème non +, les m@c ne "traversant" pas les routeurs (cf MAC): dc, même si 1 PC possède la même adresse m@c à l'autre bout du monde, aucun souci à se faire ...
Petite précision: l'adresse m@c FF:FF:FF:FF:FF:FF est 1 adresse de diffusion broadcast qui sert, via une requête ARP, à identifier l'adresse m@c d'1 NIC spécifique appartenant à 1 réseau & possédant telle adresse IP bien précise: toutes les machines du réseau reçoivent & lisent alors la requête ARP, mais seule la machine avec l'adresse IP bien précise répond vua une réponse ARP, en unicast (càd adressée à la seule machine ayant fait la demande); du même coup, la machine de départ met à jour son cache ARP sous la forme IP@mac (XXX:XXX:XXX:XXX@YY:YY:YY:YY). Je te laisse imaginé ce qu'il peut advenir s'il y a 1 seule adresse m@c associée à 2 IPs différentes ... qui est qui?)
cf ici: ARP: A quoi tu sers?
Aussi, je te propose de te refiler l'UUID figurant sur la CM HS du X93SM dont il y a la photo en 1ère page.
Ou alors, 3ème possibilité, je modifie le BIOS v324 afin qu'il intègre l'UUID et la m@c: il ne restera plus qu'à flasher la machine ...
- Modèle
- Plusieurs machines ASUS (X66-52 -53-73, N61-53)
- Système
- Win 7
Chapeau bas maestro... Digne du Scottland Guard de BiosLand.... Docteur Wattson existant par ailleurs dans notre milieu, je t'accorderai plutôt le statut de Sherlock...
J'ai hâte de décortiquer mes dumps de BIOS afin de comparer ma lecture à la tienne...
Une fois mes manips tentées, je me déciderai. Mais je pressens déjà fortement qu'une reconstruction d'un Bios v324 avec ta défunte UUID et la M@C que je te donnerais en MP va remporter les suffrages... C'est vrai je tenterai un flash duX53SV avec moins d'appréhension si le dump vient d'un expert qui s'il était concocté par le newbie que je suis.
Pour le X52, il est parti en l'état, avec une régulation parallèle du fan par une sonde CTN sur le Heatpipe, ce qui ne marche pas mal du tout une fois le bon réglage trouvé. La personne n'était pas gênée par l'absence de LAN...
Je me plonge sur mon patient une fois nos invités disparus...
En tout cas, ces 5 pages sont un véritable trésor didactique... du lourd...
J'ai hâte de décortiquer mes dumps de BIOS afin de comparer ma lecture à la tienne...
Bien que j'ai lu quelque part qu'il y avait des applications "générateurs d'UUID", je retiens ta propositoin que je trouve plus... propre.
Pour l'adresse M@C, ne t'en fais pas, j'ai fini par la retrouver sur des stickers de la bête...
Une fois mes manips tentées, je me déciderai. Mais je pressens déjà fortement qu'une reconstruction d'un Bios v324 avec ta défunte UUID et la M@C que je te donnerais en MP va remporter les suffrages... C'est vrai je tenterai un flash duX53SV avec moins d'appréhension si le dump vient d'un expert qui s'il était concocté par le newbie que je suis.
Pour le X52, il est parti en l'état, avec une régulation parallèle du fan par une sonde CTN sur le Heatpipe, ce qui ne marche pas mal du tout une fois le bon réglage trouvé. La personne n'était pas gênée par l'absence de LAN...
Je me plonge sur mon patient une fois nos invités disparus...
En tout cas, ces 5 pages sont un véritable trésor didactique... du lourd...
OK, tiens-nous au courant de l'avancée
Bonne soirée
Bonne soirée
Re
Encore une chose:
- Si l'utilitaire Intel FPT permet de dumper les différentes régions de l'EPPROM, logiquement, il doit être possible à partir de là de reconstruire l'image complète de celle-ci, par simple "addition" dans l'ordre (Desc + ME + GBe + BIOS) des différents dump obtenus.
Je n'ai pas testé pour le moment, mais je compte bien le faire et voir ce que ça donne (une fois que j'aurais le matos à disposition). En tout cas, hypothétiquement, ce serait un bon moyen d'obtenir une sauvegarde intégrale du contenu intégral de l'EEPROM à 1 instant t... en vue d'1 reprogrammation future de celle-ci, hé hé ^^
PS: pour l'instant, j'ai juste reconstruit - je suppose- une image intégrale de l'EEPROM, par simple "addition" (copier-coller successif du contenu des différents dumps sauvegardés grâce à HxD Editor): comme on pouvait s'y attendre, j'obtiens en sortie 1 fichier de 8 Mo (8192 Ko (KB) de taille strictement égale donc à la puce SPI équipant le X55VD(R)!!).
- Sachez aussi, que cette suite d'outils Intel permet de flasher les régions ME et GBe vers une nouvelle version des FWs (et probablement vers 1 + ancienne)... à condition bien sûr de posséder parallèlement de l'image à flasher. Encore une fois, je n'ai pas testé & je n'ai pas de retour non plus sur la réussite de la manip.
Y a des "Oufs? des oufs m-alades?" dans l'assistance pour tester la chose??
Encore une chose:
- Si l'utilitaire Intel FPT permet de dumper les différentes régions de l'EPPROM, logiquement, il doit être possible à partir de là de reconstruire l'image complète de celle-ci, par simple "addition" dans l'ordre (Desc + ME + GBe + BIOS) des différents dump obtenus.
Je n'ai pas testé pour le moment, mais je compte bien le faire et voir ce que ça donne (une fois que j'aurais le matos à disposition). En tout cas, hypothétiquement, ce serait un bon moyen d'obtenir une sauvegarde intégrale du contenu intégral de l'EEPROM à 1 instant t... en vue d'1 reprogrammation future de celle-ci, hé hé ^^
PS: pour l'instant, j'ai juste reconstruit - je suppose- une image intégrale de l'EEPROM, par simple "addition" (copier-coller successif du contenu des différents dumps sauvegardés grâce à HxD Editor): comme on pouvait s'y attendre, j'obtiens en sortie 1 fichier de 8 Mo (8192 Ko (KB) de taille strictement égale donc à la puce SPI équipant le X55VD(R)!!).
- Sachez aussi, que cette suite d'outils Intel permet de flasher les régions ME et GBe vers une nouvelle version des FWs (et probablement vers 1 + ancienne)... à condition bien sûr de posséder parallèlement de l'image à flasher. Encore une fois, je n'ai pas testé & je n'ai pas de retour non plus sur la réussite de la manip.
Y a des "Oufs? des oufs m-alades?" dans l'assistance pour tester la chose??
hello JJ ,
j'ai vu ça: je te réponds demain et sur le topic ^^
,j'ai vu ça: je te réponds demain et sur le topic ^^
salut
tu permets que je recopie ton MP en partie:
parce que là, le programme dit tout bonnement que le processeur n'a pas les droits d'accès en lecture à la zone/région cible de l'EEPROM, et que pour activer les droits d'accès en lecture pour l’opération demandée, il faut modifier les paramètres Descriptor pour donner l'accès du CPU à cette région.
Que donne la commande:
Copie-colle le résultat ici.
et avec une version 7, c'est encore + précis:
Si l'outil FPT dans sa version que tu utilises ne supporté par ton chipset HM65, tu obtiendrais donc 1 message semblable à l'1 des 2 ci-dessus, en tout cas, très vraisemblablement 1 erreur 201, et pas 1 erreur 26 concernant l'impossibilité du CPU à accéder en lecture à certaine(s) zone(s) de l'EEPROM.
Mais je peux fournir 2 versions 7 différentes, si tu estimes que et si tu y tiens vraiment ^^.
Je recherche des infos sur cette erreur 26 ... ça me paraît très très louche cette erreur!
Autre chose: tu peux tenter de booter ton PC en PXE? Y t-il une m@c qui s'affiche et si oui, laquelle?
tu permets que je recopie ton MP en partie:
d'accord: mais pour quelle opération??
parce que là, le programme dit tout bonnement que le processeur n'a pas les droits d'accès en lecture à la zone/région cible de l'EEPROM, et que pour activer les droits d'accès en lecture pour l’opération demandée, il faut modifier les paramètres Descriptor pour donner l'accès du CPU à cette région.
Que donne la commande:
Code:
fptw64 -Ije ne crois pas, d'après mon expérience de l'outil: je déduis ça des messages d'erreur que j'ai eu en exécutant diverses versions de l'outil FPT sur mon M70Vn (ICH9-M); quand la plateforme n'est pas supportée, c'est 1 tout autre message qui est affiché en sortie, comme je l'ai déjà précisé plus haut:
et avec une version 7, c'est encore + précis:
Si l'outil FPT dans sa version que tu utilises ne supporté par ton chipset HM65, tu obtiendrais donc 1 message semblable à l'1 des 2 ci-dessus, en tout cas, très vraisemblablement 1 erreur 201, et pas 1 erreur 26 concernant l'impossibilité du CPU à accéder en lecture à certaine(s) zone(s) de l'EEPROM.
Mais je peux fournir 2 versions 7 différentes, si tu estimes que et si tu y tiens vraiment ^^.
Je recherche des infos sur cette erreur 26 ... ça me paraît très très louche cette erreur!
c'est celle que tu m'as donné en MP?? c'est bien celle du K3SV +/- bancal?
Autre chose: tu peux tenter de booter ton PC en PXE? Y t-il une m@c qui s'affiche et si oui, laquelle?
re,
aussi, as-tu essaye FPT sur le K53SV qui est OK?
aussi, as-tu essaye FPT sur le K53SV qui est OK?
- Modèle
- Plusieurs machines ASUS (X66-52 -53-73, N61-53)
- Système
- Win 7
Salut,
voici donc mes réponses
Voici le retour de la commande -I :
C:\FPT Winx64 v8>fptw64 -i
Intel (R) Flash Programming Tool. Version: 8.0.10.1464
Copyright (c) 2007 - 2012, Intel Corporation. All rights reserved.
Platform: Intel(R) HM65 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid
--- Flash Devices Found ---
MX25L3205D ID:0xC22016 Size: 4096KB (32768Kb)
--- Flash Image Information --
Signature: VALID
Number of Flash Components: 1
Component 1 - 4096KB (32768Kb)
Regions:
Descriptor - Base: 0x000000, Limit: 0x000FFF
BIOS - Base: 0x180000, Limit: 0x3FFFFF
ME - Base: 0x001000, Limit: 0x17FFFF
GbE - Not present
PDR - Not present
Master Region Access:
CPU/BIOS - ID: 0x0000, Read: 0x0B, Write: 0x0A
ME - ID: 0x0000, Read: 0x0D, Write: 0x0C
GbE - ID: 0x0118, Read: 0x08, Write: 0x08
Total Accessable SPI Memory: 4096KB, Total Installed SPI Memory : 4096KB
FPT Operation Passed
C:\FPT Winx64 v8>
voici donc mes réponses
Tout simplement fptw64 -d + nom de fichier
Voici le retour de la commande -I :
C:\FPT Winx64 v8>fptw64 -i
Intel (R) Flash Programming Tool. Version: 8.0.10.1464
Copyright (c) 2007 - 2012, Intel Corporation. All rights reserved.
Platform: Intel(R) HM65 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid
--- Flash Devices Found ---
MX25L3205D ID:0xC22016 Size: 4096KB (32768Kb)
--- Flash Image Information --
Signature: VALID
Number of Flash Components: 1
Component 1 - 4096KB (32768Kb)
Regions:
Descriptor - Base: 0x000000, Limit: 0x000FFF
BIOS - Base: 0x180000, Limit: 0x3FFFFF
ME - Base: 0x001000, Limit: 0x17FFFF
GbE - Not present
PDR - Not present
Master Region Access:
CPU/BIOS - ID: 0x0000, Read: 0x0B, Write: 0x0A
ME - ID: 0x0000, Read: 0x0D, Write: 0x0C
GbE - ID: 0x0118, Read: 0x08, Write: 0x08
Total Accessable SPI Memory: 4096KB, Total Installed SPI Memory : 4096KB
FPT Operation Passed
C:\FPT Winx64 v8>
Oui oui, tout à fait.
- Modèle
- Plusieurs machines ASUS (X66-52 -53-73, N61-53)
- Système
- Win 7
Hélas non, il est parti... Mais j'ai ici jusqu'à ce soir un X73E (CM totalement différente, mais qui a le même chipset HM65).
Voici ce que ça donne (en fait strictement la même chose en -i et en -d que sur le X53) :
Microsoft Windows [version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tous droits réservés.
C:\Windows\system32>cd /
C:\>cd fpt winx64 v8
C:\FPT Winx64 v8>
C:\FPT Winx64 v8>fptw64 -d X73E.rom
Intel (R) Flash Programming Tool. Version: 8.0.10.1464
Copyright (c) 2007 - 2012, Intel Corporation. All rights reserved.
Platform: Intel(R) HM65 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid
--- Flash Devices Found ---
W25Q32BV ID:0xEF4016 Size: 4096KB (32768Kb)
Error 26: The host CPU does not have access to the target flash area. To enable read access for this operation you must modify the descriptor settings to give host access to this region.
C:\FPT Winx64 v8>
ok
le retour de la commande
prouve bien que l'utilitaire est OK sur ta plateforme HM65
sur la sortie: tout semble correct... come c'est précisé
ce n'est pas parce que que renvoie qu'il n'y a pas de région GBe (que tu as mis en gras dans ta citation) que ça pose 1 problème:
car, si ton chipset HM65 n'a pas de carte LAN GBe intégrée ... alors logiquement, il ne doit pas y avoir non + de région GBe ^^
or, d'après la doc Inel sur le HM65: Mobile Intel® HM65 Express Chipset et: Datasheet HM65
seuls certains modèles (SKUs) ce chipset intègrent cette carte; il est fort possible que le tien non.
Pour la région PDR non présente, c'est aussi le cas sur le X55VD(R) [cf. + haut]
En tout cas, si tu te réfères à ce que j'ai dit ici: https://www.forum-des-portables-asus.fr/forums/index.php?threads/x53sv-ethernet-realtek-ne-peut-pas-démarrer.8687/page-2#post-71494
par comparaison avec 1 dump de l'EEPROM réalisé sur 1 autre K53SV, tu vois que dans ton rapport effectué par FPT, les tailles des différentes régions correspondent bien:
pour la commande:
que tu as effectué, elle réalise la sauvegarde intégrale de toute l'EEPROM ^^
Elle fonctionne parfaitement bien sur le X55VD(R) que je possède:
Pour déterminer, quelle est la région de l'EEPROM qui pose des soucis d'accès en lecture sur ton K53SV, il faut exécuter, 1 à 1, les commandes suivantes:
et voir laquelle est en erreur.
De toute façon, d'1 façon générale, si pas possible de lire, d’accéder simplement en lecture quoi que se soit (fichier, dossier, etc. ), ça signifie tout bonnement qu'il n'y a pas les autorisations requises et/ou que quelque chose est verrouillé/locké.
Vu sur l'Intel Community, ici:
de toute façon normalement ça devrait t'afficher la m@c, 1 truc dans le genre:
le retour de la commande
Code:
fptw64 -isur la sortie: tout semble correct... come c'est précisé
ce n'est pas parce que que renvoie qu'il n'y a pas de région GBe (que tu as mis en gras dans ta citation) que ça pose 1 problème:
car, si ton chipset HM65 n'a pas de carte LAN GBe intégrée ... alors logiquement, il ne doit pas y avoir non + de région GBe ^^
or, d'après la doc Inel sur le HM65: Mobile Intel® HM65 Express Chipset et: Datasheet HM65
seuls certains modèles (SKUs) ce chipset intègrent cette carte; il est fort possible que le tien non.
Pour la région PDR non présente, c'est aussi le cas sur le X55VD(R) [cf. + haut]
En tout cas, si tu te réfères à ce que j'ai dit ici: https://www.forum-des-portables-asus.fr/forums/index.php?threads/x53sv-ethernet-realtek-ne-peut-pas-démarrer.8687/page-2#post-71494
par comparaison avec 1 dump de l'EEPROM réalisé sur 1 autre K53SV, tu vois que dans ton rapport effectué par FPT, les tailles des différentes régions correspondent bien:
Donc, que les régions GBe et PDR manquent à l'appel n'est pas le souci AMHO.
pour la commande:
Code:
fptw64 -DElle fonctionne parfaitement bien sur le X55VD(R) que je possède:
Pour déterminer, quelle est la région de l'EEPROM qui pose des soucis d'accès en lecture sur ton K53SV, il faut exécuter, 1 à 1, les commandes suivantes:
Code:
fptw64 -DESC -D xxxx.rom
fptw64 -ME -D yyyy.rom
fptw64 -BIOS -D zzzz.romDe toute façon, d'1 façon générale, si pas possible de lire, d’accéder simplement en lecture quoi que se soit (fichier, dossier, etc. ), ça signifie tout bonnement qu'il n'y a pas les autorisations requises et/ou que quelque chose est verrouillé/locké.
Vu sur l'Intel Community, ici:
Voici ce que donne le boot en PXE :
tu as testé avec 1 câble ETH connecté (des 2 côtés)??
de toute façon normalement ça devrait t'afficher la m@c, 1 truc dans le genre:
non, pas vraiment, car ce n'est pas adéquatement comparable -- mais rien ne t'empêche de tester tout de même, si tu veux t'assurer par toi-même que ce n'est pas 1 pb du programmes
0 membres ont lus ce sujet. Plus d'infos
-
Membres en ligne
Aucun membre en ligne maintenant. -
Bon anniversaire
-
Statistiques du forum
Vos pièces détachées officielles Asus
Soutenir le support et les forums
Soutenir les forums Asus
Objectif
Collecté
Cette campagne s'achève dans
