ANSWERED Errors reported by 360 Flash Tool not reported during nand dump and viceversa

[digant]

Hi

I read the post about the need to manually remap a block in case a read error is in range 0x00..0x4F (area used by xell reloaded).
My case seems to be never occurred to anyone (I didn't find any post on that).
I have a Jasper Arcade (thus without any HDD) 512MB with CB6751 and I installed TX CoolRunner with the 68nF capacitor between GND and A. Before starting the dump of my original nand, I verified all the solderings were ok (using multimeters etc...). Everything was ok, so I started to dump the nand.
Below you can see the errors I got in all the dumps I made (I made 8 dumps and they were all the same in a binary comparison).

Block Size: 128KB Block Linits: 0x000000..0x000FFF
File: nand_dump_1.bin
Reading
Error: 250 reading block 188
Error: 210 reading block 189
Error: 210 reading block 18A
Error: 210 reading block 18B
Error: 210 reading block 18C
Error: 210 reading block 18D
Error: 210 reading block 18E
Error: 210 reading block 18F
Error: 250 reading block C58
Error: 210 reading block C59
Error: 210 reading block C5A
Error: 210 reading block C5B
Error: 210 reading block C5C
Error: 210 reading block C5D
Error: 210 reading block C5E
Error: 210 reading block C5F
0FFF

As you can see below, using 360 Flash Tool I saw instead that block 0x0031 and 0x018B were remapped to 0x01FF and 0x01FE.

Note: Bad Block ID 0x0031 [Offset: 0x00651000]
Note: Bad Block ID 0x018B [Offset: 0x032EB000]
-> Block ID 0x018B found @ 0x1FE [Offset: 0x041BE000]
-> Block ID 0x0031 found @ 0x1FF [Offset: 0x041DF000]

=== Analyzed successfully =================================

So 360 Flash Tool reported an error on block 0x0031 although I didn't have any read error on that block. No error was instead reported fot block 0x0C58.

I decided to restore the original nand and I got errors writing on blocks 0x0188 and 0x0C58 (the two blocks where I verified read errors). The error code reported by nandpro was 202.
After that, with jtag tool I created and flashed Xell Reloaded. I didn't get any error writing on block 0x0031, but xell didn't boot (the green led on coolrunner was flashing all the time every 5 seconds). I decided to use Multi Builder 0.7 (as reported by many users). During creation, It reported to me that CB6751 was not supported for RGH and thus a donor CB6750 was used instead. I flashed xell, and this time it booted just in few seconds.
Once retrieved the CPU key, I used again Multi Builder 0.7 to create a retail image. I flashed the image using rawflash (it automatically remapped blocks 0x0031 and 0x018B. I verified that the console booted only using the CR while it didn't boot without CR (when the switch is on PRG).

I kindly ask you (and the authors of many posts in this forum) if:
1) is it possible (it's not a real problem) that block 0x0031 was reported by 360 flash tool as remapped while no read error was encountered on that block? Furthermore that block was mapped on block 0x01FF. According to Martin's post, the first usable block should be 0x0FF8 on a Jasper 512MB.
2) is it ok that block 0x018B is remapped while I got a read error on block 0x0188 (I mean the first error occurred in 0x0188 and not in 0x018B)?
3) is it possible (thus the final RGH image is OK) that you get a read error on a block (in my case 0x0C58) that is not a real problem (it is not reported by 360 flash tool and thus not remapped during flashing of a retail image or RGH image)?
4) is it ok that the retail image boots only with CR?
5) is it possible to restore the original nand only writing the original .bin file (thus obtaining write error on blocks 0x0188 and 0x0C58) or maybe something else has to be performed in order the original dash boots without any problem? I tried to restore the original nand but on boot I got error E79 (thus a problem with HDD or fyle system corruption)

I hope you can provide me an answer even for only one question

thanks

 

[Martin C]

BB NANDs work differently to SB NANDs.

A 16MB NAND is pretty much all used. In other words, there's no room for breathing space.

A 64MB NAND has 48MB of padding. Addresses in the upper 0x0Cxx range will be padding and therefore won't need to be remapped as they're not used.

Conversely, it's possible to have a remapped block but the block be read/writeable. Trust 360 Flash Dump Tool as it will be more accurate than what NANDpro is.

You're right about FF8 / 1FF confusion too. I'll edit my post as I believe it can be either/or.

Finally, retail NANDs with a CB of 6751 are tricky, because most tools (including multi_builder) don't build retail NANDs with 6751, only 6750. I had one to do today which I'm just done with. I needed to use ggbuild at commandline and edit the filelist.ini to include the cb_6751.bin including its CRC32. All up and running now and confirmed that updates are also working on it too.

Finally, E79 is common if you have a bad write. Flash XeLL back and with your CR connected, use rawflash to write the image back to the NAND.

 

[digant]

Thanks Martin.

Let me summarize your staments in order to avoid any misunderstanding (as you already understood I'm not english).
So for the first 3 bullets of my post, you say it's ok.
For bullet 4) you say that the retail image should boot without CR but in my case (CB6751 converted to CB6750) Multi Builder currently does not correctly create the retail image (you worked on that problem and you were able to boot also a CB6751 converted to CB6750).
Finally, the flashed original nand didn't work due to the errors during writing (using nandpro). In order to solve the problem, I have to use rawflash also to restore my original nand.
Did I understand correctly?

Note: maybe when you said "A 64MB NAND has 48MB of padding" you meant 16MB of padding (from Cxx to FFF they shoul be 16MB).

Thanks again for your support and sorry for my previous hijacking (that was not my intention)

 

[Martin C]

Yes, that's correct.

The 48MB of padding is merely an estimation.

64MB is what's needed for a full dump of a BB NAND, then deduct the normal 16MB of a SB NAND. There's a better way to calculate it, however the only thing to bear in mind is what 360 Flash Dump Tool says about it.

 

[digant]

thanks again Martin.
I think that a lot of things you explained in this post (if not already explained in other your posts) can guide many people to avoid errors and to be more confident in what they are doing.