| Products > Test Equipment |
| R&S RTB2004 Snooping |
| << < (8/20) > >> |
| abyrvalg:
Looks like 08000000+ area uses some different data/metadata layout, so the reader script strips metadata incorrectly. The dump by tv84 looks like it has some data stripped at wrong positions (16 "metadata" bytes are at +0 in each 16K sector of the first 128K block, but the same looking data is moved by 16 bytes upper in the next block, then by 32 bytes upper, ...). It would be better to turn off that stripping at all, read everything as is, then decide what to strip for each area. Or even use MonDeb "cr" command to read NAND to RAM (so a builtin read function that knows the correct data format will be used), then dump it from there either via JTAG (this can be done in huge portions) or with MonDeb "du" command. |
| ElectronMan:
--- Quote from: abyrvalg on October 15, 2020, 03:51:07 pm ---Looks like 08000000+ area uses some different data/metadata layout, so the reader script strips metadata incorrectly. The dump by tv84 looks like it has some data stripped at wrong positions (16 "metadata" bytes are at +0 in each 16K sector of the first 128K block, but the same looking data is moved by 16 bytes upper in the next block, then by 32 bytes upper, ...). It would be better to turn off that stripping at all, read everything as is, then decide what to strip for each area. Or even use MonDeb "cr" command to read NAND to RAM (so a builtin read function that knows the correct data format will be used), then dump it from there either via JTAG (this can be done in huge portions) or with MonDeb "du" command. --- End quote --- Yeah, I was considering using the Mondeb interface to do just that. I had tried doing DMA transfers via script from flash but could never get them to work. I have a full raw JTAG dump happening now at home via the flash controller. Problem is that long runs of 0xFF seem to cause JTAG timeouts and errors, so getting a good dump is a challenge. If it isn't complete when I get home I'll try using Mondeb to transfer it into RAM so I can read it in larger chunks. |
| tv84:
Agree with both. With a successful raw dump, we should be able to parse in no time. Electro, remember we don't need the 1st 128 MB again. You can restart at 0x08000000. :) By doing a bitmap with the whole 512MB it's very easy to see those 16-bytes "junk" zones and do a visual integrity check. |
| ElectronMan:
--- Quote from: tv84 on October 15, 2020, 04:52:04 pm ---Agree with both. With a successful raw dump, we should be able to parse in no time. Electro, remember we don't need the 1st 128 MB again. You can restart at 0x08000000. :) By doing a bitmap with the whole 512MB it's very easy to see those 16-bytes "junk" zones and do a visual integrity check. --- End quote --- I just started pulling the entire 512M so I'd have it for disaster recovery. It doesn't matter much anyway, as the first 128M transfers pretty quickly. It is the parts of flash that have a lot of 0xFF's (empty) that cause all kinds of JTAG errors and restarts. The first 128M takes about an hour or two, and the remainder ends up taking about 18hrs or so. |
| tv84:
--- 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. Peter --- End quote --- Peter, show us the command that you used for this. We can easily see here: "Block Size: 131072", "Sector Size: 16384", "User Sector Size: 16368", So, we definitely should have blocks of 128 kB = 8 sectors x 16 kB (but each sector has -16 usable bytes). |
| Navigation |
| Message Index |
| Next page |
| Previous page |