xvassor

Bonjour Tout le Monde,

Je constate qu'avec l'arrivée du RGH2, tous nos problèmes de stabilité du RGH reviennent au galop.

Pour le RGH2 (donc que pour les PHAT) nous devons câbler nos CPLD à la sauce RGH1 version SLIM mais chose bizarre
nous utilisons pas les mêmes composants externes (condo/résistance) lors du câblage.

Je suis pas un expert en électronique mais il y a surement une raison, la CM des PHAT ne doit pas utiliser les mêmes valeurs de tension que celle des SLIM
sinon je ne comprendrais pas le coup de la résitance de 10 ohms qui n'existe pas sur le montage SLIM RGH1.
=> SI vous connaissez les valeurs des tension/courant des signaux qui sont utilises par le HACK je suis preneur ...

Pour revenir au hack RGH1 il y a un truc que je n'ai pas bien compris.
- Pour SLIM on relie VCCIO1 sur VCCINT le tout relié au 1,8V qui provient du régulateur (LDO) de 1,8V/150ma interne au CPLD (vu sur 2 versions de CoolRunner non TX)
- Pour PHAT on doit utiliser une tension pour VCCIO1 < VCCINT pour que le FPGA arrive a bien décoder les infos (1 logique) qui arrive sur OUT_POST1.
-> Certains utilise le 1,8V qui provient de la CM en directe pour VCCIO1
-> Certains utilise le 3.3V du CPLD - la tension de 3 diodes pour obtenir un 3,3V-3x0,7V=1,2V
-> Certains utilise le 1.8V de VCCINT - la tension d'une diode soit 1,8V-0,7V=1,1V
(note: La tension d'une diode peut varier de 0,6V a 0,7V donc ça peut varier de quelques 0,1V)

Pourquoi car un niveau logique '1' vu sur POST_OUT doit être environs égale à 70% de VCCINT (si je confond pas avec VCCIO1) soit 70% de 1,8V = 1,26V (donc une tension >= 1,26V sera vu comme un '1' logique)
Peut etre qu'un meilleur seuil serait de 80% ?

Corrigez moi si je me trompe

De plus le signal CPU_RST que l'on va envoyer depuis le CPLD doit être de 1,1V pour être compatible avec le niveau logique des tensions des signaux de la CM.
=> Donc il faut bien régler ce fameux VCCIO1
Je n'ai pas regardé le code VHDL du FPGA mais il doit surement y avoir des résistances internes pour faire chuter cette tension de sortie au niveau de l'IO)

1ere question:
Pourquoi doit on faire cette modif sur PHAT et pas sur SLIM (pour RGH v1.1) ?
=> car les tensions de la carte SLIM sont plus élevés ?

2eme question:
En modifiant nos CPLD RGH1 pour faire du RGH2 on câble bien le montage SLIM (utilisation de SDA &amp; SCL mais plus de CPU_PLL_BYPASS) mais ne doit pas conserver le mechanisme de VCCIO1 < VCCINT sur nos CPLD aussi pour le RGH2 ?
=> Je pense que OUI c'est pourquoi nous avons pas beaucoup de retour positif ...
car ce fameux VCCIO1 est surement mal réglé !

Certains vendeur de CPLD préconise de régler VCCIO1 à 1,65V pour avoir une temps de boot de 5s sur RGH2
=> La réponse est peut être déjà donnée ?
note: 1,65V donne un seuil d'environs 92%
Plus le seuil est haut plus on va filtrer les parasites sur POST_OUT1 mais si le signal est trop faible on va rien voir non plus !

Sur RGH2, la résistance de 10 ohms pour moi ne sert qu'a limiter la sortie du courant sortant de l'IO pour protéger la CM qui doit avoir un courant plus faible (supposition).
Donc avec ou sans cette résistance ça ne doit pas changer la donne,
de plus cette valeur doit être propre à la CoolRunner de TX (propre a leur régulateur de 1,8v)
donc pas forcement bonne pour toutes les autres cartes à voir ....

Chez moi j'ai mesuré ces valeurs pour une RGH v1.1 sur PHAT de type falcon qui boot en 5s
avec VCCIO1=1,8V provenant de la CM (je ne suis plus sur de la valeur: entre [1,78-1,81]V)
et son cable d'alimentation toujours branché:

POST_OUT1:
Power OFF = 0V
Power ON = 1,14V
Au moment du Glitch = 0,9V (ca doit descendre plus bas mais au multimetre ca a tendance a moyenner la valeur)
Xell qui s'affiche = 1,14V

STBY_CLK = clock 48Mhz = tension de 1,75V tout le temps

CPU_RST:
Power OFF = 0V
Power ON = 1,15V
Glitch = mesure impossible a faire avec le multimetre mais ca doit surement tendre vers 0V
Xell qui s'affiche = 1,15V

d’après mes lectures CPU_RST doit être de 1,1V donc ma valeur semble cohérente ...

Merci pour vos lumières et si vous avez d'autres valeurs de tension je suis preneur...

Bonjour,

Mon Problème est dans le titre !

J'ai réalisé le Hack RGL sur une Falcon (16MO).
J'ai fais 3 dumps identiques qui ont chacun 2 bad blocks:
Error Lecture NandPro - Block - remap to
25C DD 3FF
250 245 3FE

J'ai Flashé le Xell
J'arrive bien a booter sur le Xell via Eject en moins de 5 secondes.
J'obtiens bien ma clef CPU: 6EF1A809FD5897C64798479561D97F71

Voici l'image de ma nand avec ses 2 bad Blocks:
http://dl.free.fr/mXk5SnxnJ

J'ai utilisé construit mon Freeboot 13604 (car je ne veut pas de la version METRO)
via 360_Multi_Builder_v0.921 en utilisant ma nand d'origine avec ses Bad Blocks
XeBuild detecte bien les Bad Blocks et les remap a la fin

voir le log:
------ finalizing image ------
Fixing up empty FS block entries...done!
Writing FS table to image...done!
calculating ECD bytes and assembling raw image...done!
remapping 2 blocks
copying 0x4200 bytes of LBA 0xdd to block 0x3ff...zero fill origin...done!
copying 0x4200 bytes of LBA 0x245 to block 0x3fe...zero fill origin...done!
done!
writing file 'nandflash.bin' to disk...done!
nandflash.bin written OK

J'ai flashe le tout via rawFlash V4 (qui lui sait aussi remapper)
Mais quand je demarre via le bouton on/off
J'ai bien les 4 leds de la manette filaire qui s'allume mais je n'ai que la led verte centrale qui clignote a l'infinie ...
pas de demarrage du dashboard !

Vu que rawFlash fais du remapping je me suis dit que peut etre il cassait le remapping de XeBuild
donc j'ai refais une nand origine sans bad block + refais mon freeboot + flash via rawflash v4
et toujours meme resultat !

la je seche ....
j'ai remis ma nand d'origine coupé le 3.3v et le 1.8v du cpld en esperant que ca suffit pour desactiver le glitch
et la ma nand d'origine ne boot plus, meme symptome, 1 led verte central qui clignote
(peut etre qu'il faut tout dessouder pour ne pas parasiter un boot d'origine ?)

je part du principe que si le Xell boot bien c'est que la console est OK (j'arrive a lancer un emulateur donc ca marche bien)

J'ai aussi fais le coup du:
- LDV+1 (en gardant le meme PD) + freebot + flash => marche pas
- refaire une nand retail a partir de ma nand clean + freeboot + flash => marche pas

Bref je seche completement:
pour le LDV qui est de 14 je pense qu'il est bon car j'ai bien 14 fois 'F' sur la fuseset 07
donc le coup du LDV+1 je ni crois pas.


J'ai aussi essayer de faire mon freeboot via xeBuild-GUI v2.04 , mais pareille vace nand d'origine avec BB ou sans BB je n'arrive pas a faire booter le NXE

J'ai lu aussi que ca pouvait venir du signal STBY_CLK (c3b2 moi j'utilise le point alternatif FT2R2)
mais j'y crois pas trop non plus vu que je boot bien sur le Xell en moins de 5s ce qui est le plus rapide ...

J'ai aussi pensé que ma nand etait corrompue donc j'ai essaye d'extraire les fichiers de la nand via 360 flash tool mais vu qu'il plante sur la partie des fichiers kernels
sur des nand Ok ou NONje ne peux rien dire de plus.

J'ai aussi injecte mon KV et Config dans une autre nand + mise a jour du LDV + build freeboot + rawflash => marche pas !

La je n'ai plus aucune piste ......


Merci pour votre aide