ANSWERED Jasper 512MB E71 after update to 14699 dash

[Martin C]

One of them, yes (J1D2). the other one would be a problem.

If you're looking to solder and you're not sure, just practice on an old PCB first!

 

[MadCabbit]

Would this be using something like xnandhealer, then?

---------- Post added at 04:56 ---------- Previous post was at 04:56 ----------

Would I be better off picking up a coolrunner qsb as well? If I'm going to solder this, I want to do it in a way where I won't have to do it again

 

[Martin C]

You shouldn't need to use anything apart from nandpro at the moment.

Did you keep a copy of the NAND which was there before you tried to update?

 

[MadCabbit]

Yes. I have both the orignals sent me, and the nand I read before trying to update.

 

[Avinitlarge]

Ive seen E71 alot lately when I do a dash update from a USB stick. When it comes up with E71 I unplug the USB stick, reboot the console and everything is ok.

 

[MadCabbit]

I also noticed in the logs, even though 360 flash tool didn't see bad blocks on the nand that I initially read myself, the log from xebuild showed it trying to remap the three bad blocks. Of course, it was trying to remap 0x16A to 016B, which is also a bad block. I'm not sure why it was trying to remap a bad block to another bad block.

block 0x16a was remapped to block 0x16b, entering remap instance 1
block 0x16b was remapped to block 0x1fe, entering remap instance 2
block 0x150 was remapped to block 0x1ff, entering remap instance 3
done!
cleaning up stray remaps
done!
--remap summary--
0: source: 0x016a dest: 0x016b
1: source: 0x016b dest: 0x01fe
2: source: 0x0150 dest: 0x01ff

---------- Post added at 05:06 ---------- Previous post was at 05:04 ----------

Ive seen E71 alot lately when I do a dash update from a USB stick. When it comes up with E71 I unplug the USB stick, reboot the console and everything is ok.

Unfortunately, no matter how many times I reboot the console, I get an E71.

 

[Martin C]

Once you have a NAND-x connected you can try all manner of manual flashes to resolve this. Even to the point of erasing the first 64MB of the NAND and re-writing the stock to make sure it boots.

 

[MadCabbit]

Once you have a NAND-x connected you can try all manner of manual flashes to resolve this. Even to the point of erasing the first 64MB of the NAND and re-writing the stock to make sure it boots.

Any recommendations on a decent soldering iron? I'm working on a limited budget, can't get anything too expensive.

 

[Martin C]

A 30W iron with good solder and flux will do the job.

Like I said, best to practice first!

 

[tingedace]

This is definitely an interesting one!

It’s possible that a part of the nand has become corrupt since the original RGH was done, hence one or more extra bad blocks showing up.
I had a slim stuck in an update loop because of this and only RGH’ing it got it going again.

For completeness, I’d like to see what XNandhealer makes of both the original images. Do they match and can you post a pic of the Info Tab screen?

However, let’s assume you have 3 physical bad blocks on the NAND: 0x150, 0x16A and 0x16B.
I can’t work out if you’re saying the original dumps have bad blocks or not. I’m going to assume not.

In that case, build the 14699 glitch image from your original nand using Xnandhealer or Multibuilder and the resulting glitch image should have no remapped blocks.
Please check that’s the case by inspecting the xeBuild output log.

Now you can manually remap the blocks of the image. Remember that this is a big block NAND and nandpro uses small block notation, so you need to multiply everything by 8:

Read the blocks to be remapped:

nandpro nandflash.bin: -r64 150.bin A80 8
nandpro nandflash.bin: -r64 16A.bin B50 8
nandpro nandflash.bin: -r64 16B.bin B58 8

Write the blocks to their new locations:

nandpro nandflash.bin: -w64 150.bin FF8 8
nandpro nandflash.bin: -w64 16A.bin FF0 8
nandpro nandflash.bin: -w64 16B.bin FE8 8

Ideally we’d also want to zero out the corresponding bad locations, although may not be needed.
In a hex editor, open nandflash.bin and zero out:

2B50000->2B70FFF (0x21000 bytes) – block 0x150
2EAA000->2EEBFFF (0x42000 bytes) – blocks 0x16A and 0x16B

Then use Flash 360 to flash the image back to your NAND.

 

[MadCabbit]

Before I try this, let me post the info, and summarize the bad block info I've already done.

It seems I'm getting wildly different results from three different programs on these nand dumps.

This is the original dump. Both files give the same results as they should, they are the same file, the md5sums are identical.

http://i225.photobucket.com/albums/dd134/ryocabbit/nandhealer1.png

As you can see, it shows no bad blocks. 360 Flash Dump Tool, however does.

http://i225.photobucket.com/albums/dd134/ryocabbit/nand1.jpg

It shows the original two bad blocks.

Now, I also read a flash from the console before I tried updating (glitch nand, pre-14699):

http://i225.photobucket.com/albums/dd134/ryocabbit/origflash.png
http://i225.photobucket.com/albums/dd134/ryocabbit/nandhealer2.png

Both 360 Flash Tool and NandHealer show no bad blocks, but xebuild shows them when it was building the image. From the log:

block 0x16a was remapped to block 0x16b, entering remap instance 1
block 0x16b was remapped to block 0x1fe, entering remap instance 2
block 0x150 was remapped to block 0x1ff, entering remap instance 3
done!
cleaning up stray remaps
done!
--remap summary--
0: source: 0x016a dest: 0x016b
1: source: 0x016b dest: 0x01fe
2: source: 0x0150 dest: 0x01ff

Lastly, here is what NandHealer shows on all the new flashes I have been trying:
http://i225.photobucket.com/albums/dd134/ryocabbit/nandhealer3.png

And 360 Flash Tool:
http://i225.photobucket.com/albums/dd134/ryocabbit/updflash3.png

 

[MadCabbit]

And once again, building in XNandHealer, it only gets two of the three bad blocks, since the third appeared when I started writing:

****************************************************

bad block at 0x150 (raw offset 0x2b50000), block ignored
bad block at 0x16b (raw offset 0x2ecb000), block ignored
block 0x16b was remapped to block 0x1fe at remap instance 1
block 0x150 was remapped to block 0x1ff at remap instance 0
done!
cleaning up stray remaps
done!
--remap summary--
0: source: 0x0150 dest: 0x01ff
1: source: 0x016b dest: 0x01fe
-----------------

It doesn't know about 0x016a.

---------- Post added at 18:12 ---------- Previous post was at 18:05 ----------

So a big block Jasper needs it multiplied by 8? I don't thnk Martin noticed, he wasn't having me do that.

 

[MadCabbit]

Okay, given the big block issue, I set noremap=true so I could follow your instructions. I tried flashing first without zeroing anything out and... it works. No USB or HD plugged in and the new metro dash loaded! Guess I have a nandx coming that I don't need right now. Oh well, it will probably be helpful in the future.

---------- Post added at 18:27 ---------- Previous post was at 18:26 ----------

Thanks to everyone, its nice to finally have this fixed.

 

[tingedace]

Glad to hear it. And yes, x8 for big blocks.
I'm intrigued about the first image you posted though.
Any chance you could upload the nand image somewhere so I could take a look?

 

[Martin C]

Sorry, I didn't specify x8 as I thought that nandpro did it automatically when a NAND/VNAND was detected with a BB controller. It matters not now, but at the start I *was* going to get you to remap with x8 and changed my mind - d'oh!

Glad you got it sorted though.

 

[MadCabbit]

Glad to hear it. And yes, x8 for big blocks.
I'm intrigued about the first image you posted though.
Any chance you could upload the nand image somewhere so I could take a look?

the nand1.bin, the original dump the installer dumped for me? I can, but can you recommend a good place to upload the file. Curse Megaupload being taken down, that just makes me rage. :mad2:

 

[tingedace]

Yes, the original one you were sent. Hypersend should work. I'll PM you details, thanks.

 

[tingedace]

Thanks for uploading the image. I ran it through Xnandhealer and it shows the 2 bad blocks correctly as expected:

Is this the same nand image you used to create your first screenshot i.e. nandhealer1.png? I don't understand how you managed to get this (your image):

 

[MadCabbit]

I think I see what it is now. Sometimes when selecting a nand image, it doesn't fully scan it. If it does, its fine. When it doesn't (when the analyzing window doesn't pop up with the progress bar) it does this.

---------- Post added at 16:27 ---------- Previous post was at 16:25 ----------

When I load it this time, it actually scans the working directory automatically when starting up and it works now. However, if I select the same nand under "From file", it doesn't scan it properly and it shows no bad blocks.

 

[tingedace]

Thanks for confirming. I can't replicate the behaviour you're seeing. If you can repeat this, can you tell me the exact replication instructions?