Writing error ripetuti nella scrittura dell'image su corona v1, come risolvo?

**vipera** · 31-01-13

vado per dare il comando e dà sempre
version 03
flashconfig 0x000000000
can not continue

ma che cacchiarola succede??? ufffff

**brundu** · 31-01-13

tra un tentativo e l' altro togli alimentazione alla console,prima collega il nand x e poi la console e riprova

**vipera** · 31-01-13

cioè ragazzi la situazione è questa...ho tolto il chip e ho messo nand originale, tutto ok, scrittura pulita e la console parte da originale (ha dash 13599)
se invece installo il chip e metto l'updflash creato con jrunner dalla nand originale (dash 16202 e RGH2.0) dopo un pò che inizia a scrivere inizia a dare errori a ripetizione! boh...non so più che pensare...
volevo creare l'update per 13599 solo che mi fa selezionare solo RGH1 ma soprattutto non me lo fa creare mi dice che manca ini!
mi potete aiutare?

**vipera** · 31-01-13

Non so cosa può essere successo, ora non mi fa scrivere proprio più...boh..
Mi da sempre flash config 0x00000000.
È come se la console non fosse proprio vista, solo dopo aver cliccato tante volte parte una scrittura stracarica di errori ma che è una scrittura fasulla in quanto continua anche se tolgo l'alimentatore!
Vorrei caricare una foto ma non ci riesco!

**fmauro52** · 02-02-13

Originariamente Scritto da zeruel85

Tutte le slim sono RGH2.

Dovresti postare le foto per vedere un attimo la situazione attuale. Se ti dà tutti quegli errori, per me l'unico motivo è il nand programmer installato male.

Perchè dici che le slim sono tutte rgh2 ? Per quanto ho capito, rgh 1 o 2 si stabilisce in base alla dash, per far partire xell! Infatti dopo dash 15574 ce bisogno del dgx, correggetemi se sbaglio.

**zeruel85** · 02-02-13

Perché si basa su I2C per il glitch e i CB del kernel sono splittati, ergo, tutte le slim sono RGH2. Le phat RGH1 sono quelle con kernel di partenza 14699 o inferiore, che si appoggiano al PLL_BYPASS anziché al I2C e hanno un single CB nellla bootchain del kernel.

aquilus · 02-02-13

Originariamente Scritto da vipera

Non so cosa può essere successo, ora non mi fa scrivere proprio più...boh..
Mi da sempre flash config 0x00000000.
È come se la console non fosse proprio vista, solo dopo aver cliccato tante volte parte una scrittura stracarica di errori ma che è una scrittura fasulla in quanto continua anche se tolgo l'alimentatore!
Vorrei caricare una foto ma non ci riesco!

Ho avuto lo stesso tuo problema con l'ultima Trinity fatta proprio l'altro giorno!
La doppia lettura...ok
Scrittura DGX.ecc...ok
Scrittura updflash....flash config 0x0000000 Can not continue

Penso all'alimentatore non collegato o ad un filo staccato, ma ovviamente
era tutto in ordine.
Dopo qualche tentativo inizia la scrittura ma piena di errori...come te!
Dopo decine e decine di console fatte con il Nand-X penso al collegamento
dei cavi tra il Nand-x e la mobo...verifico i collegamenti con multimetro ed erano
regolari.
Senza dissaldare nulla e senza spostare nulla riprovo.....scrive updflash correttamente...
Avevo appena aggiornato J-runner...può darsi sia un bug dell'ultima versione?
Non ho fatto altre console da allora e non posso avere un riscontro concreto.
Fatto sta che, incredibilmente, non scriveva correttamente la nand.
E trovarsi con DGX.ecc scritto in quel momento non era la più felice delle situazioni.
Non ho dato peso alla cosa, ma leggendo la tua esperienza ora è da capire il motivo.
Le saldature sono da escludere...per leggere e scrivere con Nand-X non occorrono
dei capolavori. Tanto è vero che senza spostare alcun filo poi riuscivo a scrivere
correttamente.
Vuoi tentare con una vecchia versione di j-runner?
Io stavo quasi per tentare con Squirt, ma poi ha funzionato e, ti ripeto, non ho dato peso
alla cosa.

**The Pusher** · 02-02-13

Scusate ma perche' scrivete l'updflash dal flasher e non da xell?

aquilus · 02-02-13

Con il nuovo xell che ora parte a video anche su Corona
è possibile scrivere la nand?
Credo di si, ma non ci ho mai provato!
Abituato alle Corona che non davano xell a video, l'immagine
definitiva la scrivevo sempre con il flasher hardware.
In ogni caso è strano quel che è successo...

**The Pusher** · 02-02-13

E' sempre stato possibile, anche quando non si vedeva a video, anche con il DGX, su corona da 250GB

aquilus · 02-02-13

Immaginavo...
C'è sempre da imparare...
Un like per te -

**fmauro52** · 02-02-13

Originariamente Scritto da zeruel85

Perché si basa su I2C per il glitch e i CB del kernel sono splittati, ergo, tutte le slim sono RGH2. Le phat RGH1 sono quelle con kernel di partenza 14699 o inferiore, che si appoggiano al PLL_BYPASS anziché al I2C e hanno un single CB nellla bootchain del kernel.

Ho letto anche su altri forum ma non ce scritto questa tua affermazione, anche perche se non ricordo male, la mia che era Trinity 13xxx ho fatto rgh1. Per sicurezza andrò a verificare, magari sto dicendo INA sciocchezza.

**zeruel85** · 02-02-13

Sono solo nomi.

Comunque al di là di 1 o 2, ciò che ho scritto è vero e documentato, cerca di capire il senso e non fermarti solo alla questione del numero in sé.

All'inizio si chiamava RGH e basta, la storia del 1 e 2 è nata quando la Microsoft ha deciso di splittare i CB delle phat per impedire l'hack.

Solo che a ben pensarci e se hai capito grosso modo il funzionamento del hack, ti accorgi che le Trinity su cui si poteva fare RGH erano già degli RGH2, proprio per la natura diversa su cui si aveva accesso alla console (le slim nascono tutte con CB splittati). Successivamente il nome RGH2 è stato associato per distinguere le phat aggiornate e in possesso di dual CB, proprio come tutte le slim in commercio. Da qui il divario tra RGH1 e RGH2. Quindi, in sostanza, sulle slim non è mai esistito un RGH1, ma veniva comunemente chiamato RGH per tutte le console, inizialmente, senza numeri.

Spero di essere stato abbastanza chiaro.

Inviato dal mio GT-I8150 con Tapatalk 2

**fmauro52** · 02-02-13

Originariamente Scritto da zeruel85

Sono solo nomi.

Comunque al di là di 1 o 2, ciò che ho scritto è vero e documentato, cerca di capire il senso e non fermarti solo alla questione del numero in sé.

All'inizio si chiamava RGH e basta, la storia del 1 e 2 è nata quando la Microsoft ha deciso di splittare i CB delle phat per impedire l'hack.

Solo che a ben pensarci e se hai capito grosso modo il funzionamento del hack, ti accorgi che le Trinity su cui si poteva fare RGH erano già degli RGH2, proprio per la natura diversa su cui si aveva accesso alla console (le slim nascono tutte con CB splittati). Successivamente il nome RGH2 è stato associato per distinguere le phat aggiornate e in possesso di dual CB, proprio come tutte le slim in commercio. Da qui il divario tra RGH1 e RGH2. Quindi, in sostanza, sulle slim non è mai esistito un RGH1, ma veniva comunemente chiamato RGH per tutte le console, inizialmente, senza numeri.

Spero di essere stato abbastanza chiaro.

Inviato dal mio GT-I8150 con Tapatalk 2

Non ero a conoscenza di quanto mi hai appena insegnato e mi piacerebbe approfondire il discorso dei cb.

**vipera** · 03-02-13

Originariamente Scritto da aquilus

Ho avuto lo stesso tuo problema con l'ultima Trinity fatta proprio l'altro giorno!
La doppia lettura...ok
Scrittura DGX.ecc...ok
Scrittura updflash....flash config 0x0000000 Can not continue

Penso all'alimentatore non collegato o ad un filo staccato, ma ovviamente
era tutto in ordine.
Dopo qualche tentativo inizia la scrittura ma piena di errori...come te!
Dopo decine e decine di console fatte con il Nand-X penso al collegamento
dei cavi tra il Nand-x e la mobo...verifico i collegamenti con multimetro ed erano
regolari.
Senza dissaldare nulla e senza spostare nulla riprovo.....scrive updflash correttamente...
Avevo appena aggiornato J-runner...può darsi sia un bug dell'ultima versione?
Non ho fatto altre console da allora e non posso avere un riscontro concreto.
Fatto sta che, incredibilmente, non scriveva correttamente la nand.
E trovarsi con DGX.ecc scritto in quel momento non era la più felice delle situazioni.
Non ho dato peso alla cosa, ma leggendo la tua esperienza ora è da capire il motivo.
Le saldature sono da escludere...per leggere e scrivere con Nand-X non occorrono
dei capolavori. Tanto è vero che senza spostare alcun filo poi riuscivo a scrivere
correttamente.
Vuoi tentare con una vecchia versione di j-runner?
Io stavo quasi per tentare con Squirt, ma poi ha funzionato e, ti ripeto, non ho dato peso
alla cosa.

Per versione vecchia quale intendi?

**vipera** · 03-02-13

Originariamente Scritto da aquilus

Con il nuovo xell che ora parte a video anche su Corona
è possibile scrivere la nand?
Credo di si, ma non ci ho mai provato!
Abituato alle Corona che non davano xell a video, l'immagine
definitiva la scrivevo sempre con il flasher hardware.
In ogni caso è strano quel che è successo...

A me xell non si vedeva a video! Si può scrivere l'upd anche se non si vede nulla a video? E in qual caso come si fa?