1
\$\begingroup\$

Device with Linux embedded system on NAND flash memory. I did memory dump of some MTD devices partitions use serial console, from U-boot bootloader use available commands. First I read MTD partition to address in the memory, then dumped memory from that address to the terminal window. For example, MTD partition 0x01d60000-0x01e60000 : "FPAR" MTD partition size is 0x00100000 = 1048576 bytes

nand read 0x20000000 0x01d60000 0x00100000
NAND read: device 0 offset 0x1d60000, size 0x100000
1048576 bytes read: OK
md.b 0x20000000 0x00100000

Then saved log file with dump as text file, cut out extra stuff before and after the dump and coverted it to binary use

xxd -r -p dump.txt dump.bin

Resulting bin file size 1,310,860 bytes is mismatching MTD partion size (1,048,576 bytes), its much larger. Is the problem related to hex data conversion or the dump process have errors? I understand that MTD partion size of 1048576 bytes is size assigned to the whole MTD partition, the actual data on partition takes much smaller space, the large space filled with hex 'ff' values. Additionally, can anyone advice good utility for hex to bin data conversion?

Edit: I tried the same steps with 64 bytes data size, and used Raw log session mode, after trimming extra stuff, the resulting ascii file is 318 bytes. After dump conversion, the bin size is 87 bytes.

20000000: a0 7c 4f fa 62 61 75 64 72 61 74 65 3d 31 31 35    .|O.baudrate=115
20000010: 32 30 30 00 65 74 68 61 64 64 72 3d 46 46 3a 46    200.ethaddr=FF:F
20000020: 46 3a 46 46 3a 46 46 3a 46 46 3a 46 46 00 6e 65    F:FF:FF:FF:FF.ne
20000030: 74 6d 61 73 6b 3d 32 35 35 2e 32 35 35 2e 32 35    tmask=255.255.25
\$\endgroup\$
  • \$\begingroup\$ What is it you're trying to achieve by doing this? What do you plan to do with this file? \$\endgroup\$ – Finbarr Dec 11 '17 at 14:57
  • 1
    \$\begingroup\$ Try the same procedure on a much smaller amount of memory (eg. 64 bytes) then examine the results at each stage to see where the 25% extra bytes are being added. \$\endgroup\$ – Bruce Abbott Dec 11 '17 at 15:54
  • \$\begingroup\$ @Bruce Abbott I tried the same with 64 bytes size data, edited dump with gedit: resulting ascii file size= 318 bytes. So gedit corrupts the file. But even if I edit file with another editor, for example Geany, the resulting file size is same. \$\endgroup\$ – triwo Dec 11 '17 at 22:01
  • \$\begingroup\$ Why do you insist on doing this blindly? Use a tool like hexdump to actually look at the files and see what is different. \$\endgroup\$ – Chris Stratton Dec 11 '17 at 22:02
  • \$\begingroup\$ Ok, I should convert only hex values from hexdump, without the ASCII representation table. \$\endgroup\$ – triwo Dec 13 '17 at 11:32
3
\$\begingroup\$

Try: xxd -r -seek -0x20000000 dump.txt dump.bin

xxd -r -p expects input in plain hexadecimal format, without addresses or ASCII. xxd -r without -seek assumes that addresses are zero-based, and will seek or zero-pad its output to skip over regions not present in the dump (the first 0x20000000 = 536870912 bytes).

\$\endgroup\$
  • \$\begingroup\$ Yes, this command does the correct conversion, binary output matches the actual size of MTD partition. Thank you. \$\endgroup\$ – triwo Dec 16 '17 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.