On many embedded systems, a great deal of communication with devices is done by reading and writing to memory-mapped I/O (MMIO) addresses in software. Supposing that I have access to the physical device, and a copy of the firmware that I can load in IDA, how can I figure out which devices are at which addresses?

So far I've just been making guesses by looking at the code, string references (e.g., if a function prints out "Initializing timer interrupt" I can guess that maybe some of the addresses are for configuring a timer). But surely something must know where all the devices live in memory, because something is responsible for routing memory reads/writes to the correct device.

So, is there a more systematic way to derive this information?

1 Answer 1


But surely something must know where all the devices live in memory, because something is responsible for routing memory reads/writes to the correct device.

In embedded devices there's nothing like PCI (well, it may be present but it's just one of the many HW blocks). So you can't just scan all possibilities to discover the existing devices. The code must know where everything is.

That said, there are some sources of information you may try to find.

  1. Datasheets - always the best choice. Even if there are typos and c&p errors it still beats anything else. Note that many manufacturers have separate datasheets for pinout, electrical/temperature characteristics of specific chips, and user manuals (also called software or programming manuals) which are shared among many chips in the same family. You usually need the latter, though sometimes the former can also give some useful hints.

  2. Any source code (OS, drivers, etc) you may find for the device. Even if it's not for the specific hardware block you're interested in, the headers may include defines for it.

  3. If you can't find the exact match for your chip, look for anything in the same family - often the differences are just sizes of some blocks or number of ports.

  4. Look at the docs for the same HW blocks in any chip of this manufacturer. Some makers reuse their IP blocks across architectures - e.g. Infineon used pretty much the same GPIO blocks in their E-GOLD (C166) and S-GOLD (ARM) basebands. Renesas is another example - they reused IP blocks from SuperH series in their ARM chips.

  5. Some hardware is standardized across all architectures and manufacturers, e.g.: PCI, USB controllers (OHCI, EHCI, XHCI), SD host controllers, eMMC and so on.

EDIT: sometimes, the hardware external to chip may be connected via an external bus interface (or external memory interface, or many other names). This is usually present in the bigger chips with at least a hundred pins. This interface can be programmable, and you can set up which address ranges go to which set of pins. Often there are also so-called chip select (CS) lines involved, which allow multiplexing the same set of pins for accessing several devices, so that one range of addresses will assert CS1, the other CS2 and so on. If you have such a set up, you need to find out the code which initializes the external interface, or dump its configuration at runtime. If you can't do that, you can try looking for memory accesses which correspond to the register layout of the external chip (such as an Ethernet controller), modulo some base address in the CPU's address space.

  • Right, but again – knowledge has to be somehow embedded in the hardware as well. E.g. the software reads at physical address 0xdeadbeef. The hardware has to know that this means "read from register 0xf of the Broadcom Gigabit Ethernet controller". Shouldn't there be some way to enumerate those mappings (not necessarily in software, but e.g. by looking for connectivity on the board or dumping the configuration of some hypothetical address-mapping chip)? Jun 3, 2013 at 17:39
  • @BrendanDolan-Gavitt: added some text about what I think you meant
    – Igor Skochinsky
    Jun 3, 2013 at 17:58
  • Ok, I think I understand. Unfortunately the SoC I'm looking at right now was manufactured by PMC for this specific company (HP) and there is no datasheet or source code available; the most I know is that it's based around a Cortex A8, but this doesn't tell me anything about the memory map. So, back to staring at the binary I guess... Jun 4, 2013 at 19:02

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.