Print

[SoloStyl]

FlashConfig:01198010 is for 16meg Flacons I beleive

FlashConfig:00AA3020 is for Jaspers 256/512

For now, we can only run XELL in order to get our CPU Keys

maybe in a few days or weeks(who knows,just be patient) we will be able to run freeBoot,XBR,Homebrew,etc

The most important thing so far, is that WE CAN get the CPU Keys, something impossible for years

in thee future with Jaspers 256 or 512 memory, who knows , we might be able to install different kernels without the use of a Cygnos or similiar chip(hopeful (IMG:style_emoticons/default/smile.gif) )

Just get your NANDs backed up and safe, get your CPU keys, and wiat for great things to come

[xxpittbullxx]

Theses are The Correct Flashconfigs


For Xenon/Zephyr/Opus/Falcon and Jasper(16MB NAND)
FlashConfig: 01198010


For Jasper (256MB)
FlashConfig: 008A3020
256MB NAND Detected


For Jasper (512MB)
FlashConfig: 00AA3020
512MB NAND Detected

If You Get Something Different Then Something Is Wrong With Your wiring

[Chemodile]

QUOTE(Boke @ Dec 12 2009, 10:10 AM)

Here is the log from my 512mb jasper.
I dumped 512mb twice. Both matched.
Then I did four 2mb dumps. All matched.

Thanks for this, very helpful to have something to compare my log to. Looks like I'll be alright with 00AA3020. Do you know which LPT mode you were using? I'm using SPP now but it'd be good to know which mode I should try next if that doesn't work out.

QUOTE(xxpittbullxx @ Dec 12 2009, 07:46 PM)

Theses are The Correct Flashconfigs
For Xenon/Zephyr/Opus/Falcon and Jasper(16MB NAND)
FlashConfig: 01198010
For Jasper (256MB)
FlashConfig: 008A3020
256MB NAND Detected
For Jasper (512MB)
FlashConfig: 00AA3020
512MB NAND Detected

If You Get Something Different Then Something Is Wrong With Your wiring

Just what I was looking for, thanks.

I've got a dump that's been in progress since earlier this morning and seems to be going well. Lots of errors 210/250, but I suspect (hope) that they're just bad blocks. They match up with my partial first dump, so that's a good sign I suppose.

No more 310 errors after shortening my cable to about 15-20cm, repositioning the diode from the LPT connector to the board, and upgrading nandpro to 2.0b. Lots of potential factors there, but I suspect it was the cable length that fixed it. It was 35-40cm total before I cut it down, but the inner cables aren't shielded too terribly well and there may have been crosstalk between the twisted pairs. Anyone know for sure what error 310 indicates?

[kly69]

QUOTE(Chemodile @ Dec 12 2009, 05:36 PM)

Now that more people are dumping the 512mb Jaspers can anyone shed some light on this? I get FlashConfig:00AA3020 no matter what LPT mode I use and the free60 wiki says it should be FlashConfig:01198010.

I've rechecked and resoldered everything, significantly shortened my cable, and moved the diode from the d-sub connector directly onto the board. Nothing gets me a FlashConfig value other than 00AA3020.

It seems to read ok, but given how long it takes to fully dump a 512mb NAND I'd like to make sure I'm not wasting my time.

Here's the log from my first attempt:

I stopped it at 35E4 after seeing all the errors. (Is it normal to have that many bad blocks on a larger nand? It seems to me if a 16mb nand having 1-2 bad blocks is acceptable then a 512mb could have quite a few more.)

Since then I've resoldered everything, shortened the cable length, moved my diode from the LPT connector to board, and switched to NandPro 2.0b which adds the message "Configured for Large Block Nand." Hopefully less errors this time around, but in the meantime can someone confirm/deny whether FlashConfig:00AA3020 can produce an acceptable dump?

I had that many errors my first time but one of my solder connections came loose. Make sure you check your connections with a multimeter.

[Gsus89]

QUOTE(Ranger72 @ Dec 12 2009, 10:21 PM)

It took about 18 hours to dump my Jasper 512 nand.

I did get about 8 read errors and they was at the same location for each of my 2 dumps so I figure this may be normal. Both hash checks are identical so pretty sure I got all the dump.

Now it is a waiting game I guess.

The errorrs were at the same adresses? Did you compare both nands with Total Commander after you got them?

[Ranger72]

QUOTE(Gsus89 @ Dec 13 2009, 11:18 AM)

The errorrs were at the same adresses? Did you compare both nands with Total Commander after you got them?

The errors was at the same location each dump. BUT Total Commander says that there are 507 differences. So I guess I am going to need to do another 18 hour dump.  

[Chemodile]

Finally got my second dump and totalcmd found 3 differences. (IMG:style_emoticons/default/sad.gif) What are the chances that I'll be ok with either of these two if I'm just using it to zero out my latest secdata.bin? Dumping a third one in the mean time. Be back in 16 hours! (IMG:style_emoticons/default/cussing.gif)

[SoloStyl]

Ahh, so you're trying to uncripple the HDD? there are a bunch of new tools for that

i used 360HDFRv1.03, FindSecDatav0_5, and NANDPro20

shouldn't be hard at all , lemme know if you need help.   you can also read a bunch of posts arround that make it real easy for anyone to do

the one i did is a Falcon Board, but Jasper uses the exact same method, just takes a LONG time for NAND reads

when you're ready to write your NAND back it will only take a couple of minuets, since you dont have to re-write the whole 512meg NAND, you just need to overwrite the Banned secdata.bin with a previous unbanned one

those programs will list the unbanned secdata.bin for you and then use NANDPro to overwrite to those block addresses

This post has been edited by SoloStyl: Dec 14 2009, 06:36 AM

[Chemodile]

QUOTE(SoloStyl @ Dec 13 2009, 09:34 PM)

Ahh, so you're trying to uncripple the HDD? there are a bunch of new tools for that

i used 360HDFRv1.03, FindSecDatav0_5, and NANDPro20

shouldn't be hard at all , lemme know if you need help.   you can also read a bunch of posts arround that make it real easy for anyone to do

the one i did is a Falcon Board, but Jasper uses the exact same method, just takes a LONG time for NAND reads

when you're ready to write your NAND back it will only take a couple of minuets, since you dont have to re-write the whole 512meg NAND, you just need to overwrite the Banned secdata.bin with a previous unbanned one

those programs will list the unbanned secdata.bin for you and then use NANDPro to overwrite to those block addresses

I'm not too worried about automating the process, hex doesn't scare me. Plus I'd rather do it manually than use more programs I'm not familiar with. Good to know that those work though, I was under the impression they didn't support big block nands yet.

I'm currently working on a third dump while I go through my first two in Hex Workshop. Since I'm only going to need to find and null the latest secdata.bin, I figure the three discrepancies found by totalcmd are of little importance as long as they're not affecting any of the sectors containing secdata.bin. This is of course assuming I don't screw something up so badly that I need a full backup.  

Here's something I found interesting from the first file: of the 10 instances of secdata.bin, 9 of them have the same datestamp. The 10th has a higher value so it's probably the one I need, but does it seem odd that the other 9 are all from the same day? Maybe it keeps the 10 most recent backups regardless of how many times it's been modified, and all but one of mine are factory defaults? I only had the console about 5 months before it got banned, so this is my best guess.

This thread is pretty off-topic now but I figure it's as good a place as any to discuss Jasper512-specific nand dumping.

[SoloStyl]

As to you 10 secdata.bins:

everytime you turn on the xbox without a DVD drive, or fan, or try to run a game off the HDD installed on it, it will write a new secdata.bin everytime

i heard some people had the same problem

you just need to find the most recent secdata.bin and either null it or even better patch it

Patching method is prefered because it basically just copies values from an UNBANNED secdata.bin

Alot of useers compained that Nulling out the most recent secdata.bin would just give them errors or RROD's

see which method works for you though, nulling or patching

[torne]

QUOTE(Ranger72 @ Dec 13 2009, 04:43 PM)

The errors was at the same location each dump. BUT Total Commander says that there are 507 differences. So I guess I am going to need to do another 18 hour dump.  

If the differences are *inside* the error blocks then that's fine. Bad blocks don't always read as consistent data.

[Martinchris23]

QUOTE(xxpittbullxx @ Dec 13 2009, 03:46 AM)

Theses are The Correct Flashconfigs
For Xenon/Zephyr/Opus/Falcon and Jasper(16MB NAND)
FlashConfig: 01198010
For Jasper (256MB)
FlashConfig: 008A3020
256MB NAND Detected
For Jasper (512MB)
FlashConfig: 00AA3020
512MB NAND Detected

If You Get Something Different Then Something Is Wrong With Your wiring

Jasper 16MB responds with a flashconfig of 00AA3020.