Tutorijal: Update dashboard-a RGH/JTAG konzole sa RAWFLASH-om XELL

Guides & Tutorials JTAG/RGH podrška
1

RAWflash V4 update NAND-a na novi DASHBOARD

        Većina nas se sreće sa problemom ne mogućnosti posedovanja NAND programatora za ažuriranju NAND-a RGH/JTAG konzole, na svu sreću pojavio se i program koji rešava taj problem i nosi naziv  RAWflash. Postojale se prethodne verzije ovog programa:

V1-prva inicijalna verzija;
V2-druga sa podrskom za BIG BLOCK NAND;
V3-verzija donosi novine kod preskakanja loših blokova (re-refix bad block) i preskače i u skidanju (dump) i u pisanju (flash) umesto da samo skida;
v4 - poravlja “page offsets” za “bad block” provere na velikom bloku ( popravlja probleme kada je nand memory unit prisutna ) ovo je kod JASPER revizija ploca.

        Za ažuriranje dashboarda na novi DASHBOARD ako ste NPR 2.0.1.3599 i želite da ima 2.0.1.15574, potrebno je koristit neki program za pravljenje hackovanog NAND-a ili skuvanog  "nandflash.bin".  Samo kreiranje ovog fajla je dosta pojednostavljeno, potreban vam je NAND kopija original Microsoft NAND-a i CPUKEY.

Sve konzole kojim je uradjen RGH/JTAG imaju DVD/CD na kome se nalaze original fajlovi i sve potrebno, nekim su to dobili u elektronskom format preko maila.

Potrebni alati:
Rawflash v4
rawflash_v4.zip

Nanddump.bin (original kopija vaseg fabrickog NAND-a)
CPUkey.txt (txt fajl koji sadrži vaš CPU ključ)

Potrebno je uraditi :

  1. Napraviti “nandflash.bin” po nekom tutorijalu sa foruma.
  2. Smestiti “nandflash.bin” na koreni direktorijum root USB drajva (formatiranog FAT32) zajedno sa “xenon.elf” nalazi se u direktorijuma programa kada se raspakuje fajl ili iz foldera \data\ u 360 multi builder.
  3. Upalite XBOX360 na EJECT sa USB-om u konzoli (podrazumeva se da ste sve od, startuje se 2stage(faza) xell-a i ugasi kada napise (izvadite napajanje iz boxa na kratko ako je menjan SMC( south bridge configuration file).

Informativno izgled 2 faze XELL-a kada se radi update NANDa :cool:

  1. Ako je sve prošlo kako treba bez grešaka u XELL-u vaša nova verzija Dashoard-a će se učitati ( sve zavisi koliko brzo vaša konzola GLitch-uje, neke brže neke sporije zavisno od revizije ploče i chipa).
    Po standardnom podešavanju (default) rawflash v4 proverava i neće prepisati ECC blokove NAND-a ili napraviti druge probleme da vam se konzola više ne boot-uje uvek će ostati XELL i ECC. RAWFLASH v4 je pogodan za fbbuild hackovane verzije NAND-a.

**Testirano na svim konzolama radi bez ikakvih problema sa rawflash v4

**Sve greške i nedostatke XBR Admin team će ispraviti i dopuniti.

2

sto ti na linku rawflash v2?

3

Slučajno sam pokupio pogrešan link, dobro si primetio.
Ispravljeno.

EDIT:
Vec je bilo problema sa nekim JTAG konzola, covek napravi E71 :slight_smile: ali uspesno reseno.

Otvaram temu zbpg ljudi kojima je stvarno potrebna pomoc, desilo veceras i uspesno reseno.

4

za 14699 dash ima bugova, ali radi, desi se da izbaci 3 empty bloka kao error ali sve normalno radi, jasper 512
blokovi su jedan za drugim inace i prazni su…

kompletan nandflash.bin i originalni nanddump.bin su provereni kroz sve moguce programe i nijedan ne sadrzi bad blocks tako da je definitvno bug u rawflash-u u kombinaciji sa novim dashom

5

evo potvrde sa TX-a da je sve ok status 240 je prazan blok :), desava se da ovaj XeBuild napravi prazan blok prilikom pravljenja hackovanog image-a

by Martin C:

Status 240 is empty block. It assumes an empty block is a problem, however a recreated NAND might have padding which means you could have empty blocks.

In short, you should be ok to ignore it.

6

@studiovpc to je bezazleno ali kada je greska 250 onda moze problem da napravi ali u odredjenim situacijama.
Ne obazirite se na te greskice nije strasno rawflash to relocira.

7

Evo ja sam odradio update na mom jasper 16mb. Izvukao sam nandflash.bin preko xeBuild-GUI-v1.0, odradio sve po upustvu i zavrseno bez problema i bez block error :slight_smile:

8

odlicno, svi 16 mb nandovi prolaze bez ikakvih problema, jasper big block zna da pravi probleme, eto ponekad…

9

Ne prolaze, ima onih 16MB koji su imali error 250 sa programatorom i kada cita i pise on ga poseduje, neki od njih i fabricki izgleda imaju falinke.
Sve mi deluje da su to neki nebitni bugovi.

Nista od ovoga nije opasno!

10

ha onda je sve od slucaja do slucaja, najbolje je clean masina za dumpovanje bez icega u pozadini pa polako pa kako bog da :slight_smile:

11

Ma kakvi ako neka pravi gresku ona pravi :), pogotovu JASPERi to znaju, na primer SLIM ni jedan nije imao problema, to mi deluje da ima neke druge veze. Bitno je da radi i da je bezopasno.

12

Greske koje su se javljale prilikom update sa RAWFLASH v3 na DASHBOARD 2.0.14699 su izgleda mi ispravljene, izasla je nova verzija RAWFLASH V4 GitHub - Free60Project/libxenon.org-forum: Archive of libxenon.org forum

13

sto bar ne stavi sta je izmenjeno, changelog:

place “nandflash.bin” on the root of a usb device
start 2stage xell and shut off when prompted (replug power if you changed SMC)

  • by default it checks blocks before writing, and will NOT overwrite or erase any block with ecc/other issues (perfect for *** images with auto remaps)

small change to libxenon was required to silence non-error messages

tested on falcon, trinity and jasper 256
**
v4: fix page offsets for bad block checks on big blocks (fixes problems when nandmu is present)**
v3: re-re-refix bad block skipping so it skips it in both the dump and flash instead of just in the dump
v2: add big block support
v1: initial version

14

Pa to su one greske sto su se kod tebe javljale :slight_smile: znas da sam te pitao da li vidi MU, pretpostavljao sam da ima veze sa tim.
Azuriram.

15

u slucaju da odradite update preko rawflash-a a konzola nece da butuje i dobije rrod evo resenje, sad sam mrtav pa ne mogu da prevodim, sutra prekosutra prevod… credits MartinC sa TX foruma

After countless posts of repeating myself, I’ve decided that it’s best to write this guide instead.

First off, let’s understand the main difference between the old SMC exploit (JTAG) and the new Reset Glitch.

JTAG consoles emulate the e-fuses, therefore data stored within (with the exception of the lines 3,4,5,6 - the CPU key) are not addressed. This is why JTAGs are a lot easier to manage in terms of updating. It doesn’t matter what state the remainder of fuse lines are in as it doesn’t care.

So, back to RGH (as this is an RGH tutorial).

Every time you run an OFFICIAL MS update on your console, the Lock Down Value (LDV) will increment by one. This value is written to the base address of the NAND as well as into secdata.bin as well as a couple of others. I think the console can go up to an LDV of 80 and after that, it doesn’t increment any more.

It’s worth noting at this state that the bootloader (CB) and LDV are the FIRST thing the console checks when it boots. If the LDV doesn’t match what the CPU e-fuses say (or more importantly, is LOWER than the CPU e-fuse LDV), you’ll get 3 red lights and 0022 Secondary Error Code. This isn’t your average run-of-the-mill RRoD, so don’t assume it is.

Whatever you see in XeLL is LAW. The value for CPU key for instance is a permanent string and CANNOT be changed (and won’t ever change, unless you replace the CPU).

The e-fuse lines are a different matter, and this is where you will trip up if you don’t understand the basics.

Example - you’ve just finished with an RGH console (or indeed rebuilding a retail NAND for unflagging) and after flashing, the console sits and looks at you for about 20 secs and FINALLY gives you 3 red lights 0022.

Crap.

Don’t panic. The chances are you’ve done something out of sequence or the NAND dump you used for the source image is older than what was previously on the console.

Solution:

  1. Boot XeLL. If it’s an RGH console doing this, then XeLL should still work as it doesn’t need to know about any details from your console (with exception of the smc and CB values, but that’s by-the-by).

  2. Count the number of ffff’s you see on lines 7 and 8 (directly below the CPU key). This is the current LDV number for the console. As long as you don’t run any more official MS updates, this number won’t change. Alternatively on phat consoles, remove R6T3 and this number will NEVER change, regardless of what you try to apply.

  3. Download Multi_Builder (latest version). You’ll see me harp on about this tool just about everywhere. I do because it’s probably the most functional image build tool out there.

  4. Go into Data/my360 and put your cpukey.txt (a txt file with your CPU key) and nanddump.bin into this folder . ANY previously valid dump for this console will do. LDV and dashboard level are irrelevent. You can even use a previous RGH image should you want to.

  5. Open options.ini (options_r.ini if you’re building a new retail NAND). Find “cfldv =” and add your number from XeLL after this, so if you counted 8 fff’s, then “cfldv = 8”. Save and close the ini file.

  6. Run Multi_builder. Choose your board type, then choose whether you’re building a retail or RGH NAND. Note at the very end you should see something like this:

_---------------------------------------------------------------
nandflash.bin glitch image built, info:

console : falcon
NAND size: 16MiB
CPU Key : 71929DA455E71BD95654E071D1018C33
1BL Key : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CF LDV : 8

ggBuild Finished. Have a nice day.

---------------------------------------------------------------_

The CF LDV should match what you entered into options.ini.

Flash this new nandflash.bin to your console and it should now be ok.

NOTES:

  1. It’s possible to sort this out without being able to boot XeLL. If you only have the CPU key for example and no longer have the ability to run XeLL, take the LAST KNOWN DUMP for the console and open in 360 Flash Dump Tool. Note the highest LDV number. Now follow the steps above and increment the LDV number by one each time, so build and flash to the console - rinse and repeat until it boots.

  2. It’s also possible to do the increment in 360 Flash Dump Tool, however this is not advisable since other files like secdata.bin etc have the LDV in there too. Whilst this won’t affect an RGH console, those booting a retail dash will have issues the next time they update (E81 more than likely). Therefore, simplicity rules and using the same method for both RGH and Retail NANDs wins.

Hope this helps some of you scratching your heads over this.

PS I’ve done this entirely from memory and it’s 1am here, so please excuse any errors!

16

To je kada se vrati stock dash i kaze sta se desava ako nisi pratio proceduru update, znaci kada se JTAG odradi nije pametno vracati na retail, moze biti problema i ne moze sam korisnik preko RAWflasha mora preko programatora.

17

Jel postoji neki specijalan razlog zasto se koristi rawflash umesto flash360 (ne racunam prvi upis pri jtagovanju), a s obzirom da sve alatke za pravljenje image-a same remapiraju bad blockove? Nikako mi nije jasno sto svi koriste rawflash (iako je ocigledno imao problema) kada je flash360 vec istestirana alatka i radi svoj posao.

18

rawflash je napravio cOz(RGH), napravljena je za Xell reloaded, covek je azurira, radi iz Xella.
(flash360)Niko je ne koristi za update RGH tj niko nije probao a nisam ni ja. Ova alatka(rawflash) je jednostavnija samo gurnes i sacekas. :slight_smile:
Probaj (flash360 na RGH) pa nam reci kako je proslo, ako je jednostavnije napravicemo tutorial.

19

ajde molim te mirko da demistifikujes ovo sto si napisao :slight_smile:

20

Ajde reci mi sada da li odgovara? !W!:happy