19

On a single-board computer running Linux, is there a way to read the contents of the device configuration registers that control hardware? I think it would be a wrapper for inw().

I'm looking for something equivalent to the U-boot memory dump (md) command, to be used in the context of driver debugging.

countermode
  • 7,373
  • 5
  • 31
  • 58
pingswept
  • 1,085
  • 2
  • 9
  • 12
  • 2
    This may help, but be sure to read the whole thread: http://lists.arm.linux.org.uk/lurker/message/20051020.014413.d56dd6f8.en.html – Gilles 'SO- stop being evil' Dec 17 '10 at 20:18
  • Any updates on this?? – Navaneeth Sen Dec 20 '10 at 08:09
  • @Sen: Negative. I'm still stumped. I read the linked thread, which suggests that inw() doesn't do what I thought: "inb() and friends are _only_ for emulation of the PCI and ISA IO address space." I've been using an oscilloscope and reading a lot of kernel driver code as my next best options. – pingswept Dec 20 '10 at 17:02

5 Answers5

15

If you know the physical address of the device, you can use devmem2.

devmem2 <physical address> <size (b/h/w)> [value]
Anthon
  • 78,313
  • 42
  • 165
  • 222
Eric
  • 151
  • 1
  • 2
3

I don't know if you can do it directly with a vanilla kernel.

But it should be quite strait forward to write a simple driver that uses a "file" in /proc to export the memory content you would like to see.

Then you can read your "file" with a simple script and have access to that memory.

Johan
  • 4,523
  • 2
  • 26
  • 33
1

I could be completely and totally wrong about this, and forgive me if I am, but if uboot's md command is just reading memory addresses mapped to device registers and returning the contents to you, couldn't you read those same memory locations with clever use of dd if=/dev/mem ...?

LawrenceC
  • 10,884
  • 4
  • 33
  • 45
  • I think this route has potential, but it seems that there is a problem. This command executed as root: "dd if=/dev/mem bs=1 skip=10000 count=512" gives this error: "dd: /dev/mem: Bad address" I'm not sure what that means. Google tells me that it's something to do with changes introduced in the 2.6 kernel, but I don't understand enough about this yet to work around it. – pingswept Jan 03 '11 at 03:21
  • 1
    Maybe try using the mtdblock driver. Check this out: http://en.gentoo-wiki.com/wiki/Using_Graphics_Card_Memory_as_Swap But instead of pointing it to your graphics card RAM, maybe try pointing it to the device registers. – LawrenceC Jan 03 '11 at 15:51
0

busybox devmem

busybox devmem is my preferred version of devmem2 which was mentioned at: https://unix.stackexchange.com/a/134661/32558

devmem2 came in many different versions from several upstreams, notably Buildroot http://free-electrons.com/pub/mirror/devmem2.c

But a Busybox utility is more canonical, widely available and maintained.

For example,devmem2 was rejected from Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595805 (but an Ubuntu package was created nevetheless).

You can get it in Ubuntu with:

sudo apt-get install busybox

Usage: read 4 bytes from the physical address 0x12345678:

sudo busybox devmem 0x12345678

Write 0x9abcdef0 to that address:

sudo busybox devmem 0x12345678 w 0x9abcdef0

Here are some cool ways to test devmem out: https://stackoverflow.com/questions/12040303/accessing-physical-address-from-user-space/45127890#45127890

0

There's a utility called pcimem (https://github.com/billfarrow/pcimem)

You can use it for reading and writing to/from pci devices.

simba
  • 1
  • 1