Products > Test Equipment
R&S RTB2004 Snooping
tv84:
ElectroMan,
Please explain how you did the NAND dump and why the first 0x0800 0000 seem all good and the rest seems to contain raw NAND bytes plus OOB.
ElectronMan:
--- Quote from: tv84 on October 13, 2020, 07:28:14 pm ---ElectroMan,
Please explain how you did the NAND dump and why the first 0x0800 0000 seem all good and the rest seems to contain raw NAND bytes plus OOB.
--- End quote ---
Whatever "filesystem" they are using seems to place 16 bytes of NAND management data at the beginning of each block after block 0 (possibly data for previous block?) I did not look too much at that and just discarded it, as it was corrupting the extracted firmware sections.
Do you have other specific questions about the process? I explained the methodology in the first post and provided the script I used here: https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/msg3242084/#msg3242084
I was basically emulating a crude NAND controller driver via memory reads/writes through OpenOCD to get the NAND contents.
The image that was extracted seems to have all the software (and a bunch of different versions), but if there are errors in the latter memory regions it would be difficult to tell for certain what should be there. I double-checked my binary math a few times, and as all the important data seemed to be there I assumed some of the garbage later in the file was an artifact of however they were flashing these from the factory.
Note that the apps seem to use about 25-30M of a 512M flash. A lot of the other stuff there are older firmware versions (the scope came with a version newer than most of them on the flash). This leads me to believe the image they use to flash these devices has a lot of stuff left over from earlier testing stages.
It is, of course, also possible there's something wrong with my methodology and my binary math fell apart. A second set of eyes on that would be welcome.
abyrvalg:
Peter’s txt contains an answer: there is an FTL (and that is natural - this is NAND), so in general you can’t just strip and ignore OOB data. It’s a luck (and high quality components choice by R&S) that simple stripping worked on the first part of data without hitting a bad/remapped block. Btw, what about ECC? Is it done automatically by Cyclone’s NAND controller?
tv84:
--- Quote from: abyrvalg on October 15, 2020, 09:58:21 am ---Peter’s txt contains an answer: there is an FTL (and that is natural - this is NAND), so in general you can’t just strip and ignore OOB data. It’s a luck (and high quality components choice by R&S) that simple stripping worked on the first part of data without hitting a bad/remapped block. Btw, what about ECC? Is it done automatically by Cyclone’s NAND controller?
--- End quote ---
Maybe I used the wrong term. I don't think that those stripped 16 bytes are really OOB with sector recovery info, etc. Maybe more like checksum, framing, etc... it seems too few bytes to have a meaningful goal.
mikeselectricstuff:
--- Quote from: tv84 on October 15, 2020, 10:35:23 am ---
Maybe I used the wrong term. I don't think that those stripped 16 bytes are really OOB with sector recovery info, etc. Maybe more like checksum, framing, etc... it seems too few bytes to have a meaningful goal.
--- End quote ---
Could they be ECC data ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version