[L3C] Difficultés d'accès au contenu d'une EEPROM série avec Bus Pirate

[milediou]

Avant de passer au dépannage d'une autre carte mère, j'ai souhaité me faire la main sur un modèle que je connais bien (le L3C - 2002) et qui fonctionne, le but étant ici de réaliser un dump de mon Bios actuel.

Je passe sur les étapes de démontage (sans intéret ici, le sujet visant un public averti). Une fois la carte mère démontée, il s'agit de repérer l'EEPROM qui nous intéresse, ici une IS93C46 - 3GR dont le datasheet est téléchargeable sur ce lien >> https://www.alldatasheet.com/datasheet-pdf/pdf/104311/ISSI/IS93C46-3GR.html

L'EEPROM se situe prés du chip Realtek

La liaison physique avec l'EEPROM sera réalisée au moyen d'une pince Pomona et d'un câble Bus Pirate 10 fils (raccourci de 20cm à 10cm pour cette utilisation >> fiabilisation du transfert de données).

Seuls six fils seront connectés ici :
(EEPROM ) CS pin 1> CS (BP)
(EEPROM ) SK pin2 > CLK (BP)
(EEPROM ) DIN pin 3 > MOSI (BP)
(EEPROM ) DOUT pin4 > MISO (BP)
(EEPROM ) VCC pin 8 > +3.3V (BP)
(EEPROM ) GND pin 5 > GND (BP)

La liaison avec le PC ( un Eeepc 1001PX) se fait avec câble USB relié au Bus Pirate (ici en version V3b)

La communication avec le Bus Pirate se fait sans problèmes avec minicom sous ubuntu 12.04LTS. Je précise au passage que le BP a passé le self-test avec succès.

Lorsque je lance la procédure d'identification avec flashrom (compilé moi même version 0.9.7) voici ce que j'obtiens

La procédure se stoppe sur le message suivant ' Calibrating delay loop.....OK' puis plus rien

J'ai remarqué que la diode VREG du BP ne s'allume pas donc j'ai creusé dans cette direction.
Sous minicom, j'ai paramétré le BP en mode SPI, puis j'ai lancé la mise sous tension avec 'W' . Voici ce que j'obtiens :

Un message d'erreur ' VREG tool low, is there a short ? ' et la sanction ' Power supplies OFF' !

So what ?? Dois-je comprendre qu'un composant de la carte mére joue les troubles-fêtes ?

 

[Asusien déchu]

hello milediou

la CM du L3C est fonctionnelle?
as-tu les schémas de la CM?
as-tu upgradé le FW du BP?

aussi, j'l'ai pas dit dans mes topics, mais mon BP est connecté en USB sur mon PC via 1 double câble USB (dc connecté sur 2 ports USB)

 

[Asusien déchu]

hello, en regardant la datasheet de la puce SPI et les schémas de la CM du L3C,
je viens de me rendre compte que les pins ne sont pas disposés identiquement!!

disposition standard des pins de la puce SPI IS93C46 - 3GR:

je suppose que tu as utilisé le 1ère config°

disposition des pins de la puce SPI IS93C46 - 3GR sur la CM du L3C:

par rapport à tes branchements ça change tout! ce qui pourrait très bien expliqué ce VREG low! (pas assez de jus)

schémas du L3C:
https://rapidgator.net/file/b9c47ca082582003a99bef25842cde16/scheme-asus-l3c_r33_mfg.pdf.html

 

[milediou]

Salut phil', je me doutais bien que tu allais passer par là

disposition des pins de la puce SPI IS93C46 - 3GR sur la CM du L3C:

par rapport à tes branchements ça change tout! ce qui pourrait très bien expliqué ce VREG low! (pas assez de jus)

schémas du L3C:
https://rapidgator.net/file/b9c47ca082582003a99bef25842cde16/scheme-asus-l3c_r33_mfg.pdf.html

J'avais bien compulsé les schémas avant de commencer et cette disposition m'avait quelque peu interpellé, surtout après avoir étudié le datasheet d'autres EEPROM, winbond not'.
Après réflexion, j'en avais déduit que l'on ne peut se fier à cette 'disposition géographique' des pins. Si tu regardes bien, les ingés Asus ont reporté les numéros des pins sur le schéma et cela correspond en tout point avec le datasheet de la puce. Je crois qu'ils ont pris quelques libertés au niveau de la schématisation, voilà tout. De plus le point sur l'enveloppe du composant semble toujours indiquer le pin CS (Chip Select).

la CM du L3C est fonctionnelle? as-tu les schémas de la CM? as-tu upgradé le FW du BP?

Oui / Oui et Non . J'ai le firmware d'origine.

HiZ>i											 
Bus Pirate v3b									
Firmware v5.10 (r559)  Bootloader v4.4			
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)		
https://dangerousprototypes.com

Tu as fais l'upgrade sous linux ou windows ? Et parce que tu as rencontré des soucis avec le précèdent ou par principe ?

aussi, j'l'ai pas dit dans mes topics, mais mon BP est connecté en USB sur mon PC via 1 double câble USB (dc connecté sur 2 ports USB)

Cette indication me semble intéressante mais du coup il va falloir que je change de machine car mon câble double est un peu court pour l'Eeepc qui a ses ports USB de part et d'autre du bottom case. A moins que je ne trouve une rallonge...Je regarde ça

 

[milediou]

Cette indication me semble intéressante mais du coup il va falloir que je change de machine car mon câble double est un peu court pour l'Eeepc qui a ses ports USB de part et d'autre du bottom case. A moins que je ne trouve une rallonge...Je regarde ça

Bon, pas de changement sur l'Eeepc relié au secteur et avec câble double rallongé. Même sanction.
Je passe sur M50vn / Wheezy pour test.

Note que la tension est correcte (3,37V) dès que je déconnecte le Pomona de l'EEPROM.

 

[Asusien déchu]

re,

moi, j'te dis, tes connections pins à pins ne sont pas correctes ...

 

[milediou]

J'ai fait un essai en revoyant le plan de câblage sans trop de conviction mais par acquis de conscience..
Le témoin VREG s'allume uniquement lorsque je pilote manuellement le BP en mode SPI (commande W). La procédure de détection de l'EEPROM par flashrom n'aboutit pas davantage et cette diode VREG reste éteinte...
Mon analyse est que dans le premier cas (branchement initial relatif au datasheet), j'alimente la carte mère via le Bus Pirate et le pin VCC. Cette 'fuite' d'énergie détectée par le BP engendre un message d'erreur et l'arrêt de l'alimentation VREG. C'est tout le problème d'intervenir sur un composant encore relié à la carte mère...
Dans le second cas (branchement que tu suggères), le 3,3V du BP étant relié au pin 7 de l'EEPROM (non relié électriquement à la carte mère), il n'y a pas de consommation de courant et donc la mise en tension VREG ne pose pas de pb. Mais comme l'EEPROM n'est pas alimentée en Vcc, aucune lecture/écriture n'est possible.
Bon, je fais peut-être erreur mais voilà mes hypothèses pour le moment.

Tu as fais l'upgrade sous linux ou windows ? Et parce que tu as rencontré des soucis avec le précèdent ou par principe ?

des infos concernant la mise à jour du firmware de BP ?

 

[milediou]

Upgrade completed !

# minicom -s
 
Bienvenue avec minicom 2.4										   
																	 
OPTIONS: I18n															   
Compilé le Sep  5 2010, 09:23:03.										   
Port /dev/ttyUSB1														   
																		   
Tapez CTRL-A Z pour voir l'aide concernant les touches spéciales		   
																		   
																		   
HiZ>AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0									   
AUX HIGH																   
Syntax error at char 2													 
HiZ>~																	   
Disconnect any devices											   
Connect (Vpu to +5V) and (ADC to +3.3V)							   
Space to continue													 
Ctrl																 
AUX OK															   
MODE LED OK														   
PULLUP H OK														   
PULLUP L OK														   
VREG OK
ADC and supply																 
5V(4.98) OK																   
VPU(4.96) OK																   
3.3V(3.22) OK																 
ADC(3.19) OK																   
Bus high																	   
MOSI OK																	   
CLK OK																		 
MISO OK																	   
CS OK																		 
Bus Hi-Z 0																	 
MOSI OK																	   
CLK OK																		 
MISO OK																	   
CS OK																		 
Bus Hi-Z 1																	 
MOSI OK																	   
CLK OK																		 
MISO OK																	   
CS OK																		 
MODE and VREG LEDs should be on!											   
Any key to exit															   
Found 0 errors. 
															 
HiZ>i																		 
Bus Pirate v3.5															  
Firmware v6.1 r1676  Bootloader v4.4										
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)									 
https://dangerousprototypes.com												 
HiZ>

Je poursuis les tests un peu plus tard...

 

[Asusien déchu]

re,

bin, je ne sais quoi te dire de + alors ...

Dois-je comprendre qu'un composant de la carte mére joue les troubles-fêtes ?

j'me demande si:

ce composant (c'est 1 condensateur non?) n'en serait pas la cause???

 

[milediou]

ce composant (c'est 1 condensateur non?) n'en serait pas la cause???

Tu parles du condo C137 ? Une fois chargé ce condensateur n'a plus lieu de perturber le montage. Je crois que le problème vient de tout ce qui est relié au 3V de la carte mère.

Une solution serait de mettre la carte mère sous tension comme l'indique Sjaak ici >> https://dangerousprototypes.com/forum/viewtopic.php?f=4&t=2512&p=24296&hilit=reset+cpu#p24296

...The second best thing is to power the board, and hold the cpu in reset and read the chip (assuming the data and clock lines aren't held low).

J'ai par contre du mal à saisir ce qu'il entend par 'maintenir le cpu en reset'...

 

[Asusien déchu]

j'me doutais 1 peu que le condo ne perturbait pas le machin, juste 1 hypothèse jetée comme cela, mais je voulais que tu me confirmes

je vais lire la topic de Sjaak voir ce qu'il dit ...

...The second best thing is to power the board, and hold the cpu in reset and read the chip (assuming the data and clock lines aren't held low).

ça fait beaucoup de chose qui compliquent la vie là, juste pour lire la puce ^^

J'ai par contre du mal à saisir ce qu'il entend par 'maintenir le cpu en reset'...

pour ça, il me semble qu'il faille lire la datasheet du CPU en question
a priori, de ce que je comprends, ça reviendrait à empêcher le CPU d'aller à l'adresse par défaut pour y lire la 1ère instruction à exécuter
https://en.wikipedia.org/wiki/Reset_vector
https://newlifegames.net/nlg/index.php?topic=19.0;wap2
cf aussi What Happens When A CPU Starts
... ce qui me semblerait logique, car je pense que l'1 des 1ères choses que la CPU va chercher à exécuter, c'est le code du BIOS lui-même, non?

Après, s'il faut agir sur le pin RESET du CPU (comment? de quelle façon?), ça va être coton ... mais par exemple, je sais que certains bricoleurs sont arrivés à agir sur les pins BSEL de certains CPU afin de les OC matériellement
cf: https://www.overclock.net/t/341123/intel-bsel-vid-mod-guide

Dans mon cas, je vois que pour les Core 2 Duo du type de mon T9900, il y a bien 1 pin RESET, juste à l'endroit du détrompeur d'insertion du CPU dans le socket:

mais pour info:
J'ai récupéré le R900VM, les 2 X93SM (le mien et celui de doublle14), le K73S de marsupilmai54 avec les CPU installés, mais sans mettre les CM sous tension
J'ai pu lire la puce des CMs M70VN sans CPU ni sans mettre les CMs sous tension

As-tu essayé de lire la puce de la CM du M50SV?

 

[milediou]

As-tu essayé de lire la puce de la CM du M50SV?

Non. Pour l'heure je déssoude l'EEPROM du X57V HS pour voir ce que je peux en tirer...

 

[Asusien déchu]

ok

et pour le reste tu abandonnes la piste de Sjaak? ou tu as simplement abandonné pour le L3C?

bon en même temps Sjaak ne dit pas grand chose, ... enfin pour moi ça aide pas.

 

[milediou]

et pour le reste tu abandonnes la piste de Sjaak?

Non, je me le mets juste derrière l'oreille pour le moment.
J'ai besoin de tester le bus pirate dans un cas simple pour commencer. Je pensais que le L3c serait un cas d'école mais non...

 

[milediou]

Bon je reviens par ici car j'ai compris un certain nombre de chose depuis cet échec.
Disons que j'ai zappé un fait important : j'ai voulu faire un dump de Bios sur un portable de 2003 et ici pas de puce spi SOIC-8 mais un autre format : PLCC

Donc d'entrée de jeu, je suis parti sur le mauvais composant. De plus point d'IS93C46 - 3GR supporté par flashrom. Donc voilà deux raisons qui expliquent toutes les difficultés évoquées plus haut..

Le Bus pirate ne permettant pas (sauf erreur de ma part) de prendre le contrôle d'une SST 49LF002A au format PLCC32 et selon un protocole FWH (Firmware Hub ) , je vais laisser tomber et me concentrer sur des puces SPI plus récentes.

 

[zrodia]

ça bosse dur a ce que je vois