Completly Messed Up Jasper From Start To Finish

[18.4009]

I am praying someone here that is waaay smarter then me can teach me how to fix this disaster...
I sold my Falcon Jtag unit and used the money to get a Jasper 256m unit. Got off work last night and tore into Jtaging it...... sad.gif
I wired it up just like my falcon and ran nandpro (nandpro lpt: -r16 nand.bin) did this three times and compared all the dumps with total commander and all were identical.
I then fired up jtag tool and told it to write xell, once done I plugged it into the tv and turned it on and had a blank screen... Just the green light on the xbox would come on and nothing else.
So I plugged it back into the pc and told jtag tool to remove xell... After it ran writing the nand I made using (nandpro lpt: -r16 nand.bin) I plugged it into the tv and omg... it wont even power on now!
After trying to figure out what in the world I did wrong I think I made two mistakes.
First one made was the command I did with -r16 isnt what you use with jaspers and secondly after writting xell to it I tried to turn it on with the aud_clamp wiring already done, hence it went to black screen. I think I should have wired it normal until I patched the smc...
Please of please can anyone help me fix this? ATM I have a $250 paper weight. 

[bluespace77]

You really should have done your research before you bricked your console. There are plenty of guides out there.

-r16 is what you use with 16MB Jaspers, -r256 is what you with 256MB Jaspers.

Your 3rd mistake was using "Jtag Tool". Your 4th was not patching the SMC for AUD_CLAMP before flashing Xell/ Xellous. You don't have to use the original wiring then switch to AUD_CLAMP, you simply patch Xell's SMC or use a Xellous preconfigured to use AUD_CLAMP such as those that Looky's has uploaded. "Jtag Tool" uses AUD_CLAMP & TRAY_OPEN for it's alt Xell/ Xellous/ FreeBoot, where as most people use AUD_CLAMP & DB1F1/alts.

Because Xellous is only in the first 80 blocks, I'm guessing you should be able to write back that 16MB dump and get a working console. I've checked on one of my 256MB dumps. I can do a -r16 read from the 256MB to a file plonk.bin, write Xellous, then write back plonk.bin using -w16 and the CRC matches that of the original 256MB NAND. So you have to wonder what that  "JtagTool" has done. Ensure you remove the power supply for 30secs after writing and ensure you've unplugged the LPT lead before powering on the console.

If it were me i'd check you are able to read the NAND,  check the flashconfig is still 0x008A3020, then do a 64MB dump and see what's what with the NAND.

I'm sure one of the more knowledgable people may help you better, if they decide to.

[mat989]

I am not sure how jtag tool works. But if you have a 16MB backup, then writing this back to your nand should solve your problem, because xell/xellous is only 2MB...

[Arakon]

Not if it was read as small block data.

[xbox360noob]

hey, how about that (don't do it right away, wait for comments by skilled members): just do a 66mb-nanddump using nandflasher 1.10. then flash XBR as it doesn't need the key beforehand. then try to boot into xbr's integrated xell, read the keys and build a freeboot from that. I think there are some tools like XBR2Freeboot. you should switch to "normal" jtag-wiring before doing the above mentioned, so you won't need to patch SMC to AUD_Clamp and you can see if you can get it running. You could try to read the keyvault from your 16mb-dump, it should be in there, even if you used the wrong read-nand mode.

[johnsmith]

Fear not, you still can get it to work

1st, you said you got a 256mb jasper... so you should have used nandpro lpt: -r64 nand.bin
You said you dumped it as 16mb.. still fine. Let's fix it..

nandpro lpt: -r64 nand.bin - run this command twice and compare the files.
when it match, run this command
nandpro nand.bin: -w16 nand.bin 16mbnandimagename.bin (where 16mbnandimage.bin is how you called your 1st 16mb nand dump)
With that, you should have your original filesystem back.
Rename nand.bin to stock.bin

Next step
Wire your jtag, regular way, not the fancy pants aud_clamp way.
Write xellous to your console using this command: nandpro lpt: -w16 xellous.bin 0 50
When it's done, read it back with nandpro lpt: -r16 verify.bin 0 50
Compare verify.bin against xellous.bin. If it matches... you're good to go
Take your lpt cable out of your pc, take the power supply from the back of the console.
Plug your dvd drive in and plug back your power supply
Power the console and you should get xellous. Remember Xellous only output images to vga or component.
Write down your cpu key.

Now download this script - www.tinyurl.com/fb4script.com and read the included txt file.
Feed it your stock.bin nand image, your cpu key
Follow the prompts and make sure to answer NO to the aud_clamp question.
When it's done, copy updflash.bin to a pendrive and use that pendrive to flash your console.
When it's done, remove psu from the back of the console, remove the pendrive, wait 30 seconds and put back your psu.
Power on the console. You should boot to the dashboard.
It worked? Cool.
Now it's up to you to choose to aud_clamp it or not.
If you choose to aud_clamp it, feed stock.bin to the script again.. and answer yes to the aud_clamp question.
Then flash it again using the pendrive and shut down the console.
Now modify your wiring to reflect aud_clamp requirements.
Assemble your console again.. and it should boot fine.
Good luck!

[bluespace77]

I'm not sure that's going to help...

I tried to help him on on XS, as he posted it there too. Turns out when he dumped his NAND, he had an ECC error at block... 0x0 in his 16MB dumps. He then went ahead flashing Xell using JTAG tool regardless, presumably "JTAG Tool" hides NandPro when it flashes so he may not have seen the error. I got him to write a single block to 0x0 and then dump that block, what he dumped matched what he wrote.

I've had an ECC error before (across multiple matching dumps), nulled the block and remapped to the reserved area after which the console worked fine. I'm presuming block 0 contains the bad block table, the boot block aswell as the headers; but Cory's post http://www.xboxhacker.org/index.php?topic=16056.msg118770#msg118770 made it sound like the flash controller runs though the spare area of each block and builds the table so you can have the blocks in any order. So I thought i'd give him a Xellous with block 0x0 nulled and remapped to the reserve area. That obviously didn't work, so I told him to come back here to seek the advice of Tiros/ Trancy/ Cory etc who know what they are doing.

Unfortunately he asked on that site which is a fountain of knowledge, S7. I did try to make it clear that there was no point flashing a donor Nand if he couldn't even get Xell to work. Unfortunately he took their advice and flashed one of Phonesy's Donor Nands, which state you the need CPU key to use with bincrypt which he doesn't have. I believe he did that without backing the rest of his Nand as you're talking over 5 hours to get matching 64MB dumps. He's also lost his SMC_config, he backed his config up as if it were a 16MB console.

Out of curiousity, XNandHealer has a field "First Block: 0x0000". Is it possible to get the Nand to start at block 1? which would then be the logical block 0? I tried tried writing Xellous to an erased 256MB file starting at block 8 and finishing at block 57, but FlashTool/ XNandhealer wouldn't have anything to do the resulting file. Anything else is beyond my limited knowledge.

[johnsmith]

Afaik.. if block 0 is busted you have to remap the contents to 3FF.. and xellous should boot fine
Any bad block under 50 must me remapped to xellous work before flashing it. So if block 0 is busted, remap it to 3FF, if block 1 is busted, remap it to 3FE.. and so on.
And that's it's for 16mb nands.. for bigger nands, each block is multiplied by 8. so block 0 should be flashed to FF8, block 1 should be mapped to FF0...

and no, I don't think the console will seek for the start of the data in the nand chip.

[bluespace77]

I know that, but block 0 is normally special. That's why block 0 is normally guaranteed to be error free,

I remapped it to 0xFF8, or rather I gave him a batch file which dumped the existing 0xFF8 (presumably it already contained data from an existing remap and he never had a full Nand dump); then flashed Xell's block 0 that location . He said it didn't work, also tried 0xFDO and didn't work either.

[xbox360noob]

Unfortunately he asked on that site which is a fountain of knowledge, S7. I did try to make it clear that there was no point flashing a donor Nand if he couldn't even get Xell to work. Unfortunately he took their advice and flashed one of Phonesy's Donor Nands, which state you the need CPU key to use with bincrypt which he doesn't have. I believe he did that without backing the rest of his Nand as you're talking over 5 hours to get matching 64MB dumps. He's also lost his SMC_config, he backed his config up as if it were a 16MB console.

after reading that I'm not willing to help him anymore. That's just a little too much :/

[jelle2503]

let's recommend this guy a new hobby then

hacking is not for him. (hacking meaning: reading a step by step tutorial, information plenty to be found online, yet still failing - miserably)

hacking is especially not for you if you're willing to take advice from 12 year old kids over at S7

[Gazcoigne]

heres a tip to fix it (not as hard as you guys all make out ffs)

you dont need your CPU key to fix it

all you need is a donor image that is made for the same type of mobo that you have (Jasper BB)

FB 0.4 images are zero paired, meaning they can be run on any mobo of same revision, without having to be encrypted with the native CPU key.

IE take someone elses updflash.bin that is compiled using thier own CPU key, and flash it straight to your mobo, (moving any bad blocks to suit your NAND chip beforehand)

It will load perfectly, and if you run XELL, you will get your CPU key from within the CPU die,not the donor one that the donor image is encrypted with.

then if you are really obsessed you can buiold your own image using your CPUkey etc (which is uneccessary TBH)

perhaps someone kind enough with a Jasper BB image will give you it, i would if i had one, i only have SB images.

[bluespace77]

How is a Donor Nand going to work if he can't even get Xell running by straight flashing Xell?

Xell is the easiest thing of all to get working. I'd have thought that until he solves the reason as to why Xell will not boot, neither will a donor.

Baby steps...

[Gazcoigne]

How is a Donor Nand going to work if he can't even get Xell running by straight flashing Xell?

Xell is the easiest thing of all to get working. I'd have thought that until he solves the reason as to why Xell will not boot, neither will donor.

Baby steps...

im not concerned about the fact he couldnt solder correctly, thats a simple thing to fix IMHO.

im merely showing him that all is not lost because he lost all his orig data.

everyone was like "f*** im not going to help him because of how much he did wrong" whats that all about?

ive shown him how to get the console booting again.

its up to him to learn how to solder correctly. once he does that its piss easy to fix.

and if the issue is bad blocks then he needs to figure out allthe blocklocations and remap them manually before flashing.

to the OP, stop being a nublet and depending heavily on single click apps that are $#!t and for noobs and cause more problems than they solve.

read up on how to use nandpro, and buy yourself a USB programmer, and a multimeter.

flash the donor image, then set to solder the JTAG points CORRECTLY.

it will boot once you have put the wiring in place correctly.

and for god's sake make sure that you check the donor image to see what SMC config its using (IE where the wires go on the mobo) as some people use alternative wiring that is evident if you check the SMC, or even ask the donor.

if yor boardis set up for aud_clamp, then change the SMCof the donor image to match before flashing.

[bluespace77]

His soldering isn't really that bad, nothing like those who for lodge the resistors in the back of their parallel port etc.

http://img.photobucket.com/albums/v228/Sheriff01/IMG_20110121_154806.jpg
http://img.photobucket.com/albums/v228/Sheriff01/IMG_20110121_154837.jpg

Just a case of flash first, think later.

I did get him to move the diode to the other end of the cable as per Tiro's recommendation, and that's where he had it when he did his 16MB dumps.

[Gazcoigne]

personally i have the resistors and diodes soldered to the mobo rather than the LPT end

those pics look ok for soldering, what about the JTAG wiring?

thats the main issue, not the SPI hookup.

[johnsmith]

Gazcoigne: Using a donor image (wich means a donor keyvault) in current fb will result in a disabled dvd drive.
Meaning no game will run from the drive.

That's why I *ALWAYS* try to make the user recover as much as possible from his original nand.
*IF* he flashed something bad and his block 0 is bad due bad writting (not a physical damage) I'd recommend him to run nandpro lpt: -e256 and see if nandpro reports the physical errors.
Then use that info to do the remap in the donor nand.

Again, I never said it isn't going to work

[Gazcoigne]

Gazcoigne: Using a donor image (wich means a donor keyvault) in current fb will result in a disabled dvd drive.
Meaning no game will run from the drive.

of course the dvd drive wont work - it has the original key. quit being a douche, the fact that the dvd drive wouldnt work is obvious.

its very easy to open the donor nand in 360flashtool and extract the key, and patch it into his drive.

this fix prob takes about 20 times less time and effort than trying to ressurect his orig files.

why worry about original files when a donor can fix it easier and faster?

surely you dont care about getting onto live?