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

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod