| Products > Test Equipment |
| R&S RTB2004 Snooping |
| << < (18/20) > >> |
| uski:
I got this : https://www.amazon.com/gp/product/B07XHW1959/ Will report if they fit or not when I receive my scope |
| Harjit:
Any updates? |
| trimen:
I was able to dump my scope via JTAG, it took only about 4-5 hours and I didn't encounter any JTAG related errors. (I used XDS100v3) In my unit, there wasn't placed Molex picoblade connector, so I populate it myself. For anyone interested I can provide dumped images for comparison. |
| AnJu:
--- Quote from: trimen on April 13, 2021, 11:10:29 am ---I was able to dump my scope via JTAG, it took only about 4-5 hours and I didn't encounter any JTAG related errors. (I used XDS100v3) For anyone interested I can provide dumped images for comparison. --- End quote --- Please to provide your NAND image. anjugm gmail com |
| sergeyklenov:
--- Quote from: ElectronMan on October 15, 2020, 01:17:10 pm --- --- 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. --- End quote --- Yes, really content repeat each 0x2000 after 0x8000000 i think mistake in setting page for nand reading. |
| Navigation |
| Message Index |
| Next page |
| Previous page |