JTAG Xenon - Nand damaged after writing updated image?!?

[X-Samurai]

Have an Jtaged Xenon and wanted to update it to latest freebot with 14719. So I made an image out of the original dump I had (retail) and flashed it through the xbox. Think I used flash360.xex as Xellous v0.3 did not recognised the updflash.bin on my usb stick.

Unpluged and repluged console and it booted straight to the bootsequence (the new one from 14719) but then at the end of the sequenz the image just freezes and wount start dash. So I tried Xellous which just works fine. Even flashing through Xellous and usb stick works now but it did not changed the freeze after bootup sequenz ends.

So I soldered LPT flasher to the Xenon and reflashed the new image through it. Same result. So I dumped it to compare it with the source freebot image. And here we go: Offset 6E3B80 to 771BF0 => nothing else then "00".
So I think as Xellous seems to be at the beginning of the image it works fine cause it wount touch anything in offsets 6E3B80 to 771BF0. But original dash need this offsets so it wount boot.

What I try next now is to delete nand and dump that again to see which offsets cant be touched. ( results willl be posted in the evening)

Oh and for those who think its an Problem with my new generated image. I just flashed back the Nand I dumped before updating, the one that worked fine, and tada, freezes just at the end of the bootsequence.

So am I right when I think nand seems to be physically damaged, and when so, is there an possibility to just replace it with a new one? (Have an reflow station which should just do the job)

Would be great to here your thoughts on that one

 

[TheElderly]

I had a similar issue where the nand was literally broken, in half (well, cracked). I solved the issue by flashing the updated nand image to another xenon (RROD), then transplanting the newly-flashed nand to the one you are trying to fix. The only other thing I can think of is onset of RROD.

Honestly, it's overkill unless you are absolutely sure the nand chip is dead. I did it this way because the traces and pads for reading/writing to the nand were also butchered by the client. I was able to do it with a pencil torch so you should easily be able to do it with a reflow station.

 

[tonyjandc]

It may not be the nand as you stated that it now does it with orginal nand but just as an afterthought why didn't you use xenon elf to load updated nand in ? anywyas back to problem console freezing on boot seq could be down to faulty ram as we all know xbox's can be a pain its a process of elimanantion . I had one xenon that frooze just before dashboard I reflowed ram chips under gpu . bang system booted straight away dont forget xenons are old units and the board may have warped slightly making the balls loose contact.

---------- Post added at 15:02 ---------- Previous post was at 14:57 ----------

I found out by using spare cpu cooler (smaller than gpu cooler plate) and apply very slight pressure to ram chip but remember to do this after new paste on chip and flat surface my workstation has glass counter top no damage via antistatic or metal touching and using antisatic wrist guard.

 

[X-Samurai]

Okay now after erasing the nand I get many bad blocks when dumping but with the error code 280?!
Have one bad block everytime when dumping in 1CD but this is an "normal" error code 250.

Also it wount FF the complete nand. Many Offsets with 00 still in their.

So I dont see the point why you think it could be a problem related to an RROD. Iam not able to write the complete .bin into my nand. And that seems to be the reason why it freezes everytime at the same point when the bottsequence ends.

Now after erasing things are even worse, now after writing .bin to nand, console doesnt even start, one little green led flashes (no dvd drive) but no led ring sequence. Even Xell dont start anymore.

So is it an bad nand or am i still poking in the dark?

 

[TheElderly]

You are correct in going after the nand. If it booted before and no wiring was changed then it should boot again with the same nand image. You say the errors are randomly happening throughout writing to the nand? But error 250 always happens at 01CD?

If the errors are random, go through each failed block and use nandpro to re-flash all the individual blocks. For example, lets say that block 01CD didn't get programmed correctly, use the following command to re-flash that one block:

nandpro lpt: -w16 updflash.bin 01CD 1

This command tells nandpro to flash your nand file, starting at 01CD and flashing a total of 1 block. Do this for each failed section until they are all successfully written.

If the nand simply is not writing any info anymore then a transplant will be necessary. Are you 100% sure you have an exact copy of the original nand that was on the console when it was booting? You dumped it twice and compared? Were there any bad blocks when reading?

 

[X-Samurai]

Bad Block 01CD is and was before constantly bad when reading writing or erasing, so I had to remap that one. But thats not the case, these many bad blocks just popped up right after i erased the nand completely. So it must have something to do with the ability to not write correctly to the nand i think. I try to flash Xell.ecc solo to the nand and reflash through xell an freebootimage with direct linking to freestyledash, maybe thats the way i can get through the freezing bootsequence.
Will tell results later

And yes the dump must be perfect, cause when i compare the dump through hex editor with an dump of it after i flashed it to the nand i see that every difference offsets that i can look after is filled with 00.
So these must be the areas where the nand did not wrote correctly. And there are a few areas of these 00 offsets...
Of course in the original dump image there are no 00 offsets in these areas, so all the information is lost.:eek2:


Flashing image through Xell Reloaded v0.991 with built in RawFlash v4 did the trick.
Xbox booting fine now!
Thanks for all your inspiration anyway

 

[dateq]

Are you telling us that you have a working glitched xenon that boots perfectly every time?

I think i just died and went to heaven....

 

[socalbill]

Are you telling us that you have a working glitched xenon that boots perfectly every time?

I think i just died and went to heaven....

he's got a jtag, not rgh

 

[LoneWolf913]

You are correct in going after the nand. If it booted before and no wiring was changed then it should boot again with the same nand image. You say the errors are randomly happening throughout writing to the nand? But error 250 always happens at 01CD?

If the errors are random, go through each failed block and use nandpro to re-flash all the individual blocks. For example, lets say that block 01CD didn't get programmed correctly, use the following command to re-flash that one block:

nandpro lpt: -w16 updflash.bin 01CD 1

This command tells nandpro to flash your nand file, starting at 01CD and flashing a total of 1 block. Do this for each failed section until they are all successfully written.

If the nand simply is not writing any info anymore then a transplant will be necessary. Are you 100% sure you have an exact copy of the original nand that was on the console when it was booting? You dumped it twice and compared? Were there any bad blocks when reading?

Just an FYI, the commandline given to reflash a specific block will not work as intended. It will write the first block of the bin file provided to whatever starting address you gave, not the same block from the binary image, i.e. you'd write block 0 of updflash.bin to 1CD on your console's nand with the above command. You would have to extract each block from the original nand.bin to a separate, one block file, and then inject that the same way you inject your KV and config blocks. It's fine if you've only got one or two bad blocks, but for a case like the OP described, don't waste your time, get XNandHealer to do it, or figure out what else is horribly wrong with the console first.