Jtag E71 probably bad blocks but which?

[noob6969]

This console has been bugging me for ages. I built it for someone ages ago with XBR and I remember having to remap the bad blocks for it and its been fine, I got it back to update to freeboot and so far have not been able to get it to work, during boot it starts the swirl then goes to E71. Putting the original image back in there works fine.

Its a 64M image Jasper.

Flashtool reports a little bit of weirdness:

It reports bad blocks at 4 locations but then only finds 2 of those bad blocks relocated

Note: Bad Block ID0x00AE [offset 0x166E000]
Note: Bad Block ID0x00AF [offset 0x168F000]
Note: Bad Block ID0x016A [offset 0x2EAA000]
Note: Bad Block ID0x016B [offset 0x2ECB000]

Block ID 0X016B found @ 0x1FC [Offset: 0x0417C000]
Block ID 0X016A found @ 0x1FD [Offset: 0x0419C000]

I have tried unmapping the extracted nand then using a tool (peanuts tried pig too) to produce freeboot then remapping and writing back into the nand, the result is always the same, the box boots xell no problem, but locks up i imagine on the second kernel
I tryed using xellous and updflash.bin to write the unmapped freeboot and allowing it to use its own remapping to remapp the blocks on both a unmapped and mapped image, neither worked. This thing is driving me nuts

What I do notice is the bad blocks were found at 1FC and 1FD does that imply there is data in 1FF and 1FE that flash tool has not picked up? I tried mapping the data from 0AE and 0AF into 1FF and 1FE (both ways because thinking about which way they go in does my head in)but that did not work either.

During the read process I get a whole bunch of read errors, when I write back I only get two locations I can't write too (which I assume is the two flash tool found)

the read errors are as follows using a USB reader:

Error: 250 reading block 578
Error: 210 reading block 579
Error: 210 reading block 57A
Error: 210 reading block 57B
Error: 210 reading block 57C
Error: 210 reading block 57D
Error: 210 reading block 57E
Error: 210 reading block 57F
Error: 250 reading block B58
Error: 210 reading block B59
Error: 210 reading block B5A
Error: 210 reading block B5B
Error: 210 reading block B5C
Error: 210 reading block B5D
Error: 210 reading block B5E
Error: 210 reading block B5F

I have been looking for a way of translating what flash tool reports as bad locations into these locations. But at least knowing if any of the above blocks are actually important ones would be a start.

Apologize in advance if this answer is staring me in the face, I have done the appropriate searching and spend enormous amount of time trying to fix this thing, I am a hardware guy and this looks like a software problem

[l_oliveira]

Something that would save you an ENORMOUS amount of time is ditch the Big Block flash in it (you already have the keyvault and config block extracted, right ?) remove that flash chip, take an flash chip from an Xenon console and put on it then move the resistors close to the flash chip to match the setup that they are into the older board (be it a xenon, zephyr, or falcon/opus) so in the end you will have an Jasper SB console which is way easier to deal with.

[cory1492]

noob6969, have you tried the built in remapper that fbbuild has?

Error: 250 reading block 578 << *8 = 1 bad block on big block (0x578/8 = 0xAF)
Error: 250 reading block B58 << *8 = 1 bad block on big block (0xB58/8 = 0x16B)
Those are your actual bad blocks, according to your log.

[noob6969]

Not tried fbbuild, I will give that a birl as soon as xbins is not dead any more, won't give FTP access right now so I can't get the dash files, I was going to steal the files from jtag tool but I suppose thats asking for trouble.

funny xellous look like it was doing its thing remapping the blocks, quick question though for xellous to work would the updflash.bin need to be unmapped, ie assume there were no bad blocks? or would it need to be remapped? I kind of reasoned unmapped because when you do a standard update on a box the file can't be mapped because all bad block nands can be different so the update process has to cope with bad blocks on the fly.

Can you think of a reason why the bad blocks were mapped to 1FD and 1FC, why would they not be mapped to 1FF and 1FE? I kind of think the data in 1FF and 1FE is critical some how but I don't know where to remap it back to.

Anyway next step is fbbuild , for the record jtag tool and best pig both gave identical results.

I have some xenon nands around but i don't really fancy changing it, besides one day when I get some micro seconds I might decide to fix some of these things that are long gone GPU units that might actually be jtagable.

[cory1492]

There are a bunch of blocks at the end of NAND reserved for remapping bad blocks; the way the controller works it doesn't matter what order most of the blocks are in, just that they be labeled with the correct order.

As to your issue, most likely: one of the "bad" blocks is software marked as bad, xellous or any other flash program doesn't deal with those well if you don't 0x0 fill the original location after remapping. fbbuild will take a dump of your current (working) machine when it creates the new image, with the right options set in the ini file it will replicate the working/existing remapping, as well as directly take smc/smc config, your settings, and keyvault. I'm not sure if any of the 'easy' or 'one click' tools cause it to do this for you, I've never used them.

[noob6969]

sorry meant to close this off ages ago, thanks for the advice, the moral of the story is when the easy way fails (despite doing a lot of consoles) fbbuild solved the issue. Ironically considering the time I spent trying to use the easy tools I would have saved a awful lot of time if I had of used fbbuild in the first place. Guess serves me right for being lazy,