Don't worry about the bad blocks that it showed there too much, it's just reporting the result of reading the block before it attempted to change it - which of course shows you the same result as before - if you were to run it again now with the same image it should only show the two blocks that were bad in your original image. Typically a true bad block should never try to get erased this variation of the tool was meant to help when artificial bad blocks happen, like those that you ran into, and shouldn't be used regularly - the normal rawflash built into current xell will never touch a block that is marked as bad, which is as it should be.

Woohoo!!! It worked

I created a brand new 16203 nand image using XeBuild GUI 2.09 and I gave it my STOCK NAND to use.  I put all the parameters in (without the DL patches) and renamed that nand to nandflash.bin and put that and the xenon.elf that you PMed me (rawflash_v4_no_badb_care) on the fat32 usb stick.  Booted Xell Reloaded and it booted the xenon.elf and started flashing.  After flashing, I did a cold boot (shut the machine off and then unplug it from the back of the console for 30 seconds to a few minutes ) and booted up the machine, and it booted RIGHT UP

It showed me the initial setup screens and after making those settings, I came into the Metro dash   Went into system settings and it showed 16203

By the way, one thing still bothers me a little.  When it had finished flashing, it again showed me the same FOUR band blocks....



Should I be worried ?

One thing is for sure, am NEVER using that stupid ass NandFlasher again.  flash360 has ALWAYS worked great for me and better yet, use Xell Reloaded to flash or the rawflash_v4_no_badb_care that you gave me

Thank you so much for all the help.  REALLY APPRECIATE IT BUDDY.  THANK YOU!!! THANK YOU!!! THANK YOU!!!

PS:  Originally, I only have TWO BAD BLOCKS in all my nands

Nothing to do with dash launch at all...

Somewhere in your process one of the tools copied the bad blocks as is from their original location to the remap location, and now you have 0x222 and 0x23e marked as bad, as well as their default remap locations 0x3ff and 0x3fe (which would happen if you just copied the already bad data to those blocks and wrote it without checking.) So in effect, you remapped a bad block, then marked the destination as bad too... my guess is NAND flasher 1.2.0 did this when it tried to remap blocks for you or something similar.

E79 literally means xam.xex is corrupt, so one of those bad blocks or both have xam.xex data in them and it can't find it or is using the data in the bad block because the remap is no good which has the effect of breaking xam.xex so it can't be loaded, which gives you a nifty E79 error screen.

You can do one of two things at this point... you can re-remap to 0x3fd and 0x3fc (by making an image with no remaps at all, then manually moving the two bad blocks to those instead, or by dumping what is currently in the NAND and using THAT to make a new image - use rawflash to write that image) or you can try to clear those 'fake' software marked bad blocks at 0x3FF and 0x3FE. I will PM you a link to a rawflash elf that will attempt to erase bad blocks, and you can choose if you wish to try it or go the other route.

edit:/ forgot to mention, if you try to clear bad blocks by writing the image with the elf, make sure after you write the image that you shut the machine off and then unplug it from the back of the console for 10 or so seconds before trying to boot it.

Hey guys,

I have an Xbox 360 Slim Trinity. I was currently on 16202 with DL 3.07. I was up to date on everything and it was working great.  Then, a member on another forum suggested I create a new nand in J-Runner with edited temps so I don't have to keep the fan running at 65% all the time.

I had originally created 16202 nand using XeBuild GUI back when I was updating my dash. It had flashed perfectly using flash360 and it was working great.

I gave this backed up nand (16202) to J-Runner for creating the new nand.

I created a new nand using J-Runner of dash 16202 with the edited temps 60, 60, 60, 65, 65, 65. I selected RGH (since my CB was 9188) gave CPU key, everything was okay.

After creating updflash.bin, I used NAND Flasher 360 for XBOX v1.2.0 by trancy to flash it.

Now, when I start my Xbox, I get red light and E79 error :O  Xbox logo boots for 1/2 sec and then E79 and red dot

I can boot into Xell Reloaded, so what I did was use my old 16202 nand (that I had flashed earlier using flash360) which means it had worked great earlier, i put this nand (updflash.bin) on the root, booted Xell Reloaded, and it flashed this nand but still it is showing me this same error.  Why is the old perfectly working nand NOT WORKING NOW???

Now, I also have 14699 nand and 16202 nand, both of which created with XeBuild GUI and flashed with flash360, both of which worked great earlier but now when I try to flash either by using Xell Reloaded, it shows red light and E79

I also have 2 bad blocks in my nand. Here's the J-runner log...


Can you guys tell me what I am doing wrong ? I can still boot into Xell Reloaded and I also have a friend who is a professional modder. He has a Nand-X and I can take my box to him too to get it fixed, but I would rather try to fix it myself using Xell Reloaded if possible.

Now, AFTER DOING ALL THIS, I downloaded XeBuild GUI, and created a brand new NAND of 16203. Here's a screenshot from it...



Even after creating this nand and flashing it using Xell Reloaded, I am still getting red light and E79 error

I have also removed my 250 Gb internal hdd and flashed again, just in case, but still same error

I have tried creating a brand new 16203 nand WITHOUT ANY DL PATCHES using XeBuild GUI and flashing it with Xell Reloaded.  Here's how it looks once it's done...



Another one...


Another guy told me to put xenon.elf on root of fat32 USB and rename updflash.bin to nandflash.bin and try flashing using that.  I did everything.  It flashed perfectly, told me the "Image has been written - Shutdown Now!"

No success   Is this all because of DashLaunch 3.07 ?  What do you guys think is going wrong ?

Sorry for writing this post so big but I tried to provide any and all information.

Any ideas ? I know I can get it fixed by taking it to my professional modder friend, but I would rather avoid that as it involves opening my console and soldering the Nand-X.

Please help me out guys. Thanx a lot in advance.

Edit: My Slim Trinity is glitched using TX CoolRunner and everything was working fine since the past 1 year.

The reason why the southbridge would not recognize the nand when an incorrect image is written is not due to wrong data.

After the 1BL has loaded the SMC from the nand will take over the southbridge.

So when this smc is corrupted or from a different motherboard, your southbridge would not work any more.

These motherboards are not designed to handle 8GB nands so the soutbridge would simply not know how to handle them.

Regards

Great work, thanks for sharing!

Its called the Matrix CryptoCop Addon for the d5s and Hitachi drives.

The latest LITE-ON DG16D5S and HITACHI DLN10N 0500/0502* solution from the Matrix Team!

*Hitachi DLN10N 0500/0502 drives are going to be compatible in a few days.



This solution provides the option to run DVD backups of your owned games. You’ll able to play all your backups (XGD1, XGD2, XGD3 Xbox and Xbox 360 DVD formats) even on Live – at your own risk!

WHAT YOU NEED:

A NAND dump of a console with one matching drive (Lite-ON DG16D5S or Hitachi DLN10N 0500/0502*);
The CPU KEY of the console above;
1x  Matrix Freedom Lite PCB (MTX 007);
1x CryptoCop Add-On
Matrix NAND Programmer
Matrix Freedom D5S Manager V.1.01
Small piece of wire, soldering station, etc.

The reason you might not have been able to read/write the 8g nand may have been something to do with the southbridge. Often people have trouble reading the nand after writing incorrect data to the nand for jtag etc.

Did you try shorting the pins of the nand to get it to read?

As far as the RPi nand reader goes, the raw format should load into Hex to be readable. I know that the ProgSkeet is a universal NAND program that does this and works fine, i have two of these myself.

I know it all works, although i don't really know the specifics, so i can't be more helpful :-(

Travelstar HTE545050A7E380 Z5K500 500 Gb 2.5 - works?

good job.
will be nice if app can flash other CPLD-File to chip and run next test automatically.
Console will also stop after three unsuccessful tries good , this why will be nice to auto flash other CPLD-File and start the test again ( LibraSoft / Squirt support ).