few nand-x questions

1moment

Junior Member
Oct 6, 2011
18
0
sorry about the noob-ness, cannot find a guide/tutorial/manual that answers this if anyone could point that out to me i would appreciate it. What are the other 2 connectors on the nandx for? the large one on the bottom and the 6 pin one on the top of the right hand side as well as the push button on the top? Also for the qsb's for nand dumping/writing what is the 4 pin white connector for? (on the piece without the hole for the capacitor)

Thanks
 

Martin C

VIP Member
Jan 10, 2004
35,981
0
Scotland, UK
www.team-xecuter.com
The other ports are for other functionality.

The 4 pin socket on the QSB is for debug purposes. You can connect the RX/TX/GND/3v3 to a TTL serial device and get output to a PC.
 

1moment

Junior Member
Oct 6, 2011
18
0
on a side note does anyone know if you can just install the pin headers into a slim the same as a fat? are they the same in terms of diameter and spacing?
 

1moment

Junior Member
Oct 6, 2011
18
0
ok so i installed nand-x to my falcon today, can dump successfully with nandpro usb: -r16 nand.bin however after a few dumps to get a matching set the crc32 does not match my matching set from xellous dump why is this?

the xellous dump was taken yesterday before installing nandx i hadn't booted or done anything with it before installing and dumping nand with nandx
 

1moment

Junior Member
Oct 6, 2011
18
0
That is correct, to confirm I took another nandx dump, disconnected and booted into xellous and took a dump there, fc'ed and found quite a few differences approx 8 or so.... At the same time I installed pin headers onto a slim and dumped it 3 times, all were matching. When i dump the falcon with xellous it will never match if i just take multiple dumps it seems i need to take a dump, power it off and unplug it, then power up and take another to get them to match and this is not even 100%. When i dump the falcon with nandx it has the same behaviour, i was only able to get matching dumps by removing power inbetween each dump. Why would this be? is it reason for alarm? The falcon has been running (and is jtagged) for approx a year now with no problems and was sealed in the box when I came in possesion of it and immediately jtagged it, it never misses a boot or does anything weird and I have reflashed to new dashes a few times. When I did my original dumps of the falcon before jtagging with a DIY lpt cable I had the same issues with getting matching dumps and was only able to finally get some matching ones after removing power between dumps. As a side note when I am dumping the falcon consecutively while it is powered on (and even sometimes comparing dumps after removing power between each dump) it seems to generally be errors at the same 2-3 sectors, blocks, lines, whatever it is fc is referencing when it finds discrepencies atleast with the xellous dumps.


Any help MUCH appreciated as I have no idea were to go from here other than keep hoping for the best...
 

1moment

Junior Member
Oct 6, 2011
18
0
xellous dumps always differ at 004ca/004cb according to fc quite often with exact same

locations
always get error 250 at block 129 reading with nandx and xellous
i have tried just reading 20 or so times in a row without moving power and have never got a

matching dump

as a test i booted xellous and left tray open, dumped nand twice then powered off and

removed power. i did this exactly 3 times then compared all 6 dumps against eachother, only

dump number 2 and 4 matched the rest all had differences as follows according to fc

i clipped the list because its far too long but here is the basic idea:

C:\Users\Admin\Downloads>fc "flashdmp.bin" "flashdmp(2).bin"
Comparing files flashdmp.bin and FLASHDMP(2).BIN
004CB135: 00 80

C:\Users\Admin\Downloads>fc "flashdmp.bin" "flashdmp(3).bin"
Comparing files flashdmp.bin and FLASHDMP(3).BIN
004CAF87: 80 00
004CB0E1: C0 80
004CB135: 00 80

C:\Users\Admin\Downloads>fc "flashdmp.bin" "flashdmp(4).bin"
Comparing files flashdmp.bin and FLASHDMP(4).BIN
004CB135: 00 80

C:\Users\Admin\Downloads>fc "flashdmp.bin" "flashdmp(5).bin"
Comparing files flashdmp.bin and FLASHDMP(5).BIN
004CAF3D: 80 00
004CB0E1: C0 80
004CB135: 00 80

C:\Users\Admin\Downloads>fc "flashdmp.bin" "flashdmp(6).bin"
Comparing files flashdmp.bin and FLASHDMP(6).BIN
004CAF3D: 80 00
004CB0E1: C0 80
004CB135: 00 80
004CB1E4: 80 00

C:\Users\Admin\Downloads>fc "flashdmp(2).bin" "flashdmp(6).bin"
Comparing files flashdmp(2).bin and FLASHDMP(6).BIN
004CAF3D: 80 00
004CB0E1: C0 80
004CB1E4: 80 00

i repeated the same process with the nandx powering off and removing power between each 2

dumps 2 and 3 matched this time however overall results generally the same
 

1moment

Junior Member
Oct 6, 2011
18
0
I am positive the soldering is correct, its actually worse on the slim that dumps perfectly. I talked to some smarter guys than me on irc and ended up opening my images in a hex editor, the area my errors always pop up (offset 004c9200-004cd3ff or block 129) is different in my fw dump from anything else, it is filled with FF's and some areas have patterns of 80's and 00's there doesnt appear to be any meaningful data in that range as compared to the rest of the image. the graphical representation really does it for me as this area appears to be garbage data/repeating in stark contrast to the rest of the image and everytime i dump over xellous or nandx these offsets sometimes report a different value 80 or 00, 7f or ff for 3-6 of the pairs in the multiple hundreds of pairs that report like this. Basically we came to the conclusion it is my set of bad blocks, or addresses, or whatever word you want to use and for whatever reason unlike most others my bad blocks do not report the exact same everytime but since that area is the only place i ever see differences, it is the block that is already known as bad and remapped, this box has been running for over a year with 0 issues, i have the original untouched pre 7371 fw and have flashed it multiple times over the last year to newer dashes with xellous I am comfortable in assuming as long as my differences stay in that range everything is working just fine, is that a fair assumption?


Thanks
 
Last edited: