| Products > Test Equipment |
| R&S RTB2004 Snooping |
| << < (6/20) > >> |
| 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 |
| Message Index |
| Next page |
| Previous page |