JTAG Jasper 6723 16MB to 14699 -> Xell boots, Dash doesn't

[ohnoes]

Hey there,
i have the following Situation.
Console is a Jasper 16MB with CB6723 on Dash 13599. Wiring is aud_clamp. There is no backup of original NAND (ye, bad, i know), only of the created freeBoot-Images.
I wanted to Update to 14699, so i did as usual: dump current nand via flash360, fire up rogero's multi_builder 0.7, select the settings for jasper 16mb->jtag-> aud_clamp->done.
Then I flashed the image via rawflashv3. Rawflash told me Block 0043 could not be written (bad block on NAND), nevertheless, after a power-cycle Xell boots just fine (via eject), but Dash is not booting: No ROL, only black screen.
So i thought "ok, block 43 is bad, thats the xell area, so i have to remap it". Did exactly this. Extracted block 43 off the created 14699 Image, and put it at position 3FF. Then reflashed the image (i could've flashed the one block only, i know^^) and hoped for the best, but: same as before, Xell boots, Dash does not.

For testing i then flashed back the image i dumped earlier, and surprise : xell boots, dash does not = oO???

No matter what older Image i flashed, xell does always boot, but Dash does not.

I then extracted the smc off the 14699 Image, and ran it through smc_util via the "io" switch, for the rol-fix. Imported the new file, flashed the Image-> same thing as before.

Has anyone an idea what could cause this, and how i could fix it?
Maybe someone got a Jasper CB 6723 16MB donor Image for me to test around with, couldn't find one?

Anyways, thanks in advance for any help.

regards

 

[Martin C]

attach your nandflash.log file from Multi_builder.

Have you also tried to reflash using XeLLous and renaming nandflash to updflash.bin ?

 

[ohnoes]

Yes, i have tried flashing via Xellous.

log is attached

Thanks for looking into this

 

[Martin C]

How long have you left the console for after trying to boot?

 

[ohnoes]

few minutes, waiting for a possible 0022 or E79, but nothing happens.
Just because i was out of ideas, i also glitched the console, created another image and same thing:
xell boots, and i can tell by the resetting stopping that the console "boots" but there is just a blackscreen and no ROL.

 

[Martin C]

Tell me what commands you ran to remap the bad block.

 

[ohnoes]

"nandflash.bin" being the created image, copied to the folder where nandpro is located, and block 43 beeing the bad block on the nand:
nandpro nandflash.bin: -r16 43.bin 0043 1
nandpro nandflash.bin: -w16 43.bin 03FF 1

Xellous recognizes that i have manually remapped blocks and writes the complete 0-3FF range (not as usual xellous-flashing only to block 3E0).

maybe a noobish question, but could it be that the console searches for the bad 43 block in a specific position (the bad nand block beeing a "factory-default" one). cause i tried just putting the 43.bin in all reserved blocks (3e0-3ff), and of course that did not work.

also shorted the nand as if it was not responsible, then deleted it and reflashed. nothing helped.

would a donor cb7623 16mb jasper image maybe help?

 

[Martin C]

create the image again and flash with XeLLous but DON'T manually map anything. The NAND doesn't report the bad block- it comes from the southbridge. Let me know if XeLLous recognises the bad block and maps it. Try it after this.

 

[ohnoes]

as expected xellous writes from 0-3E0, since there is no manual mapping.

Xellous did not report back the bad block, as rawflash and nandpro did...what does that mean?

Everything's like before; i waited 2min again to see if an error appears, but just blacksreen and no rol.

wtf is going on with this console

On the 6723 donor image question: could that help in any way?

Thanks for your time so far

 

[Martin C]

It's possible you may have more than one bad block, but it's not being picked up.

Try this.

nandpro usb: -r16 bb1.bin 3fe 1
nandpro usb: -r16 bb2.bin 3fd 1
nandpro usb: -r16 bb3.bin 3fc 1

Open each bin file in a hex editor and see if there's any data in there. If you've not erased the entire NAND at any point, it should still contain data.

I don't know if a donor nand will help you at the mo.

 

[ohnoes]

i did erase the nand at some point

but i thought if it was bad blocks, they have to be in the last image that worked, so i extracted blocks of that image (freeboot 13599),and all blocks for the reserved area (3E0-3FF) contain data

does that help me now Oo?

EDIT: just flashed that image via xellous, and it tells me it didnt find any remapped blocks in the reserved area Oo

 

[ohnoes]

could replacing the nand maybe save the console, i got a dead falcon lying around...?

 

[Martin C]

It's not the NAND.

Run your working image (if you still have one) through multi_builder and make a retail image out of it. Flash this to the console to see if it works. Don't worry about the dashboard version being newer.

If it works, use this retail image to build a JTAG one.

 

[ohnoes]

i created the image and got the error warning : "hacked smc found, you should use a clean smc for retail image", the image was build anyways.
also the created image now has a cb of 6750 instead of 6723, is this a problem?
i flashed it with xellous, and the result was the box behaving like a glitched one : it resetted in about 5 secs periods (??), and then gave me a 0022 rod.

 

[ohnoes]

anyone got a spare, clean jasper 16mb cb 6723 donor image for me ?

don't know what else i could try now....

 

[Martin C]

Just so I'm clear, is this a JTAG or an RGH?

 

[ohnoes]

JTAG

 

[Martin C]

Did you check your LDV before creating the retail? There's a sticky on it in my sig.

 

[ohnoes]

yeah i thought about that too since the 0022 usually comes up with wrong ldv.
the ldv in the retail image is 2, but fuse sets 7&8 counted 1 f, so that should be ok, right ?

 

[ohnoes]

I found a donor image now. Injected my kv and build retail 14699 from it (with multi_builder).
Since xell tells me the LDV is 1 (rows 7&8 count one f in total), i set multi_builder to set LDV to 1.

Box is resetting 4 times in 5 sec intervals, then gives me 0022 rod.

Then i created the same image with ldv 12, same result.

The r6t3 is desoldered, and i understand this prevents the console from blowing the efuses, but is a rows7&8 f-count of 1 realistic?; i'm just asking because if for retail images the image-ldv has to match the f-count in rows7&8, then why is my console giving me 0022 on the ldv=1 image?