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\$
6
  • \$\begingroup\$ What is it you're trying to achieve by doing this? What do you plan to do with this file? \$\endgroup\$ Commented Dec 11, 2017 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\$ Commented Dec 11, 2017 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\$ Commented Dec 11, 2017 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\$ Commented Dec 11, 2017 at 22:02
  • \$\begingroup\$ Ok, I should convert only hex values from hexdump, without the ASCII representation table. \$\endgroup\$ Commented Dec 13, 2017 at 11:32

1 Answer 1

Reset to default
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\$
1
  • \$\begingroup\$ Yes, this command does the correct conversion, binary output matches the actual size of MTD partition. Thank you. \$\endgroup\$ Commented Dec 16, 2017 at 17:54

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.