El tamaño del volcado de memoria no coincide con el tamaño de la partición MTD

Dispositivo con sistema Linux embebido en memoria flash NAND. Hice un volcado de memoria de algunas particiones de dispositivos MTD usando la consola serial, desde el cargador de arranque U-boot use los comandos disponibles. Primero leí la partición MTD a la dirección en la memoria, luego volqué la memoria de esa dirección a la ventana de la terminal. Por ejemplo, 0x01d60000-0x01e60000 : "FPAR"el tamaño de la partición MTD de la partición MTD es0x00100000 = 1048576 bytes

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

Luego guardó el archivo de registro con volcado como archivo de texto, eliminó cosas adicionales antes y después del volcado y lo convirtió en uso binario

xxd -r -p dump.txt dump.bin

El tamaño del archivo bin resultante de 1 310 860 bytes no coincide con el tamaño de la partición MTD (1 048 576 bytes), es mucho más grande. ¿El problema está relacionado con la conversión de datos hexadecimales o el proceso de volcado tiene errores? Entiendo que el tamaño de la partición MTD de 1048576 bytes es el tamaño asignado a toda la partición MTD, los datos reales en la partición ocupan un espacio mucho más pequeño, el espacio grande se llena con valores hexadecimales 'ff'. Además, ¿alguien puede recomendar una buena utilidad para la conversión de datos hexadecimales a bin?

Editar: probé los mismos pasos con un tamaño de datos de 64 bytes y usé el modo de sesión de registro sin procesar, después de recortar cosas adicionales, el archivo ascii resultante es de 318 bytes. Después de la conversión de volcado, el tamaño del contenedor es de 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
¿Qué es lo que estás tratando de lograr al hacer esto? ¿Qué piensas hacer con este archivo?
Pruebe el mismo procedimiento en una cantidad de memoria mucho menor (p. ej., 64 bytes) y luego examine los resultados en cada etapa para ver dónde se agrega el 25 % de bytes adicionales.
@Bruce Abbott Intenté lo mismo con datos de tamaño de 64 bytes, volcado editado con gedit: tamaño de archivo ascii resultante = 318 bytes. Entonces geditcorrompe el archivo. Pero incluso si edito el archivo con otro editor, por ejemplo, Geany, el tamaño del archivo resultante es el mismo.
¿Por qué insistes en hacer esto a ciegas? Use una herramienta como para mirarhexdump realmente los archivos y ver qué es diferente.
Ok, debería convertir solo valores hexadecimales de hexdump, sin la tabla de representación ASCII.
Parece que utilicé una forma incorrecta de convertir el volcado hexadecimal en un archivo bin, solo se deben convertir los valores hexadecimales, la tabla ASCII debe limpiarse.

Respuestas (1)

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

xxd -r -pespera la entrada en formato hexadecimal simple, sin direcciones ni ASCII. xxd -rsin -seekasume que las direcciones están basadas en cero, y buscará o rellenará con ceros su salida para omitir las regiones que no están presentes en el volcado (los primeros 0x20000000 = 536870912 bytes).

Sí, este comando realiza la conversión correcta, la salida binaria coincide con el tamaño real de la partición MTD. Gracias.
El tamaño del volcado de memoria no coincide con el tamaño de la partición MTD
RespuestasAquíPolítica de privacidad1y, 0v