Visualizzazione Stampabile
Beh in realtà dà parecchi problemi...però alemno su nand si riesce a far funzionare. Su NOR è impossibile scrivere per ora (e comunque c'è sempre l'ottimo Teensy in alternativa).Citazione:
Originariamente Scritto da Mauroz
La 1.1 non è più in commercio...quindi.
X guerrierodipace
Ma ora con questi ottimi risultati come posso procedere anche io? Con progskeet 1.2 e con clip 360 su ps3 dual nand?
non ho la clip mi spiaceCitazione:
Originariamente Scritto da enzoenzo
Ma questo bel oggettino lo vendi?
quale dici ? Grisù? :DCitazione:
Originariamente Scritto da enzoenzo
No lo zif ho solo quello,se cerchi "TSOP48 zif" lo trovi e non costa pochissimo.
carissimi qualcuno ha esperienza di clip 360 e progskeet 1.2?
Forse ho un progskeet 1.2 difettoso
x capire se può essere difettoso devi gardare qua [url=http://www.ps3devwiki.com/wiki/Progskeet_1.2#Detection_issue]Progskeet 1.2 - PS3 Development Wiki[/url]Citazione:
Originariamente Scritto da enzoenzo
e in winskeet se funziona il test dei corti
Ecco qui di seguito i. corto circuiti trovati su progskeet1.2 chi mi può aiutare?
Non sono riuscito ad inviare la foto però ve riporto qui :
Da dq1 a dq15. E da gpo a gp15.
Secondo voi sono corretti? Io non ho trovato la descrizione x verificarli
aspetto per sapere se il mio progskeet ha difetti di fabbricazione
Lascia stare i corti per il 1.2, non è affidabile secondo me.
Inviato dal mio GT-I8150 con Tapatalk 2
Come promesso vi riporto la mia esperienza. Premetto che ora sono da cellulare, quindi se mi dimentico qualcosa chiedete pure e integrerò.
- Bitstream 1223, cioè il penultimo.
- Ps3 phat 60gb, mobo cok002, dual nand samsung.
- Nand dissaldate e montate su zif socket tsop48.
- Alimentazione da progskeet.
- R7 tenuto chiuso come di default e R8 tenuto aperto come di default.
- Nessun pull up aggiuntivo, unica cosa differente, ho impiegato un flat schermato lungo la metà di quello in dotazione, 200mm anziché il classico da 400mm. Lo potete trovare sul connettore delle SD reader all'interno delle phat 60gb (non so se anche sugli altri modelli).
- Delay settato di default a 50us. Se lo imposto a 200us come da tutorial di Titty, mi si blocca dopo pochi blocchi letti.
- Dump eseguiti su entrambe le nand, comparati e tutto ok.
- Li ho poi uniti e verificati in tutto e per tutto, non solo per quanto riguarda le statistiche, ma anche per i magic byte (faceoff, deadbeef, ecc) e tutto il resto, metldr, bootloader, revokations e chi più ha più ne metta. :)
- Verificato al momento della unione dei dump con flowrebuilder che venissero estratti e creati tutti i file, dal bootloader, ai ros, asecure loader, ecc., tutto nella norma.
- Procedo al patch e alla divisione dei file da andare a riscrivere nelle nand, tutto ok.
- Flasho la prima nand e poi rieseguo un dump per verificare se ciò che ho scritto corrisponde a ciò che poi ho letto, tutto ok, quindi posso dire al 99,9% che la prima nand è ok e correttamente downgradata.
- Passo alla seconda nand tutto bello gongolante, flash della nand ok, ma poi quando vado a ridumpare non combacia mai.
Ora sono bloccato alla impossibilità di far corrispondere il flash con il successivo dump della seconda nand. Pensando ad un caso che con la prima fosse filato tutto liscio, faccio un erase della nand e poi riflasho e ridumpo, tutto ok!
Quindi ho proprio problemi con la seconda delle due nand, anche se non capisco il motivo, visto che sono uguali!
Inviato dal mio GT-I8150 con Tapatalk 2
Rettifico in parte quello che ho scritto nel post precedente. I dump sono validi, di questo sono sicuro, per cui suppongo che la lettura funzioni bene. Il problema è che mi sono accorto che nemmeno la prima nand è stata scritta correttamente. Ho provato anche a flashare l'ultimo bitstream, il 2121, ma non ho riscontrato differenze, anche se ho la netta sensazione che sia più indicato il 1223...
Ora proverò ad alimentare con alimentazione esterna, vediamo se cambia qualcosa e se la scrittura va a buon fine.
forse è una cosa stupida ma hai provato a schermare quello originale e ha provare a scrivere?
se la lettura avviene senza errori credo sia un errore di comunicazione nella scrittura quindi le informazioni che passano sul flat durante la scrittura o vengono trasmessi troppo velocemente o troppo lentamente.
prova ad aumentare e a diminuire il tempo delle comunicazioni.
sono sciochezze ma le cose piu stupide a volte si rilevano quelle esatte.
OT
forse dirò una cosa stupida
sulle nuove 4xxx che hanno il metld2 e OFW>3.55 non è possibile fare nulla ma se invece facessimo in questo modo?
1)modifichiamo il backup della flash per il downgrade 3.55
2)dissaldiamo la flash della ps3
3) prendiamo una nuova flash e la scriviamo con il backup modificato
4)la saldiamo al posto della vecchia
5)eseguiamo la procedura di downgrade
voi che siete piu esperti è possibile che questa procedura funzioni?
almeno per eseguire il 3.55 per poi un successivo ODE.
per i piu esperti cosa nè pensate ?
A me pare strano il fatto che ieri ero riuscito a comparare il dump fatto dopo la scrittura con la scrittura stessa. Oggi no, nemmeno sulla prima nand. Mah.. Guerriero dice che ci è riuscito e più o meno abbiamo usato lo stesso hardware, vorrei capire come risolvere. Sono curioso di vedere cosa succede con la alimentazione esterna. I dump buoni sono al sicuro, almeno quello per fortuna..
Inviato dal mio GT-I8150 con Tapatalk 2
Con l'alimentatore esterno credo risolverai perchè sappiamo che l'alimentazione data dal progskeet non è stabile ,mentre un alimentatore stabilizzato si.
Io penso che gli errori siano dati dalla cattiva comunicazione dal progskeet ed il PC ,altrimenti non si spiegherebbe perchè ieri si ed oggi no.
io proverei a schermare tutto dalla porta USB sino al progskeet almeno verifichi se ci sono dispersioni di informazioni.
sembra stupido.
Un passo alla volta, intanto alimento da esterna, vediamo che succede..
Inviato dal mio GT-I8150 con Tapatalk 2
sono solo dei consigli è possibile che siano anche stupidaggini ma la mia esperienza dice che è volte la cosa piu ovvia e quella che risolve le situazioni.
Continuano i miei test. Oggi come suggerito da Titty ho alimentato la nand esternamente, usando un alimentatore ATX e scollegando i 3,3V del ProgSkeet (la massa invece l'ho lasciata, male non fa). La prima nand è stata riconosciuta al volo, lancio l'erase, poi il flash (anche con verifica passata correttamente), faccio ben due dump dopo il flash, comparo tutti e tre i file (vale a dire il BIN che ho scritto e i due dump fatti in seguito) e sono uguali tra loro! Apro HxD e controllo le statistiche, perfette!
Passo alla seconda nand, viene riconosciuta anch'essa al primo colpo, lancio l'erase, mi si impalla circa al 83%, rilancio l'erase e va a buon fine. Faccio il flash con verifica, e la verifica fallisce tutti i blocchi. Chiudo WinSkeet, stacco la usb e spengo l'ATX. Riaccendo e ricollego tutto, nand non riconosciuta! :\
Ritento un po' di volte e infine la nand torna a essere riconosiuta, ma la verifica continua a fallire.
Provo a rimettere la prima nand sullo zif e anche questa ora non viene più riconosciuta! :(
Non capisco perché a volte venga riconosciuta e altre volte no. Ora penso di essere abbastanza certo che la prima nand sia stata scritta correttamente (lo conferma sia la verifica di WinSkeet che il doppio dump congruente fatto in seguito al flash). Quello che non mi è chiaro è perché appunto sia così altalenante, anche usando una alimentazione stabilizzata come quella esterna da ATX. Ci deve essere qualche altro fattore (quindi non di alimentazione) che fa "fluttuare" i tentativi...
zaruel85 se usi il progskeet 1.2 è il chip stesso ad essere altalenante! Una volta sono riuscito a farla scrivere completamente solo dopo ben 17 tentativi, uno stress, ma funziona e la cosa migliore come opzione è single word e static timing e la versione WinSkeet40000_111004 vedrai che alla fine ci riesci
Single word? Static timing? Guarda che stai parlando di NOR mi sa...
ops chiedo venia ho dimenticato che stavi programmando due nand....figura di m... LOL allora ci deve essere dell altro ma imputo sempre il problema a sto progskeet 1.2 che è antipatico
hai provato a riavviare il PC , a volte questi programmi quando si inceppano è finita bisogna riavviare il pc per far tornare tutto alla normalità.
quando lavoravo e utilizzavo phonix Nokia a volte quando si inceppava potevi chiudere e avviare il programma quante volte volevi ma dava sempre lo stesso errore ,dovevi solo riavviare il pc per risolvere.
una domanda stupida ma da ATX prendete direttamente i 3.3 volt dal cavo arancione senza nessuna resistenza, l'attacco diretto sulla MOBO?
Io non ho un ATX in piu ,vorrei usare quello del mio PC ho spellato il cavo arancione èd ho collegato il cavo rosso ramato che esce da un filo RJ-14 secondo voi va bene come spessore?
Io sto lavorando con nand dissaldate installate su zif, quindi niente mobo.
Inviato dal mio GT-I8150 con Tapatalk 2
è uguale invice di saldalrlo sul vcc della MOBO lo saldi sul VCC della flash sempre arriva alla flash.
allora fai direttamente il collegamento da ATX 3.3v alla vcc senza nessuna resistenza?
Certo, perché dovrei mettere una resistenza?!?Citazione:
Originariamente Scritto da jiro180387
Inviato dal mio GT-I8150 con Tapatalk 2
Purtroppo anche a me su nand non riusciva a funzionare corettamente e non capisco perchè! tra l'altro certe volte i dump non li faceva uguali!Citazione:
Originariamente Scritto da zeruel85
Penso che l'unico a cui funziona sia nand che nor è bartlet, non capisco come ma sei un grande ad esserci riuscito.
Citazione:
Originariamente Scritto da zeruel85
grazie per la risposta .
andre no NAND non ho avuto modo di provarlo! mi funziona solo su nor spansion e con sbattimentinti
Perdonami, avevo capito male, ma ugualmente su nor non ci son riuscito con le tue stesse configurazioni ;)
secondo me è solo una versione di costruzione che sia più difettata di quelle che gia lo sono...sto chip promette bene ma la qualità è peggio di quella cinese ...
Sto' effettuando il dump di un NOR MX29. Questa e' la configurazione che sto' provando:
- Windows XP Sp3
- USB collegato drettamente alla scheda madre.
- bitstream 121101_1223 winskeet40000 v.111120
- DYN-001
- NOR MX29
- alimentazione mothebord in standby
- R8 chiuso
- no pull up
- CFI errato
- Dump avviato
e' normale che e' mezz'ora che l'ho avviato ed e' fermo al dumpig address 0x0?
No, non è normale.
potrebbe essere l'alimentazione? con il tester ho su vcc della mobo 2,3V e sul prog ho 3,3V
comunque e' andato avanti ed ha fallito la verification dell'indirizzo 0x0
Fai il dump con scheda madre accesa (ricordati di collegare il Tristate tra mobo e ProgSkeet).
il tristate e' gia' collegato potrebbe essere questo che ha dato fastidio al dump?
E' l'alimentazione troppo bassa, prova accendendo la console, tristate collegato e progskeet messo a massa con la mobo.
oki oggi pomeriggio provo
Finalmente sono riuscito dopo innumerevoli tentativi a flashare e poi ridumpare due volte la seconda nand, quella in cui non ero mai riuscito a scrivere dati coerenti. I due dump dopo il flash confermano che ciò che ho scritto è uguale a ciò che ho letto. Ora la prova del nove sarà risaldare le nand sulla console e verificare che tutto sia andato per il verso giusto.
Configurazione definitiva (anche se ci ho messo una vita a concludere il tutto, sarebbe da appurare cosa crea instabilità di riconoscimento delle nand e flash errati):
- Bitstream 1223, i penultimi.
- Cavo flat da 200mm schermato, anziché quello in dotazione che è da 400mm non schermato.
- Nand dissaldate da mobo e installate su zif socket tsop48.
- Alimentazione esterna stabilizzata.
- R7 chiuso di default e R8 aperto di default.
- CE# primary collegato e CE# secondary non collegato.
- Switch con led spento.
Confermo che il test dei cortocircuiti presente su WinSkeet40000 non dà mai esito positivo con ProgSkeet 1.2 e bitstream 1223, mentre invece se utilizzate il bitstream 2121 il test funziona correttamente. Almeno, io nei miei test ho notato questa cosa.
hai quindi provato a dumapre con il 2121 o hai fatto direttamente con il penultimo?Citazione:
Originariamente Scritto da zeruel85
se hai NOR perchè non usi l'ultimo bitstream?Citazione:
Originariamente Scritto da mazenico
Dunque, con il 2121 mi sembra di aver provato solamente con il flat lungo (quello in dotazione), e avevo spesso bad stuck soprattutto in scrittura. Non so se fosse dovuto a questo punto al flat oppure al bitstream. Ho rimesso il 1223 perché è quello che mi ha dato i risultati migliori, sia in termini di dump, che di flash. Probabilmente è un po' più lento, ma mi sembra più affidabile. Comunque con bitstream 1223 e cavo schermato da 200mm, non mi va mai in bad stuck, al limite flasha cose senza senso, ma non mi si blocca mai. Mi pare si fosse bloccato una sola volta al 83% lanciando il comando Erase, per il resto sempre fluido.Citazione:
Originariamente Scritto da guerrierodipace
Faccio notare che per la seconda nand non ho usato la verifica di WinSkeet40000, cosa che invece ho utilizzato con successa sulla prima nand. Dopo aver flashato per l'ennesima volta la seconda nand, ho fatto direttamente due dump, confrontati e controllato le statistiche in HxD, tutto perfetto. Penso che la verifica sia superflua se poi si effettua qualche dump e lo si confronta con il BIN flashato in precedenza.
P.S.: se come me avete come modello di nand le Samsung K9F1G08U0A-PIB0, assicuratevi prima di dumpare e soprattutto a maggior ragione prima di flashare, che quando premete su Auto, venga riconosciuta come ECF1801540 e non con altre sigle. A volte non mi veniva riconosciuta, non so ancora esattamente da cosa possa essere dovuto, presumo alla posizione del chip all'interno dello zif, ma è solo una ipotesi, e non riuscivo a scriverci dati coerenti, anche se finiva sempre al 100%.
P.P.S.: mi raccomando se avete appena iniziato, fate molti dump di entrambe, e controllate non solo le statistiche, ma anche tutto il resto, magic headers, revokations, ros, ecc. ecc. ecc., come da wiki di PS3DevWiki.