Does anyone know of an Idiot's Guide to this topic? In particular, how does a processor with no special I/O instructions issue a request, e.g. to a serial output device to output "Hello, World"? And how does Memory-Mapped I/O work in detail? Where is the Memory Map stored? What are the actual contents of Device Memory? And where do AMBA/AXI (or ACE) fit in? (I did say it had to be an Idiot's Guide!)
I am not aware of any simple documentation within ARM on this topic - mainly because it is not ARM-specific in anyway. Memory-mapped IO works in exactly the same way on almost any architecture or platform you care to mention.
It really works the way it sounds - control/status registers in the device are mapped (in the hardware, by mechanisms that you don't need to understand!) to memory addresses. You access the registers simply by accessing memory locations. Unless you are designing chips (or working with an extremely complex system), you don't really need to factor in any knowledge of AXI/AHB or the bus topology. The contents and behaviour of device memory is defined by the device which is mapped to those particular memory locations.
If you look for example code on pretty much any of hundreds of development boards available from the major silicon vendors, I am sure you will find simple examples of drivers for memory-mapped devices which will show you how it all works.
Hope this helps.
Chris
Chris Shore wrote: Unless you are designing chips (or working with an extremely complex system), you don't really need to factor in any knowledge of AXI/AHB or the bus topology.
Chris Shore wrote:
Unless you are designing chips (or working with an extremely complex system), you don't really need to factor in any knowledge of AXI/AHB or the bus topology.
Well, knowing the topology and the characteristics of the various protocols can obviously also be quite relevant for performance optimization. And, on non-coherent multicore SoCs (and there are plenty of those) knowing the topology can actually be essential for reasoning about ordering of transactions (and therefore of software correctness). For example, on the one I'm using, if a core writes data to location A, performs a full data sync barrier, then writes &A to B, I'm pretty sure another core which reads B and dereferences it to read A is not always guaranteed to read the new data there (when A and B are in different memories).