Explanation of ARM (specifically mobile) Peripherals Addressing and Bus architecture?

Question

I will first say that I'm not expert in the field and my question might contain misunderstanding, in which case, I'll be glad if you correct me and attach resources so I can learn further details.

I'm trying to figure out the way that the system bus and how the various devices that appear in a mobile device (such as sensors chips, wifi/BT SoC, touch panel, etc.) are addressed by the CPU (and by other MCUs).

In the PC world we have the bus arbitrator that route the commands/data to the devices, and, afaik, the addresses are hardwired on the board (correct me if I'm wrong). However, in the mobile world I didn't find any evidence of that type of addressing; I did find that ARM has standardized the Advanced Microcontroller Bus Architecture, I don't know, though, whether that standard applied for the components (cpu-cores) which lies inside the same SoC (that is Exynos, OMAP, Snapdragon etc.) or also influence peripheral interfaces. Specifically I'm asking what component is responsible on allocating addresses to peripheral devices and MMIO addresses?

A more basic question would be whether there even exist a bus management in the mobile device architecture or maybe there is some kind of "star" topology (where the CPU is the center).

From this question I get the impression that these devices are considered as platform devices, i.e., devices that are connected directly to the CPU, and not through a bus. Still, my question is how does the OS knows how to address them? Then other threads, this and this about platform devices/drivers made me confused..

Sperling

Answer 1

A difference between ARM and the x86 is PIO. There are no special instruction on the ARM to access an I/O device. Everything is done through memory mapped I/O.

A second difference is the ARM (and RISC in general) has a separate load/store unit(s) that are separate from normal logic.

A third difference is that ARM licenses both the architecture and logic core. The first is used by companies like Apple, Samsung, etc who make a clean room version of the cores. For the second set, who actually buy the logic, the ARM CPU will include something from the AMBA family.

Other peripherals from ARM such as a GIC (Cortex-A interrupt controller), NVIC (Cortex-M interrupt controller), L2 controllers, UARTs, etc will all come with an AMBA type interface. 3rd party companies (ChipIdea USB, etc) may also make logic that is setup for a specific ARM bus.

Note AMBA at Wikipedia documents several bus types.

1. APB - a lower speed peripheral bus; sort of like south bridge.
2. AHB - several versions (older north bridge).
3. AXI - a newer multi-CPU (master) high speed bus. Example NIC301.
4. ACE - an AXI extension, allowing 'master-to-master' transfers such as CPU/GPU.

A single CPU/core may have one, two, or more master connection to an AXI bus. There maybe multiple cores attached to the AXI bus. The load/store and instruction fetch units of a core can use the multiple ports to dispatch requests to separate slaves. The SOC vendor will balance the number of ports with expected memory bandwidth needs. GPUs are also often connected to the AXI BUS along with DDR slaves.

It is true that there is no 100% standard topology; especially if you consider all possible future ARM designs. However, typical topologies will include a top level AXI with some AHB peripherals attached. One or multiple 2nd level APB (buses) will provide access to low speed peripherals. Not every SOC vendor wants to spend time to redesign peripherals and the older AHB interface speeds maybe quite fine for a device.

Your question is tagged embedded-linux. For the most part Linux just needs to know the physical addresses. On occasion, the peripheral BUS controllers may need configuration. For instance, an APB may be configure to allow or disallow user mode. This configuration could be locked at boot time. Generally, Linux doesn't care too much about the bus structure directly. Programmers may have coded a driver with knowledge of the structure (like IRAM is fasters, etc).

Still, my question is how does the OS knows how to address them?

Older Linux kernels put these definitions in a machine file and passed a platform resource structure including interrupt number, and the physical address of a register bank. In newer Linux versions, this information is included with Open Firmware or device tree files.

Specifically I'm asking what component is responsible on allocating addresses to peripheral devices and MMIO addresses?

The physical addresses are set by the SOC manufacturer. Linux platform support will use the MMU to map them as non-cacheable to some un-used range. Often the physical addresses may be very sparse so the virtual remapping pack more densely. Each one incurs a TLB hit (MMU cache).

---

Here is a sample SOC bus structure using AXI with a Cortex-M and Cortex-A connected.

The PBRIDGE components are APB bridges and it is connected in a star topology. As others suggests, you need to look a your particular SOC documentation for specifics. However, if you have no SOC and are trying to understand ARM generally, some of the information above will help you, no matter what SOC you have.

Amorette

Probably even those who create there own CPU will use a standard bus as they would also loose/limit access to 3rd party modules. While it is possible to invent your own bus, there are some pretty bad downsides. Most of the Freescale iMX line is very similar to the above; it is used in some cell phones and more commonly in vehicle systems. – Amorette

The OMAP from TI includes other non-AMBA buses because of the legacy TI DSP in the SOC. A vendor like this needs glue between a stock Cortex-A AXI and the existing BUS. Armv5/ARM926 only use AHB buses. See: Doulos's Migrating from AHB to AXI where you can see that all of these 'versions' have sub-versions and slightly altered signalling. – Amorette

Took me a while to understand some of tje things that you wrote but after diggings it all became understood. – Sperling

my intention is to understand low level processes that involves both software (i.e. OSs and drivers) and hardware (cpu<-->memory<-->buses<-->devices). One process that I'm interested in right now is the work with a dma controller. I've wrote an new question about it so it won't be just a little comment here snice it might help a lot of other people to understand important processes. This is it #28572098 – Sperling

There are different revisions of AXI, but it is the most common bus type. Wishbone, Avalon, etc. are other bus types. AXI-Stream protocol is the 'base' specification of AXI, with clock, reset, valid and ready defining the transfer of multiple data lines. Address lines, actual data, permission, etc. are layered on top of the AXI streams. Ie, multiple streams create an AXI channel. – Amorette

Answer 2

Each SoC will be designed to have its own (possibly configurable) memory map. You will need to read the relevant technical reference manual to get the exact details.

Examples are:

Raspeberry pi datasheet (pdf)

OMAP 5 TRM

Dandify