Memory display using md in u-boot
Yes you're correct about the middle values. Those are the data values and their ASCII representations are printed to the far most right. The addresses are in hex as well so you're seeing 16 values per row, 0000000c to 0000001c, for example. There is also a base command (type help base) which specifies what the base addresses is for the relative addresses you're seeing there, 0000000c. It defaults to 0.
From the help documentation, titled: 5.9.2. Memory Commands.
excerpt
5.9.2.5. md - memory display
=> help md md - memory display Usage: md [.b, .w, .l] address [# of objects] =>The md can be used to display memory contents both as hexadecimal and ASCII data.
=> md 0x100000 00100000: 8083764e bd86200a 60a19054 2c12c402 ..vN.. .`..T,... 00100010: c101d028 00438198 7ab01239 62406128 ...(.C..z..9b@a( 00100020: 0c900d05 320b4581 1ca3d0a2 c498293a ....2.E.......): => 00100030: 58f5c828 6029e009 d0718131 154b105b X..(`)...q.1.K.[ 00100040: 9019a424 7423a001 e064013c 016a0070 ...$t#...d.<.j.p 00100050: d0809820 12437140 0064e018 424be2a9 ... [email protected].. =>This command, too, can be used with the type extensions .l, .w and .b :
=> => md.w 0x100000 00100000: 8083 764e bd86 200a 60a1 9054 2c12 c402 ..vN.. .`..T,... 00100010: c101 d028 0043 8198 ...(.C.. => md.b 0x10000The last displayed memory address and the value of the count argument are remembered, so when you enter md again without arguments it will automatically continue at the next address, and use the same count again.
=> md.b 0x100000 0x20 00100000: 2f 83 00 00 40 9e ff 38 38 60 00 00 4b ff ff 3c /[email protected]`..K..< 00100010: 83 5e 00 0c 80 9e 00 08 2b 9a 00 ff 82 9e 00 10 .^......+....... => md.w 0x100000 00100000: 2f83 0000 409e ff38 3860 0000 4bff ff3c /[email protected]`..K..< 00100010: 835e 000c 809e 0008 2b9a 00ff 829e 0010 .^......+....... 00100020: 82be 0014 7f45 d378 409d 000c 3b40 00ff .....E.x@...;@.. 00100030: 38a0 00ff 2b95 00ff 409d 0008 3aa0 00ff 8...+...@...:... => md 0x100000 00100000: 2f830000 409eff38 38600000 4bffff3c /[email protected]`..K..< 00100010: 835e000c 809e0008 2b9a00ff 829e0010 .^......+....... 00100020: 82be0014 7f45d378 409d000c 3b4000ff .....E.x@...;@.. 00100030: 38a000ff 2b9500ff 409d0008 3aa000ff 8...+...@...:... 00100040: 8002021c 3bfb000a 7f9f0040 419d002c ....;......@A.., 00100050: 2f9a0000 419e0014 7c1f0050 3925ffff /...A...|..P9%.. 00100060: 7f890040 419d0014 7fe3fb78 4bf1401d [email protected].@. 00100070: 7c651b78 48000014 3c00bfff 6000ffff |e.xH...<...`... =>
Related videos on Youtube
03 : 08
04 : 15
01 : 25 : 58
02 : 04
32 : 11
Comments
-
gpuguy almost 2 years
U-Boot-PetaLinux> md 0xc 0000000c: 2201c2a0 1a8441c5 90031018 52011010 ...".A.........R 0000001c: 0045c903 022c19ae 01077620 ca173dc0 ..E...,. v...=.. 0000002c: 0804e426 15dd0c12 201092c1 2a405554 &.......... TU@* U-Boot-PetaLinux>Here the right most column is address. In middle I can see values
32 bit 32 bit 32 bit 32 bit
At the left it is the ASCII representation of the values in middles (total 128 bit ).Am I right? Also why is it printing 0000001c, I did not ask for this?
Can some one explain me if my understanding is wrong.
-
Lexx Luxx over 6 yearsFor correct conversion of memory dump from the hex form back to binary, should we use only hexadecimal representation? If we converting raw dump containing the corresponding ASCII data column, we can't get a correct binary file? Then, how to get dump without the ASCII equivalent data at the end?
