Products > Test Equipment
R&S RTB2004 Snooping
<< < (7/20) > >>
tv84:

--- Quote from: mikeselectricstuff on October 15, 2020, 11:01:10 am ---Could they be ECC data ?

--- End quote ---

Well, as I was saying, they sure are OOB (out of band) but they don't seem ECC as they are only 16 bytes for each 16384 bytes block. I think that is very few bytes to do any recovery or error signaling. But, for sure, I'm no expert on this. And, most of all, i think 4 or more bytes are always the same... so it is even less useful data.
abyrvalg:
Checked the Cyclone docs and ElectronMan's script, the command used for reading (MAP01) handles the ECC internally, NAND spare area is not included in the readout at all. Those 16 bytes should be FTL metadata. PeDre's txt contains Sector Size: 16384 and User Sector Size: 16368 - exactly 16 bytes difference. FTL block map dump (the big part of txt) consists of small entries fitting to 16 bytes easily. I don't have a dump to see how those OOB bytes looks like, could someone post an example?

That txt also explains why simple stripping works (for now): all "bad" counters (bad blocks, sectors, ECC errors, relocs etc) are 0.
tv84:
Here I shared a very rough map of the whole NAND with 32kB lines width (heavily resized).

One can see the patterns although the 16 bytes are completely obfuscated given the resizing.

I'll see if there is an anonymized extract block that I could share.
ElectronMan:

--- Quote from: tv84 on October 15, 2020, 08:51:43 am ---
--- Quote from: ElectronMan on October 14, 2020, 09:39:31 pm ---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.

--- End quote ---

Doing it methodically:

The first 0x08000000 bytes (128 MB) are perfect. All the bytes in the right place and we can see all the previous FW versions fully stored there. I wonder when they start writing on top of each other since we have the 128 MB almost all filled up.

The problem rises after the 0x08000000 as the dump starts having this format:

- a macro-block of 8 blocks of 0x4000 bytes (with the first 16 bytes being OOB) but the last block not having its own 16-bytes OOB.

This repeats itself up to file's end.

I've just reread your dumping explanation and I'm sure that your "The script strips out the 16 byte block header that is on blocks 1 - 4095."  was not correctly executed on the whole NAND dump.  So you did strip out the OOB data on the first 128 MB but not on the rest (at least not fully, as one of the 8 consecutive blocks has it strippeed out)?

I extracted the remaining OOB stuff, concatenated its contents and did some sanitization of certain patterns that seem to be flashed previously on the NAND (before writing newer files).

The remaining information seems to be some settings files and huge log files. I think even the calibration logging is there. But, I have a feeling something may be missing...

I'm not very good at interpreting perl stuff, so some questions remain as I can't verify your scripts fully:

- The last 384 MB must have a stripping/extraction error. Can you please verify.
- If you did extract 512 MB we should have 536.870.912 bytes. We have 512 MB - 4095 x 16 bytes.

It looks like the first 0x2000 blocks (of 0x4000 bytes) had their OOB data correctly stripped but the rest not. And if so, and you tried to also strip them in the rest of the data, then you stripped some good data (which was not the OOB portions).


--- Quote from: PeDre on October 15, 2020, 05:17:50 am ---Here is the output from a SCPI command to the flash memory. But I do not know exactly what it means. Maybe it helps a little bit.

--- End quote ---

I'll try to have a look, Peter.

--- End quote ---

I recall when working with a mostly-complete unaltered dump before that the 16-byte block headers may have ended later in the flash. I am taking a raw image now.

My scope indicates it has ~380M of free internal flash memory, so I don't think there's anything major missing. I have noticed a few things like screenshot thumbnail BMP files in the last 3/4 of the flash, alignment logs, and possibly mask files.
ElectronMan:

--- 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 ---

The NAND controller does do ECC transparently when reading in "Main area" mode, which is what I used. Main mode does not include the Spare area.

From the CycloneV HPS technical reference manual:


--- Code: ---Main Area Transfer Mode
In main area transfer mode, when ECC is enabled, the NAND flash controller inserts ECC check bits in
the data stream on writes and strips ECC check bits on reads. Software does not need to manage the ECC
sectors when writing a page. ECC checking is performed by the flash controller, so software simply
transfers the data.
If ECC is turned off, the NAND flash controller does not read or write ECC check bits
--- End code ---
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod